Gollum – A simple, Git-powered wiki with a sweet API and local frontend
1–10 of 44 posts
Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend
#2I like the look of this a lot, particularly the support for running-from-local. I think git is such an ideal backend for something like a wiki, where multiple contributors and version history are both so important.
Tangent: how do HN folks generally do technical wikis -- or really, just keep track of the technical details of your software -- in large software development organizations?
My org uses Confluence for some stuff, Github pages and READMEs for others. It's... fine. It's not the worst I've ever seen, you can find some useful stuff with a little bit of work and some knowledge about where to look, but it's still very likely that whatever you're reading is either outdated or now-irrelevant.
How do you (and your team) solve the challenge of keeping documentation actually relevant and up-to-date when there are so many people writing so much code, then leaving two years later?
Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend
#3I like the look of this a lot, particularly the support for running-from-local. I think git is such an ideal backend for something like a wiki, where multiple contributors and version history are both so important. Tangent: how do HN folks generally do technical wikis -- or really, just keep track of the technical details of your software -- in large software development organizations? My org uses Confluence for some…
I always find Confluence to be the place where docs go to die. There's very little motivation to keep it up to date and tends to be one or two people driving it. When they move to another team or job, then it gets abandoned.
The things my team uses GitHub pages for tends to do better because devs don't object too heavily to writing code comments (for generated docs), markdown (for design docs), or API specs (for API docs). The last two in particular have become a big part of the design process, so it's been bought into heavily. Whether those stand the test of time remains to be seen - they're relatively new.
Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend
#4Interesting!
Isn't it better to couple the documentation of a project to the source (e.g. in a `docs/` sub-directory) and just use markdown?
Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend
#5I like the look of this a lot, particularly the support for running-from-local. I think git is such an ideal backend for something like a wiki, where multiple contributors and version history are both so important. Tangent: how do HN folks generally do technical wikis -- or really, just keep track of the technical details of your software -- in large software development organizations? My org uses Confluence for some…
We use self-hosted Readthedocs [0] with git/repo integration - merge to master triggers a build.
Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend
#6I like the look of this a lot, particularly the support for running-from-local. I think git is such an ideal backend for something like a wiki, where multiple contributors and version history are both so important. Tangent: how do HN folks generally do technical wikis -- or really, just keep track of the technical details of your software -- in large software development organizations? My org uses Confluence for some…
Gitea supports web-based wikis that are git repos on the backend.
It also has a good auth system and supports U2F (or SSO).
Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend
#7I like the look of this a lot, particularly the support for running-from-local. I think git is such an ideal backend for something like a wiki, where multiple contributors and version history are both so important. Tangent: how do HN folks generally do technical wikis -- or really, just keep track of the technical details of your software -- in large software development organizations? My org uses Confluence for some…
I always find Confluence to be the place where docs go to die. There's very little motivation to keep it up to date and tends to be one or two people driving it. When they move to another team or job, then it gets abandoned. The things my team uses GitHub pages for tends to do better because devs don't object too heavily to writing code comments (for generated docs), markdown (for design docs), or API specs (for API…
My problem with docs in repos is it isn't as smooth to edit, especially if you have to wait for reviews.
Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend
#8I've used gitit and it is pretty nice. Why do we need another one of these?
Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend
#9I like the look of this a lot, particularly the support for running-from-local. I think git is such an ideal backend for something like a wiki, where multiple contributors and version history are both so important. Tangent: how do HN folks generally do technical wikis -- or really, just keep track of the technical details of your software -- in large software development organizations? My org uses Confluence for some…
Notion.
Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend
#10Earlier quoted context omitted.
I always find Confluence to be the place where docs go to die. There's very little motivation to keep it up to date and tends to be one or two people driving it. When they move to another team or job, then it gets abandoned. The things my team uses GitHub pages for tends to do better because devs don't object too heavily to writing code comments (for generated docs), markdown (for design docs), or API specs (for API…
My problem with docs in repos is it isn't as smooth to edit, especially if you have to wait for reviews.
You can always just make the semantics of the doc folder or repo push permissions match what you're looking for, ie. 'no real reviews necessary to push to master' if that's the semantics you're looking for.