Ask HN: Does your team use an internal wiki?
15 comments
We use Redmine[1], which has a wiki plus a whole lot more. We use the "issues" feature heavily as well as the wiki feature.
The non-technical staff use the repository browsing a lot - the engineers use SVN/git direct access... the non-technical staff only needs browsing access so Redmine covers that.
In the past, I've used Trac[2] as well. Redmine is heavily influenced by Trac, but at the time I made the choice for our company, Redmine supported multiple project a whole lot better.
In the more distant past, we used Twiki[3], which is wiki-only. It has a lot of functionality and is a nice wiki (I still like its markup best).
Twiki is very nice in that it keeps its pages as text in a repository (RCS when I used it, probably still). One thing that bothers me about Redmine/Trac/MediaWiki is that the pages are in a database so, if you have a problem with your Wiki, you have a very hard time getting your notes out of the wiki to see how you fixed it last time. :-/
A different engineering group at a former employer used MediaWiki[4] which obviously is a very competent wiki as well.
[1] http://www.redmine.org/
[2] http://trac.edgewall.org/
[3] http://twiki.org/
[4] http://www.mediawiki.org/wiki/MediaWiki
The non-technical staff use the repository browsing a lot - the engineers use SVN/git direct access... the non-technical staff only needs browsing access so Redmine covers that.
In the past, I've used Trac[2] as well. Redmine is heavily influenced by Trac, but at the time I made the choice for our company, Redmine supported multiple project a whole lot better.
In the more distant past, we used Twiki[3], which is wiki-only. It has a lot of functionality and is a nice wiki (I still like its markup best).
Twiki is very nice in that it keeps its pages as text in a repository (RCS when I used it, probably still). One thing that bothers me about Redmine/Trac/MediaWiki is that the pages are in a database so, if you have a problem with your Wiki, you have a very hard time getting your notes out of the wiki to see how you fixed it last time. :-/
A different engineering group at a former employer used MediaWiki[4] which obviously is a very competent wiki as well.
[1] http://www.redmine.org/
[2] http://trac.edgewall.org/
[3] http://twiki.org/
[4] http://www.mediawiki.org/wiki/MediaWiki
We use gitit [1]. It supports a number of syntax formats, including Markdown. It supports a number of revision control systems to use as the file store, such as git. I very rarely use the web interface, as I prefer to use the wiki from the command line, using vim for editing. Use of git also allows team members to easily clone the repository and use it even without access to the server.
Note that you can also edit text in Firefox textboxes with the editor of your choice using the "It's All Text!" add-on [2]. I have my browser configured to use gvim, so I can use vim to edit everything from emails and wiki content to this HN comment. :)
[1] http://gitit.net/ [2] https://addons.mozilla.org/en-US/firefox/addon/its-all-text/
Note that you can also edit text in Firefox textboxes with the editor of your choice using the "It's All Text!" add-on [2]. I have my browser configured to use gvim, so I can use vim to edit everything from emails and wiki content to this HN comment. :)
[1] http://gitit.net/ [2] https://addons.mozilla.org/en-US/firefox/addon/its-all-text/
Oh gosh, I've always wanted something like "It's all text", but I never bothered looking if anything of the sort
existed. This certainly removes the need for having to store the files on disk in such a way that they're
accessible to gvim, awesome!!
I've used Gollum (https://github.com/github/gollum) which is a pretty straight-forward little wiki and works well in a small company.
I discovered that apparently Gollum isn't very well supported on Windows (might be more specific to actually), but at least you can view the end-product in GitHub, if you can't run the server.
It can be very hard to get started with a wiki - content either isn't added, or isn't up to date, so people lose trust in the info in there. This has a negative feedback effect on people writing entries too. In addition, writing articles is hard as people feel expected (perhaps from wikipedia) to having to write detailed, canonical articles.
I have had success numerous times introducing an internal blog as a team knowledge repository, blogging anything interesting to it. With a search function, and making anyone an editor, it has many of the same features with a number of benefits:
- people can comment and ask questions
- signing up the development mailing list as an email subscriber ensures everyone sees new info as it is posted
- people blog about code issues, and tips and trick, not just 'how complicated feature X works'
Honestly, it works a treat. Blogging is the mechanism by which we share programming knowledge on the internet, why shouldn't it be the method we use inside our workplaces?
I have had success numerous times introducing an internal blog as a team knowledge repository, blogging anything interesting to it. With a search function, and making anyone an editor, it has many of the same features with a number of benefits:
- people can comment and ask questions
- signing up the development mailing list as an email subscriber ensures everyone sees new info as it is posted
- people blog about code issues, and tips and trick, not just 'how complicated feature X works'
Honestly, it works a treat. Blogging is the mechanism by which we share programming knowledge on the internet, why shouldn't it be the method we use inside our workplaces?
Interesting approach, thanks for sharing!
My team has an XWiki. It works well enough, and there are a number of plugins and things to get XWiki pages to update in vim or emacs through a Perl RPC library. I don't like it as much as Confluence (paid), but it's at least syntactically the same. The Perl library you use for scripting is actually the Confluence library.
Mediawiki is OK, but the granularity of access control isn't there for what you could need in the software world.
The corporate overlords use Sharepoint, and also some Confluence. If you host all your OneNotes online, you can have OneNote sync them. That might be your quickest way to share your tribal knowledge. This is an obviously short term fix because otherwise every new employee will have to add N synchronized OneNotes. I haven't found a way to import a OneNote into XWiki short of printing to PDF and importing again.
Mediawiki is OK, but the granularity of access control isn't there for what you could need in the software world.
The corporate overlords use Sharepoint, and also some Confluence. If you host all your OneNotes online, you can have OneNote sync them. That might be your quickest way to share your tribal knowledge. This is an obviously short term fix because otherwise every new employee will have to add N synchronized OneNotes. I haven't found a way to import a OneNote into XWiki short of printing to PDF and importing again.
Yep, we have a GitHub repo and use its Wiki quite a bit. (Along with shared Google Docs)
I actually just realized that you can clone the wiki hosted for each repo in Git onto your disk and just edit it
from there rather than having to do everything through the web interface. I think running the gollum server will
also host that wiki locally if for some reason you want to read it locally through the browser. That's pretty
neat!
My last two jobs both used Mediawiki in different capacities. The current company is moving from Mediawiki to Mindtouch. It is similar to Mediawiki but more geared towards corporate environments. The editor is completely wysiwyg as well.. no more markup which is great for the non-geeks in the company.
Our team uses dokuwiki, which is much more lightweight than mediawiki and serves our purposes quite well.
http://www.dokuwiki.org/dokuwiki
http://www.dokuwiki.org/dokuwiki
[deleted]
We use a wiki and it's very useful. We have even moved the project documentation to it from SVN.
We've used moinmoin, which is nice.
Can't use vim.
Maybe Dropbox for teams?
Can't use vim.
Maybe Dropbox for teams?
I was wondering if any of you had experience with setting up and running an internal wiki as a team knowledge repository.
My team right now uses OneNote to store all of our tribal knowledge in, It's however recently become quite inconvenient, as many of us are moving to either Linux or Macs. Bonus points if it uses a popular syntax such as Markdown. Even more extra points if you can edit the content through a good text editor like vim.
Thanks!