To learn about the basics of wikis, see TechSoup’s article Exploring the World of Wikis
Tools for editing:
wikis generally let you edit the information on web pages in one of two ways. Some allow you to use a WYSIWYG editor like that in Microsoft Word, which allows you to click a button to make text bold or italics. With this type of editor, your view of the text while you’re editing is more or less the same look as what the all the readers will see. Without a WYSIWYG editor, you’ll instead need to use what’s called a markup language.
Well, I can’t say that I’ve spent significant time using more than a handful of wiki engines, but I’m familiar with MediaWiki , DokuWiki, PhpWiki, and Confluence . For my needs, Confluence is the clear winner—it’s got an extremely clean look, is absolutely packed with features, stores content in a database of your choosing, and has a dead-simple markup language. Confluence costs $1,200 for an installed version or $50/month if they host it, but non-profits can get it for free.
One thing the other three offer that Confluence does not, though, is open source code – the ability to freely update or distribute the code in most any way you like. Though you can get your hands on their code if you actually pay for Confluence, you cannot re-use the code in any way other than modifying your version or contributing macros and bug fixes to the Confluence community. The other three all use versions of the popular GPL open-source license and are supported by large, active communities of open-source developers and users.
All four of these wikis require expertise and access to a server to install. To get started quickly and with minimal technology overhead, a hosted solution may be better. Two popular hosted wikis are PBWiki and Wikispaces, both of which have a free version with some limits. An upgraded Wikispaces account is available to nonprofits through Techsoup Stock . Google has recently released Google Sites as part of its Google Apps suite, based on the Jotspot hosted wiki service that they acquired. If your organization is already using the free nonprofit edition of Google Apps, Google Sites is an easy way to get started with a wiki that will be integrated into your other Google Apps services.
Don’t forget to consider the software you already have, either: if you’re using a higher-end content management system to manage your website, like Plone or Drupal, these systems may also offer strong, wiki-style collaborative documentation features.
For more wikis, and much more information, WikiMatrix.org will let you compare a hundred or more different wiki engines. Each wiki is rated on over 100 features. As with any software application, different wikis will be more or less appropriate for different uses.
Once you’ve chosen a wiki engine, you still have a little work to do before you can start writing your pages.
If you want, you can certainly make your wiki open to all comers, like Wikipedia and WikiHow. However, your organization’s procedures, while likely not top secret, are probably something you’d like to keep reasonably private. It’s easy enough to lock down any wiki in its entirety. The real security question to ask yourself, though, is how granular you’ll want your security controls to be. Do you need to be able to lock down individual pages? Do you need security groups, which will enable you to change security settings for a bunch of users at once?
It’s important to define who will create and maintain the wiki information – your documentation. You can, of course, have one person at your organization create all of the content. However, that would ignore the strongest offering a wiki has: the ability for a group of people to collaborate on the creation of content. Letting a larger group create content doesn’t just spread the work out among more bodies— it also allows you to take advantage of more brainpower.
You’ll also want to determine a basic outline for how your content will be organized. This process will likely include a cross-departmental conversation about what should be included in the wiki and how it should be structured. Of course, if you want to start using a wiki in just one department and let it slowly grow to include other departments, you wouldn’t be the first one!
Although it’s a good idea to have as many staff members contributing content as possible, it’s best to choose one person to oversee the organization of the wiki as it grows. This will be an ongoing, active role—your original outline will be a good start, but because wikis allow many to contribute, things will tend to stray from the plan from time to time. The person who does this work, trimming one branch of content, planting the seeds for what will turn into groups of pages on particular topics, is called the wiki gardener . Really!
The last thing to do before opening the floodgates to the whole organization is to ask a small group of people to create as many pages as they can—seeding your wiki with a few dozen truly useful pages will go a long way toward convincing the rest of the team that your new wiki is an important place for both gathering and sharing knowledge.
Jeremy Wallace has worked with both non-profits and technology since 1995, mostly focusing on databases, though lately he’s gotten the impression that the internet might just take off,and he has started helping non-profits with their web needs. He has worked for TIAA-CREF, the Fund for the City of New York, the Center for Family Life in Sunset Park, the Education Trust, and many non-profits as an employee or contractor. Jeremy is currently a project manager at PICnet, is the Director of Operations at Writopia Lab, and still keeps his consultancy alive at ABCDataworks.