4 ms·
Well, to quote Jordan Sissel (author of Logstash) "Wiki means: where documentation goes to die". I found maintaining a good documentation inside a wiki tough.
by kakwa_ 7y ago
Well, to quote Jordan Sissel (author of Logstash) "Wiki means: where documentation goes to die".
I found maintaining a good documentation inside a wiki tough. People (including me) will tend to create new pages willy nilly, never deleting old ones. The layout is generally rough, you generally have a basic structure, but under that, you see a mess of pages at every levels. The information is often out of date and often redudant which creates noise even if you have quality pages (and even if you have a good search).
The plus side of a wiki is its accessibility. Committing a text file inside a git repository is a tough ask to none technical people. Asking them to "fork" and do a pull request is even harder.
But to maintain quality documentation inside a wiki, a dedicated curator is almost always needed.
It's also not in or near the logical path of code/product changes. You need to login into a dedicated system, find the page you need to change or where to add a new page and finally do the edit. It's kind of hard to have a systematic good documentation in such circumstances. Also, doing reviews and documentation versioning (in sync with product versions) is kind of hard with a wiki.
For all these reasons, I tend to prefer putting my documentation right next to my code in a markup language (simple Markdown README.md for simple projects, RST+read the doc for more complex ones, but that's a personal preference). You have far more incentive to edit the documentation, versioning is automatic, documentation versions are in sync with your product versions, review is easier (just include it inside the PR, same as code review).
The downside is less outside accessibility. It's also a very "low altitude" documentation, great for documenting individual libraries or components, it's not so great for things like documenting overall system architecture, or organizational stuff like processes, basically anything not tied to one specific component.
In the end, wikis have their role, but I found they are generally overused and miss-managed.
- with-point 7y agoI've also had enough with various wikis. And at some point we didn't find a decent tool for documenting our projects. We decided to build our own tool https://nots.io https://nots.io (yay NIH syndrome). The main idea is to make possible to link any type of doc like plain or markdown text, files, google docs right with the code. To give all docs a clear scope. And make it easy to discover what code is documented from the site or IDE. We also track the relevance of each added document. When new commits come in and the code behind the doc changes, we decrease its relevance factor (we call it the fresh rate), and let you know if the document is obsolete now. We have a demo (https://nots.io/demo https://nots.io/demo). Check it out, I'd love to get feedback.