Ask HN: How do you share knowledge/documentation?
4 comments
This is exactly what wikis are for.
I work for the mouse, and for each line of business we have a special wiki for everything about that product (hotel/resorts).
I work for the mouse, and for each line of business we have a special wiki for everything about that product (hotel/resorts).
I've edited the question to add ease of editing as a consideration since you've answered.
What kind of wiki do you use? I'd argue that something like MediaWiki is too hard to edit to the point that documentation will tend to fall out of date without anyone wanting to update it over time.
What kind of wiki do you use? I'd argue that something like MediaWiki is too hard to edit to the point that documentation will tend to fall out of date without anyone wanting to update it over time.
We use a really simple custom wiki. I don't know who/what team in the company made it, but the left side of the page is just boxes (headings) with links (subheadings). The main bulk of the page is an iframe (again, I didn't make it and not what I'd use) that loads the link clicked on (theory is to keep the url static and prevent linking to specific sections, again I'm not on this team). I can't share pictures for legal reasons, but my email is in the bio if you want to talk further.
Works extremely well, though. Non-tech-savy people can even fly around it, and people with a special cookie get editing rights. No need to over engineer it really, if it's just documentation you could even make a private subreddit and use the wiki feature there, giving editing rights to some users and preserving a commit-style edit history.
Even the Apple OS X (or what used to be called OS X) Server app has a wiki built in.
Works extremely well, though. Non-tech-savy people can even fly around it, and people with a special cookie get editing rights. No need to over engineer it really, if it's just documentation you could even make a private subreddit and use the wiki feature there, giving editing rights to some users and preserving a commit-style edit history.
Even the Apple OS X (or what used to be called OS X) Server app has a wiki built in.
not OP, but we have used dokuwiki (https://www.dokuwiki.org/dokuwiki) and it was very easy to deploy and to use. I like it, because it doesn't require DB engine, and has tons of useful plugins.
For most projects we deploy a static web documentation site. The content of this site is generated under change control by a select few publishers / editors.
Our reasoning is that documentation should be a "read mostly" resource. We prefer to vet and manage the updates with some manual processes. Might be sub-optimal, but the quality is high and erroneous / misleading changes can be easily rolled-back and then the re-edited versions re-released. However, most errors are caught in pre-release review stage.
Our reasoning is that documentation should be a "read mostly" resource. We prefer to vet and manage the updates with some manual processes. Might be sub-optimal, but the quality is high and erroneous / misleading changes can be easily rolled-back and then the re-edited versions re-released. However, most errors are caught in pre-release review stage.
Dropbox Paper because it support markdown and simplifies text formatting so you don't have 20 different font, and heading styles running around.
I use one of Google Docs, Confluence or Office 365
I'm curious to hear what solutions are used elsewhere and what has worked well (or not) in the past. The end goal is to have all our internal documentation (engineering, operations, sales, recruiting, on-boarding, etc.) in a single location that is easily accessible and searchable for all employees.