Wiki facilitation

This page is for gathering together tips for Wiki facilitators. Of course there are many different types and uses for Wikis, so it will be necessary to discriminate appropriately.

The tips here relate to community wikis not personal ones, and to the type where a reference or knowledge base is being built up by and for a community rather than the type which is temporarily set up for quickly allowing people to self-enroll to a conference or similar. A lot of the tips are of the form "don't do this".

Don't create too many empty pages
Have enough content at the beginning to show that at least you are going to participate. Laying down some skeleton page structures can be helpful, but don't take it too far. Creating an expansive empty structure is just presumptuous, doesn't really show any real intent to do things, doesn't give the project any real momentum. Small concentrated content is better.

Don't over organise
People like organising, and the people who do the organising are more inclined to feel closer to the project and contribute more in general, so by organising all the structure yourself, people won't feel so inclined to help out.

Don't do it all yourself
Easing back from making tempting wiki edits can help to encourage others to step in and get involved.

Plug away on the forum
Some people easily lapse into engagement on a discussion forum or email group without making the effort to extract the volunteered information and conclusions onto the associated wiki. That's where it's tempting to do it yourself, but a better strategy is to make a small nuisance of yourself by butting in and reminding them from time to time. Ask them to summarise a particularly fruitful discussion, maybe even suggest or set up a page name. Perhaps in time, one of the contributors who learns to appreciate the power of the wiki will take over this role.

One of the techniques a wiki facilitator can use to help get the community working together on improving a wiki is to initiate wiki projects.

The idea is to focus attention for a limited period on a particular section or set of pages which are considered to be in need of attention. I think the appeal is in the way this can bring together people who enjoy making contributions by editing pages, with others who have spotted work which needs to be done. The identification of a small task as part of a group project apparently makes it more likely that it will get done sooner, or perhaps just more satisfying when it is done, because the progress can be monitored.

The Wikipedia community have formalised this and provide tools for identifying pages which have been deemed part of a project, in the form of project templates.

Andy Roberts initiated a small project for the ukcider community wiki looking at under represented counties, and found it to be a successful technique which added value by combining efforts and collaborating on the creation of additional new content.

Initiating a FAQ on a wiki can be a good barn raising activity.

On Barn Raising again

but see also multiple page FAQs

Further discussion on ACTKM mailing list:

I'm actually taking real Q&As as they arise in practitioner discussions, copying them into a wiki page and encouraging others to do the same. Some members like to add bits directly as well.

software help FAQs

Luckily the domain I'm working with has nothing to do with software. It's agriculture, chemistry, craft cider making. When I try to access software helps myself, I always seem to get lost in the largest section of all, the bit which tries to tell me how to use the help system rather than how to use the software. That way, madness lies!

complex FAQ design
Jack Vincent suggested:

For a possibly too complex system, I'd suggest each FAQ should be an
individual entry with the Question-Answer pair. Each entry should get
meta-data that will let a display engine group items based on common terms.
I'm thinking of tagging, but this could just as easily be a hierarchical
taxonomy of some sort. My goal here is that a given FAQ entry could be
categorized in several buckets. Why not set up a system that allows that
from that start?
Thanks for explaining that one, it's a very good system, although as you say, possibly too complex, I could relatively painlessly I think, convert over to that method and may well do so yet. The mediawiki software allows for multiple tagging of pages, creating a semi-automatically derived taxonomy out of the folksonomy, and I've already used such a method on another project ( )

simplest way that works
My reticence in the case at hand though, is to do with wanting to facilitate the maximum amount of user contribution. A wiki is supposed to be based on "the simplest possible way that works" and yet a majority of ordinary users are still reluctant to make edits, thinking that they need to have training or permission or special skills before they will dare to click on that edit button and type something. It still puzzles me as to why that is the case, but it is.

user preference for adding to existing formats
One thing I have discovered, is that, apart from regular users, people will much more readily edit an existing page, following the format of a previous entry in front of them or extending it, than they will create a new page starting from blank, as it were.

( How should this pattern be named? )

I put the needs of the FAQ writers first, maybe that's wrong, I'm not sure.

Anyway, the wiki based FAQ has grown organically up to the point where the single page is deemed to be too long, which is quite a nice problem to have really.

If you were trying to find an answer would you prefer to scroll down through a long list of questions until you found one similar to your own problem, or to click through some kind of index of tags? My guess is that we should try to provide both ways if at all possible.

Top 10 FAQs
David Jaques-Watson suggests:

Another idea is to display the "top 10" FAQ's separately
(i.e. at the top of your FAQ, or as a set of links, or even
on a separate page). If your system allows programming, and
you can dynamically access the site statistics, you could even
set up the list to be generated automatically.

Now that is a very useful suggestion indeed. "Most Frequently Asked Questions" is a pattern which naturally extends the usefulness of the FAQ concept when it gets very large. I shall store it away for use at a future stage. Thank you very much.