Effective Wiki Model

Effective Wiki sites don't just happen. They require the careful attention of someone who understands human nature and has a good picture of what works. This page hopes to promote such knowledge.

About this page

Original author: SteveDavison.

The aim of this page is to establish one (of many) effective model for using a Wiki, and to document the model well enough that others can easily benefit from the information. Hopefully it will also support the implementation of some new features that this model holds as essential. While the focus (at least in the beginning) will be on the documentation needs for a medium to large sized corporate group (how is this defined??), I believe that most of the principles apply to a much larger audience, and in fact I hope to identify those principles that apply to just about any Wiki application.

During its initial development, I will keep this page under my homepage, but eventually it can find a home as an article or discussion page for the general MoinMoin audience.

Philosophy Statements

These statements embody the power of a Wiki, at least within the scope I'm trying to address here.

• The wiki state of mind is, to many people, a very foreign concept. It takes time to shift people's thinking to align to this.
• Some people are naturally wiki-inclined, and some people aren't. A wiki needs to cater to its desired user base as a whole, which means that it probably needs enough help and new user information to guide the non-inclined in the right direction.
• There are various levels of contribution that can be made by a user, and the most effective wikis will support all levels.
  • Organized, complete, and well-written subsections of a wiki, primarily for documentation and how/to. This will be contributed by gifted and organized writers, and/or those who have time devoted to making there work of art come true. This is the rarest form of contribution (by a single user)
  • Organizing and refactoring what has already been written
  • Rewriting and consolidating content that is hard to understand, or is scattered enough that it users can't easily get a good understanding of particular concept.
  • Writing "island" articles... ones that are basically complete on their own and do not currently fit into any existing or structure of pages. Or perhaps it could, linked in with some existing pages, but those are not well organized or the writer doesn't want to deal with it for whatever reason. (This is one of the easiest ways to get people to contribute highly useful information, because it's not complicated.) It will usually be a root-level page with a fairly long title, like an article.
  • Submitting terse bits of information on a new page
  • Creating "stub" pages for information that should be in the wiki, but is not. Most soften these omissions are discovered by those not qualified to write the page, because they were searching for information they did not know, but could not find it. Hence the stub page. Hopefully the page will contain a few questions or bullet items stating what is wanted on that page.
  • Correcting errors on a page, updating stale information, or adding missing info.
  • If someone lacks the time or knowledge, simply noting on the page that ther is wrong or missing information. To a newbie, just seeing a comment that something is wrong/out of date can be very helpful in and of itself, even if the page does not have the corrected information yet.
  • A "page comment", homepage message, or email requesting that certain information needs added or updated.
  • A review of new content by an expert to ensure its quality
  • A rating of how useful an article was.
  • When someone has difficulty finding the information they needed, alter the page title or contents so that it will match better on the search words they thought to use.
  • Oversight and periodic review of page titles, content, conventions
  • Promoting the wiki, educating people how to use it, and organizing experts in various areas of expertise to assist in reviews and promotion.
• People are busy, and contributing takes time. Promote an environment that makes it OK to contribute whatever you can in whatever time you have.
• A good analogy for how to build a wiki is sliding down a snow-covered slope on an inner-tube or dish-type sled. The first time you only get a couple of feet, because the snow is not packed. That's OK. The next person will use the snow you packed and will get farther because of it, but they also make their small contribution which will allow the next person to go farther. This way, every person only spends a little bit of time contributing when they encounter the limit of what is in the wiki, and they trust that the next person will do the same. Don't worry that you don't have time to make it "complete" (whattever that is), just do your best to make it a little better.

• There must always be some amount of someone's time devoted to maintenance and policing of the wiki. If no one has time to monitor RecentChanges, provide guidance to users, handle organization dilemas, etc., the wiki will probably go stagnant or fall into chaos.

• If a user is ever frustrated, there is something that needs to be fixed. In rare cases, this amounts to nothing more than educating that user. Generally, if someone gets stuck or cannot find the information they're searching for, it is because something in the wiki needs improvement. Content may need to be added, or pages may need to be linked better, or wording changed so that it comes up when the user searches. To achieve the most effective wiki site, someone needs to be monitoring the pulse of the users, and listening to what they have to say.

Changing the Culture

To have an effective wiki, much of your work may be in the area of social engineering.

1. Spend some time defining the ideal end-state for your wiki
2. Create an expectation of this end-state among your users.
3. Also communicate that the wiki will never completely reach this ideal state, but it is up to everyone to help it move in this direction.
4. Define the process that a user should go through when they discover that the wiki is somehow imperfect.
5. Put systems and processes in place that will support the incremental process of improving the wiki.
6. Always have a last-resort fallback plan for users to easily give feedback. If the user cannot find the "correct" channel for their comments, questions, complains, etc., then there still must be an easy way for them to be heard.

Requirements

• A good Wiki engine. Specifically, must support the following capabilities:

• Effective email notifications. MoinMoin goes a long way towards this, but could still use a number of improvements.