Encouraging participation in the wiki world

David King is in the middle of a terrific series on his blog about inviting participation in Web 2.0/social software tools. Here are the ones he’s come out with so far:

• Inviting Participation in Web 2.0
• Part 2: Passive Invitations
• Part 3: Active Invitations

Check out the comments too where people are making some great suggestions!!!

One important point he made was this:

In library-related articles, blog posts, and presentations I’ve attended and/or read this past year, the presenters/writers have been saying that Web 2.0 and Library 2.0 are all about starting conversations, building community, and telling our stories. But the writer/presenter tends to skip over what I think is the most important part – they never explain how to do it. Instead, they continue on with the next Powerpoint slide or paragraph.

I’m just as guilty of this as the next person. I think this is one major limitation of giving technology talks in general. When you give a one hour wiki talk, that’s just about enough time to describe the features of wikis, give some examples of how they can be used in libraries, and discuss how to choose the right wiki software for your needs and get started with it. When you’re giving a 2 or 3 (or probably more)-hour talk on a topic, it gives you the opportunity to talk more about the strategies for making your tech initiatives successful. I’ve often thought about how I can talk more about building participation with wikis in an hour-long talk, but, unless you know the group is starting from a place where they know what a wiki is, you can’t really skip the basic stuff. It would be fun to do a “so you have a wiki, now what?” 🙂 sort of talk where you could really go into the management, marketing and community-building stuff. People are always starting from different places, though. At a conference I spoke at a few months ago (where I only had 30 minutes to talk wikis), the satisfaction surveys contained comments that said both (I’m paraphrasing) “this was too basic” and “this went over my head.”

In my experience, it can be extremely difficult to get a large number of people to contribute to a wiki; whether library patrons, library staff or the profession at large. The first wiki I ever created (the ALA Chicago 2005 Wiki) gave me a very slanted view on wiki participation. With that wiki, all I had to do was create it, seed it with content and manage it. It was really an “if you build it, they will come” scenario. But there were two things that distinguished that wiki experience: 1) the population of people who attend ALA is huge and 2) with a conference wiki, there is a very real deadline for adding content (when the conference starts). With a huge population and the immediacy issue, the wiki was getting over a hundred edits per day in some cases. While I was dealing with a lot of spam problems on the management side, I didn’t have to do a lick of marketing to get things going beyond posting to my own blog.

So when I created Library Success: A Best Practices Wiki, I thought “well, all I have to do is create this, seed it a bit with content, and people will add to it in droves. I was seriously naive! While people did add to it, it was in drips and drabs. Days would go by where no one would add to it. What I discovered is that is how most wikis work. You will get a few really loyal content contributors, you will get people who are occasionally very passionate about adding content on a certain topic and the majority of people will just add content once in a blue moon. I’ve been amazed by how much the wiki has grown over the past 18 months, though some topics are far better developed than others. I could definitely do a better job marketing the Library Success Wiki, but it really is an issue of time. And while I feel guilty about it, it has become a real success in spite of me.

People may appreciate the value of wikis, but most will demur when it actually comes to adding content. Several of my colleagues actually asked me to create a reference wiki where we could share information about reference resources and student assignments, but when it came to adding content, it just didn’t happen. People in the workplace may agree that it would be useful to share information better, but they often have to feel that there is no option but collaboration and be really committed to adding content for a workplace wiki to be successful. And it’s even more difficult to get patrons to add to a wiki. The only wiki I can think of that successfully got patrons to contribute to it was the Princeton Public Library’s Book Lover’s Wiki, and maybe a big part of that was because it was a time-limited project (it’s also a uniquely civic-minded community). That doesn’t mean that it can’t happen for other libraries and other wikis developed for the public. Look at the Davis Wiki, RocWiki and ArborWiki. If the local libraries had created those city guide wikis, and didn’t create barriers to participation, I think people would have added to them. We just haven’t seen too many tests yet of libraries creating wikis for the public to add to and edit. Right now, most library wikis are either internal or are used as a way to share information with patrons.

There was an interesting article not so long ago about wiki facilitation (on a wiki, wouldn’t you know!). While I didn’t agree with all of their advice, I did agree with most of it. Here’s their list with my commentary:

1. Don’t create empty pages – my big pet peeve. I don’t think that you should create pages that have no content. It makes it seem like you are instructing people on what to add and it makes it look like no one has cared enough to add content. When I created the ALA Chicago Wiki, I went through and added content to every page, even if it meant having to do a whole bunch of research. If you don’t want to do that, don’t create the page in the first place.
2. Don’t over organise – I agree that we shouldn’t make things so structured the people don’t feel comfortable adding new categories, but I also think that having a structure makes people feel more comfortable posting and gives them an idea of where they “should” put things even if there is no should. There are good arguments for either view.
3. Don’t do it all yourself – when I see a wiki where virtually all of the edits were done by the creator of the wiki, I don’t feel like I want to post. It seems more like one person’s project than a community project. In the beginning, most edits will be made by the creator, but that should not be the case six months or one year in. You have to resist the temptation to add too much.
4. Projects – I haven’t done much with this, but I think it’s a great idea. The author writes “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.” I don’t know if this will work in every community, but I would definitely like to try it. It’s kind of like a barn-raising!

Something I have found really useful in getting people to post content to Library Success is to encourage people’s passions. There are a lot of people in the field with very specific interests like book reviews, teen services and collections, gaming, RSS, podcasting, or browser extensions. I have found that most contributions have come from people who have been encouraged or felt encouraged to add information about what they’re passionate about. We all have a lot of useful information in our heads that we could be sharing with others, but we usually need a reason to make the effort. Most people who are passionate about something usually don’t need a reason to share with others, because they love that topic. It’s how I feel about wikis. I could talk about this stuff until the cows come home. If you can find and encourage people who are passionate about certain relevant/complementary topics to add to the wiki, you’ll be in very good shape.

Another thing they didn’t mention on that site was ownership. I know the term “radical trust” has been thrown around a lot, but it really can’t be stressed enough. I just conducted an e-mail interview with a teen librarian who has been very successful in doing podcasting with teens. She attributed the success to the fact that she gives teens ownership over the product. She doesn’t try to impose her creative vision on the podcast. That really is the key to attracting and sustaining participation with most social software tools. We may think we know better. We may want to delete something or move it, but in some cases, we may want to step back and leave it to the community. People have to feel like they “own” the wiki. They need to feel like it belongs to them. I get worried when people call Library Success “Meredith’s wiki” because it isn’t mine. It belongs to the profession. And while I may not think that certain things fit into the Library Success wiki that someone has put in there, I will never delete it unless it is truly offensive or opinion masquerading as fact.

I actually had a situation like that a few months ago. Someone had vandalized the Radical Reference page, and while I wanted to delete it, I just didn’t want it to look like I, personally, was wielding power over the wiki. Instead, I kind of cordoned the comment off and wrote next to it “this is the opinion of one individual and may not reflect those of others”. In hindsight, maybe I should have just deleted it, but I am very concerned about the wiki having an open feel. Fortunately, someone else deleted it as you can see in the discussion on that article.

On the other hand, it is important to have guidelines that protect every member of the wiki community and give wiki managers a clear mandate on how to deal with issues that may come up. The Wikipedia has policies and guidelines that are designed to produce civility, consensus and quality articles. They also have etiquette guidelines. All of these guidelines are rather general and therefore do not seem to be targeted towards any specific group. I think problems happen when you create policies to prevent specific groups you anticipate being a problem from editing, because it’s often obvious that it’s what you’re trying to do. Much better to think about the behavior you want to promote than the behavior you want to prevent, and then base your guidelines on that. When guidelines feel preachy or restrictive or target a specific group, they can really discourage people from adding any content at all.

Having guidelines paradoxically protects the wiki from control from above. Sometimes people will start a wiki and get a bit of vandalism or spam on it and then decide to totally restrict access to the wiki. This is a huge overreaction and will only lead to you losing your audience. When a wiki that was once totally open now requires you to apply to get an account to edit it, I feel like that’s one too many barriers for the users. Better to come up with guidelines in advance so it is quite easy to make decisions about what to do with “inappropriate” content.

Another way to deal with content you don’t like is to have wiki editors in the community rather than one or a few people in your organization doing all the editing. If you have people outside of the organization policing the wiki and enforcing the policies you created, it won’t look like your organization is trying to silence people when content is deleted. Of course, the problem is that you need to actually find people who are willing to do this, which can be difficult. I know with the ALA New Orleans Wiki, I was doing all of the editing single-handedly and I didn’t feel very comfortable deleting content that was inappropriate (not spam or vandalism) because it was just me. However, there were lots of people involved in the ALA Chicago 2005 Wiki and it truly was community managed for a while. I think that’s the ideal, but it’s very hard to engage people in the community to take on the responsibility. It’s hard enough to get people to add content, much less help manage things!

I’d love to hear other wiki manager or wiki users’ thoughts on how to get people to add to wikis in different settings. I’m only speaking from my own experiences and I’d love to hear those of others!