Wiki best practices
I am on the excellent Refresh Cambridge mailing list and another member asked for advice about wikis. I gave a long reply and a few people recommended that I share it with others.
First, there is the question of which wiki to select. I have a strong preference for open source wikis to minimize vendor lock-in. If you ever do decide to migrate to another wiki vendor in the future you are more likely to succeed if you began with open source software.
MediaWiki is charming but the user interface is too uncomfortable for most people, especially the subject matter experts you want to do the most writing. The advantages of open source are outweighed by the usability issues. On the other hand, I have heard someone cheekily saying that the reason the Wikipedia is still high quality is that its MediaWiki software puts off authors below a certain intelligence.
Socialtext is a brilliant open source wiki, but installing your own version is hard and pricing is for enterprise customers. So I personally like Deki Wiki because although it is open source, the user interface is Microsoft Word-friendly and administering the software is very easy with their hosted version.
By contrast I hate Confluence because it is a massive proprietary content management system, and because its user interface encourage each author to make a large stand-alone office document rather than richly interconnected web pages. This habit is pernicious and difficult to reverse so you must be vigilant early on in a deployment to teach everyone the value of interconnected web pages.
At any rate, I regularly use all four of these wikis and I know that I am in the minority in my aversion to Confluence. I would never choose it, but I can see that great results are possible with.
So how do you get great results with a wiki? Here are nine tips from my experience:
- Everyone in the group must commit to using the wiki, and to the wiki being the version of record. It is dispiriting for junior people assigned to write on a wiki to see the real decision makers discussing elsewhere and to understand that none of the seniors will use the wiki.
- To get that commitment without a big change effort, it is better to have everyone in a small group of ten using the wiki than it is to have a couple of people from each of five groups doing so. The good folks of Common Craft have an excellent video explaining the advantages of wikis.
- Have your debates about the contentious issues on the wiki, for all stakeholders to see, not in private conversations, and resist the temptation to make private decisions through messages between insiders in your group
- Everyone will have their own excuse for keeping material away from the wiki, often citing “security”. But in general, most people’s bias is towards under- rather than oversharing, so there needs to be a strong champion who has the opposite bias.
- Use the wiki to take minutes of any meetings you hold. Have someone in charge of writing the minutes during the meeting, with the output projected on the screen. A lot of misunderstandings are cleared up that way as people can see straight away if they have been misunderstood and can make correction there and then with the group watching and learning.
- A wiki is not a reason to have no meetings, rather it is an easy way to have a version of record as decisions are made in these meetings.
- The best thing about Socialtext is that it sends everyone a daily update by default. This seems a subtle difference but it really motivates everyone else in the team to see a message of what their colleagues did the previous day. If you use a different wiki, switch to this default.
- To get over the initial period of colleagues who do nothing in the beginning, make sure you write something every day so that your colleagues feel guilty enough to do start doing something.
- Instead of answer e-mail questions and then trying to summarize the consensus on the wiki, write your thoughts on a wiki page and then send the link to everyone else you want to have a consensus.
A final note about my first comment about junior people being assigned to write on a wiki. This is both a strength and a weakness. I like to show juniors that contributing to the wiki is an excellent way for them to learn about the organization, and to show the organization how much your are willing to contribute to its success. On the other hand, if you give out signals that wiki work is of minor importance and that is why you are parcelling it out to junior people of minor importance, you will get an unused and useless wiki.
People get the wikis they deserve.