Chapter 2. Your Wiki Isn’t (Necessarily) Wikipedia

Wikipatterns – Table of Contents

Wikipedia has democratized participation and changed the way people think about building and accessing knowledge like nothing before it, save for the printing press. For me, it helps establish a frame of reference to explain what a wiki is and how it can be used in organizations.

Wikipedia is one example of how wiki collaboration can be used: to build an encyclopedia. In my experience, it’s one of the lesser used applications in organizations. Whereas an encyclopedia makes sense for a large social community, other uses make more sense inside organizations where needs and priorities are different.

But because it is the most well known example of a wiki, people new to the idea of using a wiki in an organization or enterprise can be highly influenced by Wikipedia’s pattern of use, and think that wiki use in their organization will be fraught with all the pitfalls of Wikipedia they’ve heard about in the news. The reality is, Wikipedia is quite different from organizational wiki sites both because of its primary use – encyclopedia – and the way its community is structured. I often say it’s the most extreme instance of wiki in existence because everyone can see its entire contents, anyone can contribute, and people can do so anonymously.

These characteristics have made Wikipedia successful, but they aren’t necessarily the conditions for success for every wiki. Most organizations can’t have content publicly viewable, nor can they even have it viewable by everyone within the organization. Editing often needs to be restricted to specific people or teams, and anonymity isn’t necessary since people on a team already know each other, so knowing who’s editing a document enables discussion among the people collaborating on the document, and allows people to be given credit for the changes they’ve made.

Brief History of Wikipedia

Wikipedia was initially set up as a feeder project for Nupedia, an online encyclopedia founded by Jimmy Wales in early 2000. Wales wanted articles in Nupedia to be of similar quality to other professionally edited encyclopedias, so the site tried to get experts to write articles and use a peer review process to vet them for accuracy. Along the way, Wikipedia was set up as a place to start and collaboratively develop articles destined for the peer review process. Because of the lower barrier to entry on Wikipedia, it quickly outpaced Nupedia in number of articles and contributors, and has grown rapidly into the tour de force it is today.

Wikipedia took off because it enabled communities to organically spring up around common interests, and collaboratively author the corresponding articles about them. Nupedia focused first on the information, and as a result it limited itself by only wanting experts to write articles. That reduced the pool of potential contributors on any topic, and complicated the authoring process with questions of how to verify the expertise of contributors. Wikipedia inherently focused on people from the start, by using the wiki to make article creation easier, and that’s why it has taken off so quickly.

This raises the question of accuracy. Nupedia tried to ensure accuracy up front by looking for experts to write articles. Wikipedia has achieved accuracy because the process is a self-checking one. The low barrier to entry of the wiki means that not only can articles be created quickly, but the presence of an interested community results in accurate information and rapid error correction.

Jon Udell’s “Heavy metal umlaut: the movie” illustrates this very well; in it, he shows the history of content growth on the Wikipedia entry on the use of the umlaut in heavy metal band names (Udell, 2005). In one example, he shows how the community editing the page experimented with various ways to represent names that use the umlaut, from code tricks to the use of LaTeX document markup, to the eventual use of an image of the SpinalTap logo. The initial methods didn’t work well, and the community editing the page reacted quickly to try new ideas.

At another point in the video, he shows how a vandal defaced the page, and within less than a minute another editor restored the page to its previous state. This continued on for several minutes, with the vandal defacing the page, and an editor immediately restoring the page, until the vandal gave up and stopped altering the page. This illustrates the commitment interested communities have to the pages they edit, and the resulting high level of accuracy and integrity they can maintain on a publicly editable page.

Nature Compares Accuracy of Wikipedia and Britannica

A 2005 study by the journal _Nature_ has provided some support of this, by concluding that for science topics Wikipedia is about as accurate as Britannica (Giles, 2005). To conduct the study, _Nature_ asked its journalists to choose articles from Wikipedia and Encyclopaedia Britannica on the topics they regularly cover. They stripped out any identifying information about which encyclopedia the articles had come from, then sent them to experts in each topic for blind comparison.

For the 42 topics compared, Wikipedia was found to have an average of four errors or inaccuracies per article, while Britannica was found to have an average of three. The journal’s conclusion was that the quality of the information in the two, at least for science topics, was about equal. Even though Wikipedia articles had, on average, one more error than Britannica articles, people editing those articles could fix the errors immediately, thanks to the wiki. The people publishing Britannica, however, would have to wait until the next edition of their encyclopedia was revised and published to fix their errors.

Ironically it took Britannica three months to reply, and in the reply they accused _Nature_ of conducting faulty research. _Nature_ issued a detailed rebuttal to Britannica, with point by point responses to Britannica’s complaints, but Britannica has already illustrated a bigger point. In its initial report, _Nature_ said, “It is going to take Britannica longer than Wikipedia to deal with this issue, and by taking three months to even reply and make a statement about it, Britannica confirmed this.

The study also addressed high-profile media coverage of some incidents where Wikipedia pages were edited with false or misleading information. “One article was revealed as falsely suggesting that a former assistant to US Senator Robert Kennedy may have been involved in his assassination. And podcasting pioneer Adam Curry has been accused of editing the entry on podcasting to remove references to competitors’ work. Curry says he merely thought he was making the entry more accurate. However, an expert-led investigation carried out by Nature — the first to use peer review to compare Wikipedia and Britannica’s coverage of science — suggests that such high-profile examples are the exception rather than the rule (Giles, 2005).”

In an editorial published in the same issue of _Nature_ as the study, the editors reflected on the growing importance of Wikipedia and the potential result if it further closed the gap with highly respected rival reference works: “a comprehensive, accurate and up-to-date reference work that can be accessed free from Manhattan to rural Mongolia (Nature, 2005).” Whether or not this can happen, they argued, hinges on finding contributors who can further refine the quality of entries, and they called on their own readership to help, arguing that “…scientists can bring a critical eye to entries on subjects they study, often highlighting errors and misunderstandings that others have unintentionally introduced (Nature, 2005).”

By conducting this study, _Nature_ shed light on an issue that was, until that point, receiving inaccurate coverage because of a general lack of understanding of Wikipedia, and the propensity of the media to highlight a newsworthy story even if it’s the exception and not the norm. The ensuing debate was equally eye-opening because there are plenty of people who think that the Wiki is a passing fad, or don’t know what to think of it, or think that maybe there were flaws in _Nature_’s work. And there may have been; but the impact of it on the people’s thinking is what is really important, and no matter what people think of it, it has made a big impact. There has been a lot of talk about the idea since that study, and there is now more and more research emerging on the idea of looking at what happens in the revision history of a Wiki page, versus material that is published in more static book form.

When you pick up an article in Britannica and read the content, you get what’s there at face value but you don’t know what went into developing that article. There’s no easy way for you to know the backgrounds, influences, and biases of the authors. Now think about reading that article on Wikipedia. you’d have not only the article itself, but the revision history which reveals the social forces behind the construction of that article. You can see, for instance, where authors may have disagreed about the content, when people have contributed new content, and who those people might be. Although you can edit anonymously, some people want their names attached to their work. The bottom line is, with a wiki you see not only the end product of the information, but you get to see the construction of that knowledge, and that’s incredibly valuable in measuring the quality of that information.

It’s that ability to easily edit, refine, and even repair information that’s at the heart of not just Wikipedia, but the wiki concept. But it’s important to understand the significant differences between how the wiki is used as the foundation for Wikipedia, and how it’s used in organizations.

The All-Virtual Wiki Community vs. Wiki that Mirrors Physical Community

When comparing organizations’ wikis and Wikipedia, I often say there are two types of wiki communities – the all-virtual vs. the wiki that mirrors a physical community. Wikipedia exemplifies the all-virtual community, where contributors belong to the community only through their participation on the site. This can lead to some of the perceived problems with Wikipedia, like vandalism of entries on popular or hotly contested issues, posting rude or hostile comments to other users (flaming), or people and organizations editing entries to serve their interests. For example, Microsoft got into hot water with the blogosphere earlier this year because it allegedly offered to pay a blogger to edit Wikipedia entries on the XML protocol that it perceived to have an anti-Microsoft sentiment (Jeliffe, 2007).

The wiki in your organization is the second kind because people are part of the community for more reasons than just the wiki. They either work or volunteer for the organization, they regularly work with a known group of people and they are often working toward a common goal. They may be in close proximity (even the same office) with at least some of the people they work with, but may be at great distances or even have never met others they work with, but the effects of this are quite different than in an all-virtual group, and the wiki will be used in ways that support the overarching goals of the organization.

Why Mischief Doesn’t Happen in an Organization’s Wiki

Upon first hearing about the wiki as a workplace tool, some people think that it will be as open and anonymous as Wikipedia or worse yet, an uncontrolled mess with no productive use and lots of inappropriate behavior. For people used to communication that seems more controlled, like conversations, meetings, and email, this can be very disconcerting.

The reality is, this just doesn’t happen. Let’s look at some reasons why:

Open versus Secure

Wikipedia is a very open, public site and even allows anonymous editing because that’s what works best for its community. For most people, Wikipedia is the first experience they have with editing a live web page, so having the fewest possible barriers to entry is critical. Giving people the ability to edit something immediately, and even anonymously, is what gets them to fix an error, or add a new piece of information to an article.

The anonymity does increase the potential for people to vandalize the site or use it as a soapbox for their views on a topic, but those negative effects have to be taken in context. When the news media makes a big story out of a “Wikipedia Scandal” like the incident where someone edited the comedian Sinbad’s entry to say he had a heart attack, the reality is that’s just one edit and there were thousands, maybe millions, of edits that same day that were perfectly legitimate and added new or more accurate information to the wiki. The media often “forgets” to mention this, because putting it in context detracts from the supposed newsworthiness of the story.

In the wiki of a private organization, this kind of vandalism or erroneous editing is extremely unlikely to happen because the wiki is being used within an already established social and organizational structure. The fact is people just don’t abuse tools that are important to their professional work.

It’s important to strike a balance between openness and security. Keeping the wiki open to a point where people can collaborate across teams might be a little less secure than restricting each team to its own space, but it’s likely to help people realize the interplay between the work of different teams and work even more closely. This can make your organization dramatically more efficient. At the same time, users need to know that thy can use permissions to control access at several levels, depending on their requirements.

Quality, Accuracy, and Moderators

Since the accuracy of Wikipedia is questioned regularly in the media, many new users reflect that when they question the accuracy of the new wiki you’re evangelizing in your organization. It might be useful to point out the _Nature_ study and its conclusion that Wikipedia is quite accurate. But it’s important to address Wikipedia and then put it aside to focus on your wiki.

New users need to understand that the wiki is merely a tool, as is their email, their word processor, or anything they use to do their work. The wiki is no more or less accurate than these other tools. It is simply a new mechanism. The social nature of the wiki actually offers the opportunity to have higher accuracy.

When an organization wants to verify accuracy of information on a wiki page, the page might include a [ContentAlert|]. This is a standard message posted at the top of the page indicating that the page needs to have information added, sources cited, or a section checked for accuracy.

How Will Your Wiki Be Used?

The wiki can be applied to a wide variety of specific uses which are fundamentally different from an encyclopedia. New users benefit from seeing a variety of applications – sales processes, technical documentation, work group collaboration, event planning, etc. – so that they can visualize how they might use the wiki. One of the first steps is to show new users these possibilities.

Build a Peer-Directory

Keeping an up to date employee directory is a constant challenge for many organizations. When people join, leave, change roles, or move to a new office information needs to be updated accordingly. In reality, this doesn’t always happen in a timely manner, so the organization directory gets out of date, and you only find out when you try to call someone and find out they haven’t worked for your company in a year!

Creating a wiki-based peer directory can be an ideal solution because it distributes the responsibility to update personal information to the people themselves. It also gives people a reason to come to the wiki in the first place – to put their information in the directory – and then they stay to collaborate. Building a Facebook-style page can be a great first experience editing the wiki, because it helps people tackle the paradigm shift of an editable web site in stages. Unlike a meeting agenda or project document, someone else isn’t likely to edit your personal information so this gives people a chance to get used to the process of wiki editing. Later on, when they start collaborating with others, they’re likely to be more comfortable with making changes and seeing changes made to their work if they’re already proficient, confident editors themselves.

Agendas > Meetings > Projects

If you email a meeting agenda to a group of people, and then find that something needs to be changed, you have to make changes and send another email. Likewise, if someone else needs to change the agenda, they’ll have to either email you to ask that the change be made, or do it themselves and resend the agenda to the group. In either case, there’s a possibility that with so many versions of the agenda circulating each person will come to the meeting with a different agenda!

Instead of emailing the agenda, put it on a wiki page and email people a link to that page. If changes need to be made, anyone can do so and everyone will have immediate access to the same, up-to-date version. Then, record minutes on the wiki so all information pertaining to the meeting is in one place. The further advantage here is that the responsibility to take minutes doesn’t have to rest with just one person. No matter how carefully one person listen and takes notes, it’s really difficult for one person to accurately capture everything that happens during the course of a meeting. One person may pick up on a certain detail that another person misses, so using the wiki can give everyone a place to contribute, resulting in a more comprehensive account of the meeting.

Keeping meeting agendas and minutes on the wiki can be the perfect foundation for project and task management. As various topics and items from a meeting are discussed and need further action, new wiki pages can spawn from the agenda or minutes and be used to manage them.

Manage Projects

Give each project a page in your wiki, and keep all relevant materials there. One way this may happen is as a result of the project being discussed and approved in a meeting, so project pages may organically grow out of meeting minutes. This is a great example of how the wiki can flexibly adapt to how your organization works.

It’s a huge time saver to have everything in one place and easily updated, and it ensures that everyone associated with the project has consistent information. Furthermore, if the project management pages have grown out of meeting agendas & minutes, reporting on project progress becomes part of a cycle that’s fully captured on the wiki. This allows greater flexibility with the information, since it can be referenced in other areas of the wiki, like an annual report or strategic plan, or other projects.

Product Development

A wiki is ideal for managing your organization’s products from development to production, marketing, and support. The product designers and engineers might start by collaborating on the design, features, and technical specifications for the product. The manufacturer could then be invited to the wiki to be involved in the discussions on issues like materials, and production processes. When changes are made by the designers and engineers, the wiki allows the manufacturer to know immediately and change manufacturing processes accordingly.

You can also invite other groups like marketing and support to the wiki to collaborate on developing marketing materials and offer input based on experience with customers. Marketing staff can also use product information from the wiki to develop the marketing campaign, product materials, and website content. Support people can offer input on the product based on common issues they’ve seen with earlier or similar products, and by being involved on the wiki, they’ll have a more thorough knowledge of the product as they support customers.

Knowledge Base or Support Site

A knowledge base is another ideal use for a wiki, and if you’ve built product documentation on a wiki already, a knowledge base can be the logical next step. Keep common FAQs and support questions on the wiki so they can easily be updated with new information. People inside your organization can update it with new information like questions, issues, solutions, and how-to guides.

A wiki knowledge base can be especially useful for support staff so they can update it as soon as they find a new answer to a question, or add new issues in need of answers. Because the wiki tends to “pull” information from the edges of a group into a central place that everyone sees, it helps reveal information that people might not realize others have or are looking for. In the case of a support group, it helps bring to light the issues that need answers so someone who knows an answer can easily contribute it. With a constantly growing wiki knowledge base, support staff will be able to answer questions a lot faster because it cuts down on the unnecessary repetition that happens when people are working in relative isolation and don’t have a mechanism to share what they know.

Some organizations open the wiki knowledge base to customers so they can directly update it. As the wiki becomes more comprehensive and people increasingly look there first for simple issues, support staff have more time to concentrate on new and more specific issues. Customers can also directly support each other through the information they post to the wiki, and if the knowledge base includes a peer directory, they can discuss issues directly and work together to solve them, then add new information to the knowledge base. Heck, this could even lead to those customers realizing they have complementary interests and collaborating on other projects!

Event Planning

Start off by planning the event agenda, logistics, and documents like the agenda, all on the wiki. You can even use the wiki to distribute the invitation – just put it together on a wiki page, then use email and your blog to announce the event and include a link to full details on the wiki. You can also gather RSVPs on the wiki – set up a page that people can edit to add their name to a list, or have them RSVP by leaving a comment on the invitation page.

If you have materials to distribute before or after the event, you can use the wiki for this too. Create a page on which to host all materials, or you can link them from items on the agenda. One advantage of doing this: presenters can attach copies of their presentation slides and handouts by themselves, without having to email them to you. That’s a great way to further cut down on unnecessary email, and you can still check the documents they add to the wiki and contact them if any changes are needed.

Intranet or Extranet

Use a wiki for your intranet or extranet. The problem with the traditional intranet is it doesn’t encourage people to contribute often. One person is usually responsible for updating it, and when lots of changes have to be funneled through that person, information on the intranet gets out of date quickly.

Imagine the scenario – you ask the intranet person to make changes to a page, but he or she already has a long list of changes to make so yours takes days or weeks to happen. When you haven’t seen the change, you probably email the person for an update, and if everyone else is doing that the person is even more distracted by answering those emails, so the change takes even longer. By the time the change is made, that information is already out of date and the cycle starts all over again. Or not. Eventually, you just stop asking for changes to the intranet because it’s just too difficult and not useful.

At Atlassian, the company which develops the Confluence wiki (and where I work as Wiki Evangelist), we use a wiki for the company extranet. Development teams, departments like marketing, sales, and customer advocates each have a wiki space. The ability for logged in users to view content in different spaces across the extranet isn’t restricted by default, but pages can be restricted as needed. Project documents, standard materials like company and product logos, meeting agendas and summaries, and draft content for the website and public blogs are all developed on the wiki. Some information is developed collaboratively, and some is developed individually, but because of the wiki it’s well organized and easy to find, which makes content easy to use as needed.


Some wiki tools have the ability to support blogging. At Atlassian, internal blogging is used to communicate about activities like product development, support issues, product releases, planning events such as user groups and conferences, and providing informal updates on miscellaneous issues like server updates. Since blogging takes place on the wiki, it adds further value to the wiki as a central information source, and is a better way to distribute information than further clogging people’s email inboxes, because people can identify the information most relevant to them. When they do so, they’re more likely to make a meaningful contribution than if they were just copied on lots of emails that some else may have thought they’d be interested in.

Using internal blogging for routine updates and information allows email to be used only for updates that truly affect everyone and need to be communicated in a blanket manner. By reducing the number of general emails, people will be more likely to pay attention to the few that really do affect them, and by putting more specific communication on the wiki, people can identify and keep up with what’s most relevant to them.

External Communication

A wiki can be used as a simple platform for internally editing content, then allowing an external audience to just read and comment on it, but not edit. For instance, you might use a wiki internally to collaboratively write news releases. You might start by asking for input from various internal groups working on a project for which public news is being released. Public relations and marketing staff would then draft a news release, ask appropriate parties to refine and vet the content, then finalize the release. If something changes, the release can be quickly updated as necessary.

Once the release is ready to be released to the public, the wiki can be used for this as well. Most enterprise wiki software has the ability to set permissions regarding who can read and edit content, so the finished news release could be put on a wiki page where permissions are set to allow anyone to read, but only those who are logged in are allowed to modify the document. Members of the public could also be allowed to add comments to the page, which would still preclude them from editing the actual content, but would allow a mechanism for feedback, comments, and questions relating to the news. Staff could answer questions by posting reply comments, and since they would be logged in, their names would appear with their comments, indicating that they are official replies.

Public Website

Another use for the wiki is as the platform for a public website. The fact that it can be easily edited just makes the job of keeping content up to date much easier. This is not likely to be the first wiki use you might think of, but some of the ideas I suggested earlier are essentially public website uses of the wiki, such as a public support site or knowledge base.

For example, [|] ( is an example of a wiki used as a public website. The first time you visit, it might not even be apparent that it’s a wiki, but when you want to contribute to a pattern page, build a personal profile, or add a new pattern, the edit button is right there.

Last year, along with eight collaborators, I wrote the wikibook [Using Wiki in Education|] ( entirely on a wiki and even released it to readers on the wiki as well. Most chapters are read-only, but one is editable by general readers, as are some pages on the site where readers can contribute links to other wiki-related content.

And many more!

These are just a few examples of how a wiki might be used in your organization, but the best part is, you’ll think of many more and when you do, you’ll be able to use the wiki! Also, although the wiki is an excellent collaboration tool, not all of the activities that take place on it must be collaborative – drafting blog posts for example – but the flexibility and lack of rigid structure means the wiki can be used for all these activities and the more you use it the more valuable it becomes to everyone in your organization. In the next chapter, we’ll talk about how to get your wiki use underway, and encourage people to make the all important first edit.


  1. Giles, Jim. “Internet encyclopedias go head-to-head”. _Nature_ 438, no.7070 (December 14, 2005), (accessed May 16, 2007).
  2. Jeliffe, Rick. “An interesting offer: get paid to contribute to Wikipedia”. _O’Reilly XML Blog_ (January 22, 2007), (accessed July 9, 2007).
  3. Nature. “Wiki’s wild world”. (Editorial) _News@Nature_ 438, 890 (15 Dec 2005), (accessed July 9, 2007).
  4. Udell, Jon. “Heavy metal umlaut: the movie”. _Jon’s Radio_ (January 21 2005), {accessed July 9, 2007).