4 ms·
The premise is wrong. The hard part isn’t the structure or purpose of the documents, you can do an ad hoc structure and just strive to be clear. The hard part
by coffeefirst 5y ago
The premise is wrong. The hard part isn’t the structure or purpose of the documents, you can do an ad hoc structure and just strive to be clear.
The hard part is the library. How do you organize all these records so they might be usable by someone two years later.
- shakezula 5y agoNotion has worked okay for us in the past, but recently we’ve moved to just using markdown documents in Git. It’s just as searchable, and stays closer to the code. RFCs et al. are submitted as PRs.
- titanomachy 5y agoI can heartily recommend Obsidian[0] as a way to augment "markdown documents in Git". It lets you cross-reference between your markdown documents using [[wiki links]] so you can start building a knowledge graph. [0]: https://obsidian.md/ https://obsidian.md/
- shakezula 5y agoI am already an avid Obsidian user but I absolutely encourage the promotion of it. It’s one of the first apps I install on any fresh machine.
- dllthomas 5y agoI find cross-references to be a big win. I've taken to using `@@{subject}` syntax as anchors and `^^{subject}` as references, anywhere in comments, docs, etc, within a single repository. Then I set up tooling that checks that every reference has a (single) corresponding anchor, and tooling that surfaces in github PRs the other relevant bits when an anchor or reference shows up in the (changed or context) lines of a diff.