Ask HN: As a team, how do you organize your KB/documents?
4 comments
Generally, a wiki, usually (though not always) internal / accessible via VPN, though increasingly publicly hosted.
I've used, implemented, and/or administered: Twiki, Atlassian Confluence, Mediawiki (the Wikipedia engine), and others. My general preference is for tools which are already well known and supported, with Mediawiki scoring well on these grounds.
Simply accumulating documents does not constitute a knowledgebase.
The biggest problem is that information ages, it's hard to correlate with other information (so your KB becomes inconsistent over time), and you need to edit, prune, and review. Failures of KBs to remain current indicate a problem of process not of tools, and must be remedied by changes to process, not tools.
I'm increasingly partial to systems which support creation of a book-type document, rather than merely an accumulation of articles (though there may be a place for both). In particular, a lightweight markup (my preferences are LaTeX or Markdown), a solid outline, and a regular review process, are probably a best-practice approach to this specific problem.
What I'd really like to see is a system which marries such an approach with conversations (effectively: a mailing list) and issue tracking (BTS or similar), and which allow for publishing a specific point-in-time document with revision control: PDF, HTML, ePub, etc. The latter are particularly useful as they allow for creating and distributing offline copies of documentation which can prove useful in circumstances in which online access isn't available or convenient (e.g., the server / colo / network has melted down).
I've used, implemented, and/or administered: Twiki, Atlassian Confluence, Mediawiki (the Wikipedia engine), and others. My general preference is for tools which are already well known and supported, with Mediawiki scoring well on these grounds.
Simply accumulating documents does not constitute a knowledgebase.
The biggest problem is that information ages, it's hard to correlate with other information (so your KB becomes inconsistent over time), and you need to edit, prune, and review. Failures of KBs to remain current indicate a problem of process not of tools, and must be remedied by changes to process, not tools.
I'm increasingly partial to systems which support creation of a book-type document, rather than merely an accumulation of articles (though there may be a place for both). In particular, a lightweight markup (my preferences are LaTeX or Markdown), a solid outline, and a regular review process, are probably a best-practice approach to this specific problem.
What I'd really like to see is a system which marries such an approach with conversations (effectively: a mailing list) and issue tracking (BTS or similar), and which allow for publishing a specific point-in-time document with revision control: PDF, HTML, ePub, etc. The latter are particularly useful as they allow for creating and distributing offline copies of documentation which can prove useful in circumstances in which online access isn't available or convenient (e.g., the server / colo / network has melted down).
Google sites can work well, especially if you use Google docs. You can customize the UI to suit your needs, and organize into any kind of hierarchy you want. If your team is working with Gdocs for their actual day to day, the site content can update as they do it (almost), so eliminates the issue of a dead zone wiki. There are a lot of widgets available, so pretty easy to get a 1st version up.
Sharepoint. It creates internal web sites much the same way that MS Word emits concise, elegant html.
Ugh.
Ugh.
I create "intranets" (they are on the internet technically) for my teams using google sites. Its easy and have found it fairly easy to maintain permissions and manage the content.
I have a pretty bad experience of using Wikis, which are most of the time out-dated. Trello's lists appears to be too limited. And simple Dropbox/GDrive shared folders' hierarchy lack of homepage/cross-reference/UI.