Accelerated Authoring™ @ Method M

Following the previous post on Wiki’s in documentation, and some off-line discussions, here is Reichman’s Rule for When Wikis Work for Technical Documentation:

1. Trust.  High degree of trust that people who edit the Wiki will not sabatoge or contribute nonsensical content (or worse).
2. Tolerance.  Many contributors and editors mean that the quality of the writing will not be perfect and will not be consistent.  Our take — don’t worry about it.
3. Critical mass.  If the number of contributors/editors will be very low, then a Wiki will not pick up the critical mass to attract users.
4. Incentives.  What incentives to developers, users and other staff have to contribute to the wiki?  If the answer is none, they won’t contribute.  Make sure to build-in incentives.
5. Confidence.  It takes a confident technical writer to “let go” and open up his or her documentation to Wiki. If you think that the best way to function in the workplace is keep your head in the sand and take no chances, then don’t do a Wiki.
6. Medium to low critical path.  If the cost of an error is very high, I’m not sure that Wikis are a good idea.  Of course, the error might be caught and corrected, but if we are covering nuclear power plant operation or brain surgery we don’t want to leave open this window of opportunity.

More to come on Reichman’s Rule for When Wikis Work for Technical Documentation – but looking forward to reader input here.

Katriel

This entry was posted on Sunday, April 29th, 2007 at 10:17 am and is filed under structured authoring, technical writing, technical documentation, wikis. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.