Around the places I work (and the non-profits I work with, too) we use Atlassian’s Confluence wiki software. With Atlassian offering $5 licenses for Confluence and Jira through the end of the week I thought it’d be a great time to write about how we use our wiki.
We love wikis because:
1. They let us easily add & maintain documentation. Let’s say that someone finds an error in a document I wrote (it happens). With old static documentation, like HTML, someone would need to find me and tell me how to fix it. Then I’d need to actually fix it, and re-publish it. With a wiki the person who finds the problem can click “edit” and fix it themselves without using two staff members’ time.
2. I can tell who edited what, and what they changed. When I discover that someone changed my document I can tell who did it, when they did it, and I can compare their version to my version to see what changed. I can also “watch” certain documents so I get notified when they do change.
3. Meeting agendas are easy to maintain. Need something on the agenda for the weekly team meeting? Add it yourself. Likewise, during the meeting I can take notes right in the meeting agenda page, and avoid needing to transcribe my notes later (if ever).
4. I can integrate other media, like mailing lists, calendars, and checklists, with my documents. Many of the teams I work with have a web presence, a documentation repository, and a mailing list. A wiki like Confluence can pull all those together into a single searchable archive. Where was that list of servers with expiring warranties? Email? Wiki? Who cares — just search for it. Need a checklist? Just create one as a wiki page. Need a project calendar? Just use the built-in calendar plugin.
5. No more format fights. Some of my coworkers insist on using text files for documentation. Some use text files with RCS. Some with CVS. Some with SVN. Some do the same with HTML. Some love Microsoft Word. Some use OpenOffice.org Calc, or Excel. And with Excel are you saving as .xls or .xlsx? ARGGGH. The wiki ended all of those format fights, especially since tables can have sortable column headings. Additionally, we licensed the Gliffy plugin, which lets us do basic diagramming right in in a wiki page. No, it isn’t as powerful as Visio, but most of the time we don’t need all that power, either.
6. No more document storage fights. Before the wiki we had documents in home directories. In with applications themselves. Out on the file server shares. As HTML. On desktops of servers. On desktop workstations. It was a mess, especially when someone was out of the office and we needed that data. Now we have a single place for our documentation, which gets backed up centrally, and is easily searchable.
7. While wikis are best when open, sometimes you only want to open them to a few people. Confluence has a permission model that lets you give some folks access and keep others out. It also has good anti-spam features to go with the discussion features, too, including methods like CAPTCHA.
Atlassian has always offered limited-time evaluation licenses, but for us it’s taken over a year to really get all of the different parts of our organization into using the wiki. A $5 renewable starter license for 5 users is a great, zero-risk way to get started with a world-class wiki application, especially for a small IT department. Heck, you also get support, too. The same goes for Jira, a great issue tracker that integrates with Confluence. All in all, something you probably shouldn’t pass up.
I couldn’t agree more. Our Twiki-based operation documentation goes back to 1999/2000’ish. And yes, it has tracked all changes since day one.
Just make sure you have a DR/BCP plan for the docs. 😉
Are you using Confluence?
Thanks for the mention of Gliffy. We are glad to have enhanced your wiki experience. Let us know if there are ‘power’ features you find yourself wishing we had —
best,
debik at gliffy dot com
Michael — yeah, a new DR/BC plan for the docs is actually in the works. It needs to be the first thing recovered, after all.
We are using Confluence and have been very happy with it.
I still like to refer to “The Wiki” as a fantastic information hiding tool. Used improperly (say, for example, to hold Word, Excel, Powerpoint and Visio docs as attachments to a page), or just not well cross-linked (or overly structured), it’s a great place to put something you don’t want to be “public”, but that you want to have plausible deniability if what you are up to becomes “public” (“I published the plan in the Wiki, you could have read it there!”).
But, I’m probably just being bitter.
jon
Jon, if it were up to me that sort of behaviour would be banned from wikis. It’s mainly done by people who are ignorant of the way a wiki is supposed to work.
I do understand that sometimes there’s no better way, like a MS Project file that you want to share. Usually there is a better way, though.
Bob,
How do you do/set/structure it for the meetings? How do you track the updates for the various project efforts going on that you are talking about in the meeting?
I’m using a wiki (evil evil sharepoint version – no choice) and we are starting to move towards using the wiki for meeting notes and I’m a bit stumped on how to organize this that doesn’t waste effort/time.
Ian — for the meeting itself we just usually create a page with the meeting agenda, and we name it in such a way to avoid namespace collisions. So “Agenda – 4/27/2009” becomes “System Administrators – Agenda – 4/27/2009.” On that page we just make an ordered list of what we want to talk about. I’ve also seen it done as a table, agenda items vs. notes.
Projects may have their own wiki pages where status is kept, in a “Projects” section we have. Otherwise status is just reported as part of an agenda item. If I’m running the meeting then I just put the status report in the notes under that section of the agenda.
We’ve changed how we store agendas & notes several times in the last couple years. I’d suggest making it a topic for discussion after you’ve been doing it a little while to see whether people like it or not, and if complaints can be addressed.