This page builds on a post from 2010 called “Wikis are not Documentation,” but discusses the use of wiki(s) in two contexts:
The “wiki method” promises better information use and maintenance because the software promises easier editing workflows that conventional web pages and management systems and because wikis like c2 and wikipedia provide powerful case studies for successful “community Authorship Issues and Information Debt” where large groups of contributors build a generally useful information resource.
In truth there are a number of problems with using actual wikis for larger scale information resources, given common editorial resources. This wiki pages provides an overview for some of these challenges and suggests possible solutions.
Pages in an information resource often need to be “living:” updated regularly, changed to reflect changes in the topic matter, product, or the state of the art.
If pages are not reasonably atomic, it’s possible for the information to “rot,” where it looses internal consistency and where revisions–even major revisions–must happen in a rolling fashion. Combined with the diffusion of responsibility and the general lack of wiki-wide tools for editing, managing, and structuring the information resource, these problems make it difficult to use wikis for many classes serious information resources.
While wikis themselves push you to think about content on a page-by-page basis, to avoid information rot you must approach the totality of a wiki. Typically this means, having a dedicated person or two writing, editing, and organizing content. Like any other serious sufficiently complex “living” information resource.
(`I’ve written about wikis a bunch on tychoish <http://tychoish.com/ikiwiki.cgi?P=wiki>`_ before, and most of the posts address some aspect of this problem. In truth, I think my earlier have been a bit scattered.–sam)
Too often people link two facts to each other: first that Wikipedia is wildly successful, and second that Wikipedia is a wiki. To compound this problem, the community of editors behind Wikipedia is largely transparent to the people who read Wikipedia.
The result is that you look at Wikipedia, say “We need one of these for our project,” without realizing that there are anywhere from a dozen to thousands of people writing, organizing, editing, and verifying the content on Wikipedia. In truth, the amount of rote work involved in wikipedia is astounding, and I’d venture to speculate that the entire venture is a bit inefficient and only really viable because it’s a non-profit project and the contributors are all volunteers.
If you’re working with a small team, a team that has other projects than maintaining a wiki, an editorial team that’s a significant subset of the user/read community, if your editors are your SMEs,[^sme] and you start a wiki without a plan: you’re probably already in trouble.
[^sme]: Subject matter experts.
Consider using wiki methodology without wiki software.
I think it’s important to separate the methodology from the actual software. Both have their flaws and disadvantages, but there are some cases where wikis make good publishing systems (i.e. tychoish – Visits, Modes, and Forms is a wiki.) Furthermore, the core of the wiki method (i.e.e “get everyone in a project involved in authorship,”) has merit, even if the actual implementation in wiki software isn’t often productive.
Fight diffused responsibility. Provide structure, and attention to contribution to ensure quality, encourage efforts, and provide consistency.
Approach information resources systemically and holistically.
Use appropriate bucketing to provide good, manageable organization of pages.