Regardless of the environment of new documentation, whether WordPress, DocuWiki, GitHub, or vi into text files (kidding), the real focus should be on what we want to see in content, not so much how it's created or rendered. Personally, here are my raw thoughts on the docs available for ISPConfig: The awesome series of Perfect installations is just the beginning of the road for the ISPConfig experience. They are tutorials, references, and the go-to RTFM for many forum posts. But they are not suitable for configuration or ongoing administration after the initial installation. The User Manual, also awesome for its purpose, tells us what buttons to press, but it doesn't tell us anything about what the software does, why, or how. Let's face it, it's also quite old and rather sparse on details. While RTFM might be a good response for many questions, this FM (and I say that with a respectful smile) may or may not be accurate in too many places given that it hasn't been updated in a few years. This leaves a huge gap which is now handled in these forums. There are questions about how users and jails work, subdomains and vhosts, DNS-related nuances, and every other feature that needs to be implemented by administrators. Some of the questions here are from people who don't understand the concepts. (I'll include myself in that category of "under-educated" wannabes.) But many are from ISP-employed administrators who simply don't know what is expected from ISPConfig: what values it sets in underlying applications, what folders it creates, permissions, restricted/insecure fields it does not set, and how exactly a secondary environment is instructed (currently via MySQL queries) to perform specific functions. I see a LOT of questions in these forums about how things work, and a lot of instructions to just press whatever button we're told to fix it. But there is often little insightful information that can allow people to really use this software to its potential. "Anyone with interest can read the code." That's a dismissive engineer approach which discourages platform adoption. One should not have to know how to code at all in order to understand what the code does. I could be wrong in a lot of that, but my perceptions are what they are, reinforced as I read more and more. To be clear, I also appreciate every note I see in a forum. People give their time to help others with no compensation. I do this in other communities - that's my FOSSy pay-forward/pay-back for the help I get in this world. What I'm seeing here is that the top contributors to these forums are spending a lot of time generously answering questions (with some visible frustration) when we should be able to Refer To Friendly Manuals. So here is one aspect of what I'd like to see in new docs, ideally at https://docs.ispconfig.org/ based on notes in the other thread on this topic... I think it would be good to have very well indexed content with a keyword index. The easier it is to search, the easier it is to point to an existing answer so that we can save time and move on to other topics. There should be many ways to get access to a topic. There should be many relevant See-Also references. Extensive indexing is helpful to facilitate the web surfing experience so that people can get all information available about a concept. Contributions of links to related topics should be as welcome as any other on-page content. Links to other fundamental resources are important because we frequently see that people need more information about a topic before they're competent and confident to press the buttons as instructed in docs and forums. I don't see a doc site for ISPConfig as being constructed from one complete page at a time. I think all content evolves because there is always some new relevant bit of information that can be added. If we look at the User Manual there are a lot of topics and I think it would help to create a page stub for a lot of those, and then fill in the stubs over time. Anyone who has something to contribute can add to these pages about how and why things work as they do, with links back to the manual for how to implement the details. I'm not suggesting a wiki-style free-for-all, but a code-like system where contributions are submitted in a process like MR, verified, then merged into the content. These are examples of topics that can start as a stub and get filled-in over time. Please don't debate specific topics, these are just examples. Yes, topics like this can be covered in HowToForge but this is all about detail specific to its use with ISPC : DNS ALIAS, CNAME, or A record? Where should a subdomain be hosted? How does ISPC work with a jail, permissions, user IDs and other authorization mechanisms? What does ISPC do related to BIND9 and named resolution? What kind of directives should go in .vhost files? What do we do about .htaccess? How do we customize the login page and new site index.html? What are all of the areas touched by certbot/LE, and what is Not done from ISPC? What is monitored? What is not? How can we add a new log monitor? How to manage (custom?) folder structures. How are SSH/SFTP users managed? What are some backup/recovery strategies? What can we monitor in SMTP/POP3/IMAP/spam/AV and related services, and what else do we need to do outside of ISPC? In all of this, I am not proposing publication of the User Manual. I am not trying to make ISPConfig documentation a substitute for the million other resources for system administration. I am not proposing "Hosting an ISP for Dummies". I'm suggesting we stub out topics that are relevant to ISPConfig environment management and fill in content that's not provided elsewhere. A ton of this information is already in forums - a lot of wisdom there can be conveyed briefly in topical pages so that people don't need to be told how to use a search engine and site:howtoforge.... Thanks for your time and suggestions. P.S. : And I'm not suggesting that @till or any other developer take the lead on all of this. I would be happy to create stubs, contribute content, edit, format, and respond to commentary and contributions. I won't pretend competence to do this all on my own. I'm just saying I have no intention to dump this on the people who are already fully occupied with what they do here.