As a nerd by nature and occupation, I spend a lot of time writing documentation, procedures, HOWTOs etc.
Even in my own personal life, I've found that I often default to writing up the steps I took to do a thing, or recording recipes, or recording IP addresses of my various home network devices.
Over the years, the way I've recorded these things has changed.
I've used plain text files, spreadsheets, various databases, raw HTML, SharePoint Server, self hosted copy of MediaWiki (the software that runs Wikipedia) and used to build those.
The problem with a lot of the various solutions I've used over the years is that a lot of them have "high friction" The effort to manage and maintain them made them less than optimal.
The best thing about writing documentation/knowledgebase articles in a Wiki ist that the wiki (at least WikiMedia) makes it incredibly easy to cross-link to other topics nearly effortlessly. So you just start writing and any time you mention a topic you think should be also an article you can just [[wikilink]] it. If there is already an article with that title, it just links to it. If not then the link will lead to a "create this page" when you click on it.
After years of hand-coding HTML, the experience of writing wiki articles where I could just concentrate on the content and leave [[placeholders]] for later really spoke to me.
Microsoft SharePoint Server also provided a somewhat seamless way to get knowledge and information in as well, though the offered "WIKI" functionality (at the time I was using it) was really a poor substitute for a real MediaWiki instance.
However, the down side of SharePoint, and databases and even MediaWiki was that while the friction of data going in is low, friction going out - moving out / away from them is difficult.
Microsoft SharePoint Server) is actually kind of notorious in some circles for being "super easy to get into but a nightmare to get out of" when you want to export your data / migrate elsewhere.
MediaWiki isn't intentionally so but when you've spent a lot of effort creating templates and categories and transclusions etc, the articles and data are stored within a fairly well normalized database, and extracting / migrating out is far from straightforward. If your MediaWiki or SharePoint instance gets corrupted or crashes, you might be really stuck. Yes, any sysadmin worth their salt will have backup / disaster plans, but I know as a one-person shop, the knowledge needed to really be one with the application and seamlessly backup and restore... well, it's a use it or lose it kind of skill, and I don't have a lot of spre cycles to practice that regularly.
So, what's the solution?
Thats where I have doubled back close to text files. Text files are human readable and are really cross platform compatible in the extreme. However, they lack any type of formatting and are not very searchable on their own (yes if you have grep-fu you're golden but lets be realistic here). So Markdown solves the formatting issues nicely. Markdown is intentionally simple - it's a deliberate alternative to so called "markup languages" like HTML and XML. HTML and XML have their places but they're not very human readable when viewed raw
Markdown strives to be useful for parsing by a suitable viewer but retains high human readability.
This very article is written in markdown. I wrote a blog tool that applies my web site header and footer, lists articles and parses the markdown into HTML. But for my knowledgebase articles I don't need that fanciness. I do however need searching and management.
I found a tool called Obsidian which provides a framework to make what it calls "vaults" (set of folders with related content) where it provides excellent search and graph capabilities as well as providing a rendered view of the markdown (semi WYSIWYG when editing, full rendering in view mode).
This is really what I've been looking for. It lets me write without letting focus on layout / format get in the way, It also handles wiki-like linking (though it does need an actual existing article to link to - but not bad). I can search but use the vault structure to isolate different areas.
I have now set up vaults for Knowledgebase (various HOWTOs and info about tech stuff like server configuration, procedures, templates etc...), Recipes for cooking, Recipes and knowledge for my whipmaking hobby, and a vault for my blogs and rants and other creative writing to help me organize my thoughts and article ideas.
Obsidian is great and since the files are human readable even without it, I can pop the files onto a memory stick and bring them with me when I travel... Except if I get a wild hare and want to update one ... If I update one of my markdown files while traveling then I risk getting out of sync - remembering to back-update etc.
So, the last piece to the puzzle was to use GIT to add my vaults as private repositories on my git provider. Obsidian even has a very helpful GIT plugin. So now any time I have one of my files open and want to make edits, I do so, check them in, and push back to my repository. I can do this home or away and in the rare instance I manage to "step on" the same file from two different places/times the merge tools in GIT can save my bacon.
So, now, I use Markdown whenever I'm writing a document or formatted document. Even if I will eventually end up using something like LibreOffice Writer to do more extensive formatting, the base writing/content goes into a markdown file in one of my vaults, and gets pushed to a private repo so I can always access them.
I even use my .gitignore file to specify certain files that have super sensitive info (passwords, account numbers etc) from being included in the cloud repo (takes a bit of managing but well worth it for security)
~DigitalSorceress