Would you need a wiki maintainer?
February 28th, 2011
According to the wonderful http://www.wikipatterns.com site, a maintainer is a person assigned or self-assigned to a page, space or section of a wiki who accountably takes responsibility for the quality of some of the content. The role may include that of a:
- secretary, collecting information from comments and meetings into the wiki
- refactorer, collapsing redundancy and inserting organization into a wiki
- solicitor, encouraging input from community members
- architect, categorizing pages, creating 'project' and 'overview' pages, assigning meanings to labels
While everyone will agree that this is indeed a vary valid wiki pattern, to actually get it off the ground may be an whole different matter. Let's focus on what we saw typically happen in organizations.
Wikis should be self-maintained
For some reason people seem to think that any sort of wiki organization is a bad thing. Maybe it is the myriad of open source solutions that exist for wikis, may be it is their inherently open editing nature, maybe it is just a sign of the times, but every time we try to get someone in the organization responsible for setting up and maintaining a subsection of the wiki, we get a big oh-oh. Like, how can you seriously consider organizing something as beautiful and organic as a wiki? The answer is simple.
Assigning a responsible owner for a section or a subsection of your wiki will help you move things forward. There are just some things that need to get done and you cannot rely at all times that 'someone will fix it'. The bad news is everyone will think everyone else will fix it. We've often advocated to use the wiki for meeting preparation, agenda setup and meeting minutes review and approval.
In our previous blog post on "50 tips to get your wiki up and running" we have shown following tip: The bad news is that these things don't come naturally. Even worse, when you leave things to organize themselves, you can be pretty sure all hell will break loose in no time. A simple set of rules for our meetings example:Acknowledge wiki (sub) section ownership
- All team meetings are in the wiki.
- The wiki organizer makes sure that the minutes are available max 24 hours after the meeting.
These can make sure things move forward.
Other examples of wiki pages that merit a responsible:
- Contact list.
- Requirements and specifications.
- Customer info.
- Knowledge base.
- Course schedules...
- ...
In fact most of the 'structured' wiki page content can be attributed a responsible.
Tip10: Beware the derailers.
October 6th, 2010
Watch out for obstacles, like someone who takes content out of the wiki and emails it around, or someone who organizes others’ work a little too much. Help these people understand how to use the wiki more productively so they don’t inadvertently hinder its growth.
This is probably one of the more difficult tips to implement. You got everything going. Wiki pages are being created and new revisions are added. But then there is the helpful person that takes it a step too far. Who wants to make it to perfect. Who would put any thing in the wiki just because.
What do you don't want in there?
Content that should not go not go in a wiki:
- Log files
- Mails
- Program code (other than code snippets that illustrate coding guidelines and alike)
- Copies of websites
- Database content
- Users posting content they don't own (without revealing their sources)
Wiki patterns and antipatterns
The great site WikiPatterns lists a number of patterns and antipatterns that respectively helps and hinders getting the best results of your wiki.
Although some of the content and some of the roles are a bit far fetched (who ever came across a wiki noob ) there is some ground in most of the (anti)patterns the site lists. Roles described on WikiPatterns are often not really identifiable with one or more persons. In reality all of your users (even you, the wiki maintainer) will suffer from time to time to one of the lesser productive wiki behaviors. It is important to recognize such behavior and correct it.
The result
Like everything else in live, nothing comes easy. It is a matter of constant correction, review, cleanup,... You (or someone else in your team) will need to spend time every so often to correct mistakes, put the wiki on the agenda of team meetings and lead by example.
Tip7: Trust me. Don’t excessively manage it.
July 21st, 2010
A wiki doesn’t have complex approval mechanisms for a reason. Trust people to write quality content and they will.
A wiki is not a publishing engine
In a previous live, we have worked for some years in the publishing industry. That industry has its particular processes for content creation, indexing, storage, retrieval, review and finally publication build. Quite easy to understand when you know that the final product need to be pushed out to professional printers that, after some final processing, print it in high quantities. The professional publishing industry now publishes much of its content online. The result is that its cycle time can be drastically reduced. Yet most of the processes still apply.
Approaching a wiki with a publishing background is a definite no-no. The wiki built in mechanics concentrate on a superfast edit/publish cycle. One key feature in this is the knowledge that all changes are visible, all author actions are exposed and, if desired, all mistakes can easily be reversed. This is what is called a game changer. In other entries in this blog, we have made the case that the wiki contains many of the publishing functionality in one neat, easy to manage and understand package. Content creation, linking, indexing, versioning, review and publishing are not only all there, but they also are contained in one neat package.
So yes, the wiki content is also 'content', pushing the 'save' button can be considered as publishing and the more advanced wikis even add auto indexing, keyword management and some sort of 'table of content' creation. One big difference is that the wiki is a two way process. The reader can adapt, augment, correct, complete the content that is proposed.
So how to 'manage' a wiki?
Pushing content out there and get the wiki 'the' reference source is the task you want to accomplish. Put all of your organization's knowledge on a place where you know you can find it if nobody can be reached. So focus on getting the critical mass in there and get your team into the habit of updating and maintaining the wiki regularly.
But after some time, 6 to 12 months in most cases, you will see that the self organizing capabilities of a wiki may need some gentle push or discrete clean up and restructuring. We have called it 'Spring cleaning' before suggesting that its frequency will be rather low. Typical actions you may take are listed below:
- Put the wiki cleaning and restructuring as a separate topic on the team quarterly meeting agenda.
- Use new projects or special events as the reason to add new content to the wiki and archive old pages
- Suggest searching wikis for specific problem situations that the team encounters. If your team finds it, see if it is still up to date. If not found, grab the opportunity to add a new wiki section.
- Don't hesitate to archive complete subsections of the your wiki. Add a section called 'old' or 'obsolete version' and move stuff over there. It will not be lost and you have made room for new and fresh content.
Know it will never be perfect, never finished
This is probably more a problem for some people than for others. Some people take hours or days before they are happy with the result of their content creation. Just because everyone can see what they wrote, they get stuck in polishing and re-polishing the content. They much rather not publish anything. One trick that can help is to just open the relevant pages during some meeting or some face to face talk, and just start editing. Taking notes on the fly. After the meeting you forward url's to the pages to the relevant people asking them to complete it.