The topic came up in another thread about options for writing documentation. I've been involved with many projects that faced the same question and all have made different choices. I think this means we can save a lot of time and accept that there is no "best" solution, it's really a matter of personal comfort of the few people who actually work on documentation. I'll note a number of related factors here, numbered only for reference (cuz you guys know I love numbered lists ), and might come back and edit this list as others add their notes. Then based on these factors, Till and other leads here can make their decisions. Let's start with the elephant in the room: Free is good. I think it's important to have the ability to share content between documents to avoid copy/paste or re-writing. I think text should be small and modular, not enclosed in massive, hard-coded "silo" documents. Think lots of DLLs rather than a huge EXE, or lots of OOP classes rather than one huge file/function. I think this project could really use the ability to generate a document that is specialized for the reader. Right now there is a different "Perfect" document for a bunch of platforms, and there is another document published for each new version, like Ubuntu 16/18/20. I think the ideal scenario is to have intelligent documentation that is generated dynamically. So for example, if someone is using Courier rather that Dovecot, the document presented to them can include Courier-specific information and links to related discussions in this forum. I hope we can agree that collaboration is a top requirement. An environment where people need to copy around a document is old school and inadequate. A single document maintained by a single person is not scalable. Wiki docs in a Git repo with markdown is a great option for collaboration. (A GitHub Wiki repo is a bit weird. For this purpose I'm talking about a regular repo that happens to contain a markdown docs.) It can be versioned like software, branched, and published. A problem with generic markdown is that it doesn't support (either easily or at all) attractive UX features like tooltips, collapsing sections (spoiler/accordion), or other features common and helpful in other media. Tools are also required to export from markdown to other formats. A wiki like MediaWiki is also a great option. Too many people think a wiki Must be open to the public. That is not true. People also believe a published wiki like this is exposed to bogus registrations, malicious content, etc. That is only the case when it is not secured - that is, when people want a wiki with public viewing and private collaboration, but they leave it open for public contributions. A hybrid option is possible where a read-only wiki is available to users with a private wiki for development. MediaWiki also has plugins for publishing documentation to PDF or HTML. So people don't need to get their information from a wiki - the wiki can be used just for development. In summary, there is no "a wiki does this". The more accurate statement is "a wiki does whatever we want it to do". Note that MediaWiki supports the modularity and conditional logic mentioned in #2 & #3. MediaWiki is just one wiki option. I focus on it here as just one of many wiki options that can be installed and fully supported internally. Collaboration tools are much more readily available now than in the past. For example, documents are easily shared in Slack and Teams. Google docs can be used in a split second, and it contains adequate formatting for current purposes. Microsoft One Note collaboration is easy, as is Evernote and similar notebook applications. While some of these options allow for versioning, verision support isn't great. Many of these options claim real-time collaboration as a feature but in practice, especially for FOSS which is developed very asynchnously, that feature is almost entirely unimportant. There are many subscription based websites. As examples, Confluence is popular and free for 10 users, and Bit.ai specializes in collaboration and is free for up to 5 users. Personally I don't like subscription sites because the documentation is on someone else's server and there are always limits to avoid. Over the years WordPress has evolved into a full content management system. It's FOSS, free, all data is local, there are a ton of plugins that already support functionality described here, and it's very extensible. It's also written in PHP which is very familiar to ISPConfig devs if required. I personally recommend WordPress, though others might prefer Drupal or some other CMS. The point here is that for this specific application a general purpose CMS with a lot of features might be preferable to a documentation-specific platform. I tend not to think that way, that general-purpose tools might be better than tools for a specific purpose, but I see documentation as being "content", and each paragraph and chapter as being separate content, with a document just being a desired export format. Compared to forum software like this which requires forum-specific functionality. Note that a CMS, similar to markdown, can export content (a web page) in other formats like PDF. Note also that this medium faciliates user/role-based access, workflow, notifications, comments, and many other features. We can integrate it within the control panel for context-specific help. And we can probably also integrate it with this XenForo. There are licensed products like HelpNDoc and Help&Manual. I've been using H&M professionally for the last year and have been quite happy with it. It conforms to almost all of the notes here so far except it is not free, though I don't know if there is a special license for FOSS projects. There are probably others in this category that might be full-featured And free. Summary: There are a lot of options with WordPress, so if I had to do this now for this project, that would be my first preference. If markdown a requirement then I'd go with MediaWiki - Second to that woudl be another wiki package - Third to that would be pages on GitHub. My overall preference would be H&M but I don't actually think that would be best for this project due to the cost. YMMV I hope I haven't forgotten anything obvious. And I hope this is helpful in this process. If the team decides on WordPress or MediaWiki, I would be happy to help setup, maintain, and sort of mentor the environment for these purposes. While others contribute with code, this would be my FOSSy contribution.