WebJunction

So you’ve decided that you want to implement a wiki at your library. Fantastic! Now you’ve got some decisions to make. While a wiki is free and democratic, that does not mean you can just throw it up online without some sort of planning and structure. You need to think about your audience, your wiki’s focus, the level of control you wish to exert over the wiki, and the software you wish to use. Here are some practical things to think about before you get started:

1. A wiki must have a specific purpose. You can’t just offer a wiki up to your patrons as a blank slate and expect them to know what they should add to it. Even when the wiki has a specific purpose, it’s good to create some sort of structure so that people will feel comfortable posting. Users can always post whatever they want and can change the structure of the wiki later on, but it can be difficult to get people to start posting without any structure. 
2. It’s also good to add some content to the wiki before making it public. Most people get nervous if they’re the first person posting to a wiki and they may be unsure if they’re posting the “right” sort of content. Even if there really is no “right” or “wrong,” people may need some concrete examples before they feel confident enough to add content.
3. Be very explicit in your instructions and disclaimers. You need to make the guidelines for adding content to the wiki very clear or you may get a flood of emails where patrons ask you to add things instead of doing it themselves. If it is a public wiki, you should develop a disclaimer making it clear that the library has not created all of the content on the wiki. This way the library will not be held responsible for the opinions of wiki users and the librarians will not be considered experts on every bit of content in the wiki.  Copyright is an issue that should be addressed both in terms of the license governing content on the wiki and content added to the wiki that may be restricted under copyright.   
4. Spam can become problematic on a wiki, but with enough loyal users, it will become a manageable problem. When I first started the ALA Chicago 2005 Wiki, I had to fix all of the spam myself, but once I had a community of users, other people usually fixed the vandalized pages before I ever saw them. The community really can enforce behavioral norms. Some wiki software also allows you to install spam filters that can help delete the spam before it ever gets onto the wiki.
5. It is nearly impossible to “break” a wiki. Spam and vandalism are not fun to find on your wiki, but they are very easy to fix. Most wiki programs save all of the earlier versions of each page, so even if the entire page is vandalized, it is easy to revert back to an older version of the page. This is also good news for nervous users who may be afraid of ruining a page. No matter what anyone does, it can always be changed back.
6. One important decision wiki administrators must make is whether or not to limit access to the wiki. Many wikis are open to anyone who wishes to read or edit the pages. Of course this gives free reign to spammers or malicious individuals whose only intent is to vandalize pages. Some wikis require users to register, which usually helps with any spam problems. Registering is a simple process that requires users to create a username and password, but it prevents spambots from simply putting content up on the wiki. While this will help to control the spam problem, it will not prevent malicious users. Other wikis are password-protected so only selected people can even read it. Obviously this measure would prevent malicious users or spammers from adding content. Password protection is only practical for wikis where the list of users is limited and known – like in group projects. For a community wiki, it would be difficult to give user names and passwords to every member of the community. The level of access restriction should depend on the type of wiki the library is creating and the level of protection they feel they need. It’s hard to find a balance between being as inclusive as possible and still protecting the wiki from malicious individuals.
7. There seem to be as many wiki applications as there are wikis. The decision of which wiki software to use depends on the features the library wants and the tech-savvy of the person or people setting up the wiki. Some wiki software is easier to set up than others. Most wiki software is written in PHP, but others are written in Perl, Ruby, Python, and other programming languages. Some wikis are freely hosted on the Web and have limited features. Others, all free to install, must be installed on the library’s server and usually have greater ability to be customized.  Here are a few options for your library:

Just remember, most of the decisions you make now are not irrevocable. You can always make changes later on. If spam becomes a real problem, you can change the permissions and require people to register. If you find that people are not using the wiki, you can change the focus, add content, or make your permissions less restrictive. The wiki can become anything you and its users want it to be. 

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.