Questions & Answers
Wikipatterns – Table of Contents
When people are thinking about how they might use a wiki, they’ll have a lot of questions about basic editing issues, privacy of information, how the wiki works in relation to email and other tools, and how to get started. Answering these questions is key to getting to that all important first edit – the moment when they actually start using the wiki. Here are some questions I’ve been asked at various workshops, conferences, and by people whose wiki adoption I’ve advised.
Someone else can change what I wrote?
Yes. The basic function of a wiki is to enable people to collaboratively create and edit content using a web site that can be easily edited using just a web browser. Within an organization’s wiki, who can see and change what you’ve written is determined by who has access to the same wiki space as you, which is often just the people working on the same team or project as you.
Although it can seem disconcerting at first, this is what makes wiki collaboration so powerful. The technical ability to easily make changes to what someone else has written raises the personal and social responsibility to make those changes in a way that respects what others have done. Therefore, when someone makes a change to something you’ve written, it’s incumbent upon them to do things like leaving a comment about the changes they’ve made (this is good practice especially with regard to significant changes), and making their changes in a way that builds on the best of what others have contributed.
When someone else edits a page, how do I see what changes they made?
Whenever changes are made to a wiki page, the wiki stores a record of those changes in its revision history, so you can see exactly what was added, changed, or deleted each time a page is edited. The revision history is an important window into the content that you see on the “surface” of a wiki page, because it shows how that page arrived at the current version you see today.
For example, let’s take two people collaborating by emailing a Word document back and forth and making changes. Each time one person makes changes, whatever they delete or edit in the document is lost as soon as they save their changes, and the only way to look at earlier versions is to search through the chain of email for an older version of the document. Even then, you’d have to manually compare the two documents to see changes.
The wiki simplifies this significantly by keeping the document and its revision history together in one place. When you compare revisions it highlights the changes, typically marking additions in green and deletions in red. The revision history also allows changes to be easily reverted if necessary. For example, if content was mistakenly deleted from the page, an earlier version of the page could be restored from the revision history in a matter of seconds.
Can the wiki notify me when a page is changed?
You can monitor changes to a page by email or RSS feed. Once you’ve elected to “watch” a page, you’ll receive an email or new item in your RSS feed when the page has been changed. This is especially useful if you want to keep up with a number of wiki pages and don’t have time to manually check each one. Notification also helps maintain a healthy level of activity on wiki pages because the notification helps people stay aware of what’s happening on the wiki, and they’re more likely to actively contribute when they’re engaged with what’s happening on an ongoing basis.
What if I don’t like what someone else wrote? Can I just delete it?
It’s better to change than just delete. If you’re going to make major changes, you might ask your team or community for consensus first. In addition to directly editing the content of a page, wikis provide space to comment, and this is the ideal place to discuss potential changes or deletions to a page’s content.
Discussing changes, especially if they’re likely to have a significant impact on the content of a page, is a good way to avoid becoming known as a [Do-it-all|http://www.wikipatterns.com/display/wikipatterns/Do+it+all] – someone who overpowers the collaborative nature of the wiki by taking it upon themselves to make unilateral changes.
Isn’t it necessary to have a moderator who can prevent people from deleting each others’ work?
This is very unlikely to happen. Good practice on a wiki discourages simply deleting someone else’s work, and in practice people are much more likely to do just the opposite – they’ll add their own contribution and won’t even touch what someone else has written. This most often happens with new users who are afraid to change what someone else has written. The best thing one person can do is make contributions that build on the existing content.
Let’s say you add a new wiki page and post a draft news release. I edit it to add a new sentence at the end of the fourth paragraph. When I click “Save”, the current version of the page is going to have my new sentence added to that paragraph. When you visit the page, you might check the revision history to get a quick overview of my changes to the page, and see the new sentence. You might decide that my new sentence belongs in the middle of the paragraph and should be combined with another, so you move it and edit those two together. Once you click “Save”, your revisions then become the new current version of the page. After you save the page, you might leave a comment explaining the rationale for your changes, and the next time I look at the page, I can see both your changes and your reasoning for making them. This way, we can work at times that are most convenient, and not have to be on the phone discussing changes.
So what you have with a Wiki is not one person who is entirely charged with dealing with all of that change, but shared responsibility among all collaborators to make their changes integrate with what others have contributed, use the best of other contributions, and take an approach that emphasizes refining content.
If the debate on a wiki page does get “hot”, can you somehow shut off editing?
Enterprise wiki software lets you set permissions for reading and editing pages, so you can turn privileges on and off as needed. It’s important to note that the instances you’ve probably heard about regarding situations on Wikipedia where editing has been shut off for a period of time – a cooling-off period if the debate gets to be really hot – are specific to the type of community on Wikipedia. That scenario doesn’t happen in organizations because when people are working toward a shared goal, they don’t get into the type of heated exchanges that happen in open, anonymous, all-virtual communities.
In organizations, editing and discussion on pages will ebb and flow naturally at certain points. For instance, if people are working on a document, report, or project and there’s a deadline, they’ll finalize their editing as they reach the deadline. After that deadline, the pace of editing may pick up again when changes need to be made.
Can everyone see what I put on the wiki? What if some material is sensitive or confidential?
Enterprise wikis allow you to easily create multiple wiki spaces for different groups, teams, and projects, and give people appropriate access to read and edit pages. Using these permissions, groups can collaborate privately when necessary, and work across boundaries when necessary.
For example, your team can have a wiki space where the ability to view and edit pages is restricted to just members of your team, but if you’re working with someone in another team, you can give them access to view or edit certain pages in your wiki.
How do I give people access to it/restrict access?
Wiki a wiki, you don’t have to ask the system administrator or IT staff to do this – you can do it yourself. For example, in Confluence you can set the permissions for any page directly from the page itself. When you’re in edit mode, the option to give indiviudal users or groups of people read or edit access is just below the content editing area.
How can I control the wiki and approve edits?
There’s a fine line between using permissions to manage access to wiki spaces, and controlling the wiki itself. Wiki is successful where knowledge management and content management tools have failed because it allows you to strike a balance between control and creative, organic growth. If there’s no restriction at all, the tool won’t be successful because people need some guidance on how to use it, and knowledge that it’s secure before trusting it with sensitive information. On the flip side, too much control restricts people from fully participating because if it’s presented with narrow restrictions on its use they will be less likely to experiment with different ways of using it.
How do I know the content on the wiki is correct?
This question is an extension of the oft-asked, “How do I know the content on Wikipedia is correct?” and it subtly assumes that the information is probably not correct. If you use a wiki in your organization, and it mimics the existing social and organizational structure by being used within existing teams and projects, the information it contains will be as correct as any other information source, such as email, PDF or Word documents, or paper documents.
Furthermore, if you find something in the wiki to be incorrect, you can fix it immediately, and it will be fixed for everyone who uses that information. In a comparative sense, that makes the wiki capable of being more correct than other sources of information.
Is there a grammarian or controller?
A wiki isn’t just controlled by one person; the community collectively maintains the quality and growth of content. There are some common roles self-identified by various members of a wiki community. For example, a WikiGnome, also known as a WikiGardener, is someone who devotes time to maintaining the site, organizing pages, ensuring links work, and improving the flow and clarity of content. A WikiGardener sets an excellent example for productive behaviors and contribution to the wiki’s value.
A passionate, enthusiastic WikiChampion is essential to the success of wiki because s/he will be able to generate interest, give the appropriate amount of training for each person at the right time, monitor growth of the tool and fix problems that could derail adoption. In some instances, a team might make use of the PageMaintainer role to coordinate activity. Although this role might sound closest to some sort of controller, the PageMaintainer’s job primarily has to do with the activity surrounding content, not the content itself. For example, the PageMaintainer might be responsible to encourage input, make sure others have added their contributions to a meeting agenda, minutes, or action item checklist, and maintain the organization of pages for tracking team meetings.
So what should I do first?
A good strategy for a person’s first contact with a wiki is an Invitation to create a profile, like MySpace. For one thing, it’s useful to have standard information about people, like phone numbers, email addresses, IM screen names, and web site URLs in an easy to access – and easy-to-update – place.
It’s the difficulty of updating that hinders most other types of content management and web site creation tools, but this isn’t the case with wiki so it’s a much more attractive option. Personal pages also give people a place to write about themselves and the ease of doing this can make the first experience using a wiki enjoyable.
Building pages is also good for building community since people can help each other with questions or problems. Even just informally discussing things like what to include on the pages gets people talking about a common thread, and it doesn’t have the same formality as working on a project.
What would I put on the wiki?
This depends on your purpose for using the wiki. The best uses of the wiki are those that are highly focused on solving a particular problem – updating documentation, simplifying project management, keeping track of constantly changing information that needs to be updated by a team, etc. Therefore, the best way to decide what to put on the wiki is to look at your day to day work processes and see what can benefit from being put on the wiki.
Once example I regularly give to groups and teams looking for where to start is to put meeting agendas on the wiki, then have team members record minutes during and after meetings, and use the wiki to track action items and projects. This way it’s easy to know exactly where everything stands at any given time, and by starting your wiki use at the core of the team’s interaction, it will become indispensable for obvious things like collaboration and project management, and new uses will spring up as people interact with it.
Can it handle images and other file types?
Yes. Images can be inserted inline with the text on a wiki page, so they appear in appropriate places throughout the content. Although text is the core of a wiki, visual elements like images, diagrams, and video can be essential parts of the content, and can be included on wiki pages. In fact, video sites like YouTube, Brightcove, and Google Video have made it very easy to embed video on pages because they host the content and you just place a small snippet of code where you want the video to appear on the wiki page.
Can I get content out of the wiki, say, when I’m done drafting a document?
Because the content you are putting in a Wiki is simply text, getting it out can be as simple as copying and pasting. Although in most cases you probably wouldn’t do this, it’s nice to know that you’re not dealing with proprietary file formats when you use a wiki.
When you need the contents of a wiki page in a more traditional format, it’s possible to export a wiki page into a Word document or PDF file.
How do I get people to switch from email to use the wiki?
You don’t have to completely drop email; it’s better to use wiki for content, then send email linking to wiki page at first. This directs people to the wiki, makes it less of a dramatic transition, and over time people will get used to going directly to the wiki. Also, the wiki can email you when pages are changed, so email is still useful in the wiki world – now it’s just put to better use because it does what it does best – communicates what’s happening in the wiki, which helps encourage collaboration on the wiki.
Is it ok to work locally, (i.e. offline on my own computer) on content that will go in the wiki?
Sure. Some people will start writing some content locally on their own computer, and then add it to the wiki page when they’re ready. Typically when people are making a quick change or a quick addition to a page, they’ll just do that right on the wiki, but if you’re travelling or in some situation where you don’t have Internet access, it’s fine to work on some content locally and then transfer it to the wiki. I do this especially when I’m flying – I’ll write draft blog posts while I’m in the air, then add them to a wiki page which is my staging area for posts to be published.
What if you read what someone wrote on a wiki page and find a grammatical error or can’t tell what the person wants to say?
If it’s a minor grammatical error, I’d just edit the page and fix it. If there’s something you really don’t understand, you can comment on the page to point out the ambiguity and ask for clarification. Even in this case, I’d try to edit the page and refine what the other person wrote. That way, next time they look at the wiki they’ll see that I’ve made changes and can look at how I’ve revised the original wording. Whether it’s now really far off from what they originally meant, or closer to their intended message, they can revise it further if necessary.
What this example illustrates is the change in thinking between the way we’ve done it before and the way we do it with a Wiki, because in the way we’ve done it before you don’t make immediate changes to things. You often find a change and you tell somebody else, “Here’s a change that you might want to make.” On a Wiki, you just make the change right there. To a certain extent you’re making a change for that person, but in a community where people are actively working on this, people begin to learn from each other’s work.
So if you go in and you write something, and I go in and refine it, and you like what I have written better than the original, you might then adjust your writing style a little bit. These things happen gradually over time. And because of the ability to work so directly with something, those changes happen in a much more fluid way.