Aired May 16, 2013

This webinar covers best practices for managing a wiki and discusses how to as a community and admin, create policies for your wiki.

Slides & Transcript

Policies Webinar 2013 Slide01

Welcome to the Wikia Webinar series. Today we will will be talking about Wiki Management and Policies for your wiki.

Policies Webinar 2013 Slide02

I’m Sarah Morales, a Director of Community Support at Wikia and today joining me is Brandon Rhea, Community Support Manager

Policies Webinar 2013 Slide03

Before we dig into how to manage a wiki, it’s important to remember what a wiki is. A wiki is a place to collaborate around content you love. On Wikia, collaboration includes creating content together but it also includes deciding how pages are formatted, what the wiki’s design is, what features are used and much, much more.

Wiki software is meant to allow anyone who wants to contribute to be able to. These contributions are tracked and transparent, so anyone can see who contributed what and where. The openness of a wiki is part of its power and beauty. It means contributions are attributed to those who create them. This helps in managing a community, since you can see who is making positive contributions and who may not be.

Policies Webinar 2013 Slide04

So today we are going to cover best practices for wiki management and how to create policies to help your community be successful. At the end we will go through a few examples, so please feel free to send in your own experiences, examples or questions at any time using the gotomeeting software.

Policies Webinar 2013 Slide05
User Rights

Let’s start by reviewing some of the commons rights found on a wiki. Once you create an account and log in, you can contribute to almost any page on Wikia. You have the ability to edit and format pages, add photos and videos, and use many features such as chat, achievements, forums and much more.

Policies Webinar 2013 Slide06
Admin Rights

Admins are users with advanced rights tasked with helping to keep a wiki running smoothly. To do this they can delete & protect pages, access special tools and pages as well as block problem users. Bureaucrat is the right to make other users admins, and when you found a wiki, you are automatically given both Admin & Bureaucrat rights. These rights are local only to your wiki.

Policies Webinar 2013 Slide07
Admin Role

With these extra rights, there’s often a question as to what the role of an admin should be and how that power should be used. Are admins meant to be the boss of a wiki, or are they meant to be something else?

First and foremost admins are meant to serve the community. Admins are often those who interact with the largest number of community members. This may be to give out warnings, provide corrections or in some cases to block users. Before an admin ever gets to that point, though, it’s a good idea to remain helpful and to try and guide users, even one on one, to an understanding of the community-decided rules. Admins don’t make the rules and don’t make unilateral decisions, but rather they use their tools to carry out the will of the community.

Policies Webinar 2013 Slide08
Assume Good Faith

This idea of all users being equal is a basic tenet of wikis. It is the idea that no matter who you are, no matter what rights you have, everyone is equal and has an equal stake in the wiki. Everyone can work to make it better, or everyone can be the cause of it to fail. Part of being successful on a wiki and as a community is that you assume good faith. This concept has been a part of wikis since they began over a decade ago. But what does this mean exactly? It means as wiki editors we assume that most people who contribute to a wiki are trying to help it, not hurt it. If this weren't true, a wiki project would be doomed from the beginning.

What constitutes Good Faith exactly though? It means you assume that a fellow editor is trying their best to do their best, both for themselves and for the community. It means that you assume an error wasn’t done in malice but rather was a well-intentioned error. Assuming good faith is about intentions not actions. Well-meaning people make mistakes, and you should correct them when they do. What you should not do is act like their mistake was deliberate. Correct, but don't scold. There will be people on the wiki you disagree with. Even if they're wrong, that doesn't mean they're trying to wreck your wiki. They may have a different opinion or style, and assuming good faith means you give them the benefit of doubt. This can help prevent problems from escalating, and means that editors have trust in each other and the community’s best interest at heart. It makes the community a friendlier place to be.

Policies Webinar 2013 Slide09
Don't Feed the Trolls

Assuming good faith is where you should start, but if a user proves himself to not have the community’s best intention at heart, another method must be taken. If someone proves to be a troll, an individual who posts inflammatory or disruptive remarks with the intention of provoking others into a heated response to disrupt the community, then you need to employ the practice of “Don’t feed the trolls”.

By this I mean, do not "feed" them with emotional responses, over-reactions or other heated replies. This is what they are looking for. These users know that they are breaking the rules, so all this does is acknowledge them and give them the attention they are looking for. Excited and dramatic reactions encourage them to continue or escalate their bad behavior, to see just how upset you will get.

So what should you do? Our advice is to stay calm, and limit your interaction. In practice, there are three simple things to do: revert, block, and ignore. Revert the bad edits they made to restore the page back to the way it was before they vandalized it, and block the problem user so they cannot continue their bad edits. Then ignore all future interactions. By ignoring them you are not giving the attention they are seeking, and they will eventually move on.

Policies Webinar 2013 Slide10

I am Brandon Rhea and I have been editing on Wikia since 2006. I started out on Star Wars Fanon wiki where I am still an active Bureaucrat. My love for Star Wars is what drew me to Wikia, but the community on Star Wars Fanon is what made me stay. As a Bureaucrat there I’ve helped our community create local policies and had the responsibility of working with new editors to help them understand and follow them. As a member of the Community Support team I’ve offered advice to wiki’s across wikia to help them create, update and enforce local policies. Today I am going to share with you best practices on policy creation and wiki management. Remember wikis are all run into different ways - so these are general recommendations that I have seen work well first hand. It does not mean this is the only way.

Policies Webinar 2013 Slide11
Why Policies?

Lets first just think about what is a policy and why they exist. A policy is a general guideline that helps set expectations for the community. Policies can apply to the type of content, how the content is displayed or how people interact with each other on the wiki. The goal for wiki policies should be to help guide how people create content together. So that the content - such as naming conventions, formatting of a page, and much more, are consistent across the wiki.

Policies Webinar 2013 Slide12

The first thing to remember about a policy, is that not everyone is a wiki expert. So how policies are written and where they exist on a wiki, should be easy to find and clear to understand. If you take anything away from this webinar, I hope its that policies should be clear and accessible, for advanced users to editing newbies. This will be what will make policies successful or not.

Policies Webinar 2013 Slide13

The first thing you want to ask yourself when you sit down to write a policy is this: does this policy have a point and will it accomplish anything? Policies guide the editing process and the interactions of the community, so they should always be practical solutions to actual problems. That’s something wikis sometimes make the mistake of forgetting. During its early years, Star Wars Fanon would often create policies for unimportant issues: you couldn’t have more than 20 userboxes on your user page, you couldn’t have more than one video on your user page, and you had to have a category on your article immediately or the entire article would be deleted.

Do those sound like real problems, and do their solutions seem necessary? Not really, no. They were all made based on the preferences of the admins, not the need to fix real problems. So when you start, you should ask yourself: Is this policy necessary? What is it’s goal? and What problem will it solve.

Policies Webinar 2013 Slide14

If you have answers to all of of these, then next thing you should consider is what will the policy state. Policies should follow the KISS method to success. KISS stands for Keep it Simple, Stupid, and it's a way of making sure that your rules are as simple and easy to understand as possible without losing their meaning or value. One of the things KISS helps you avoid is instruction creep, which is what happens when there are more and bigger sets of rules, to the point where they can't really be understood or effectively enforced anymore. This can hurt a wiki because users either can't understand that many policies, or they simply choose to ignore them when they see so many. Who wants to read 20 pages of policies anyway?

Let's paint a scenario that I've seen before. Say you have lots of policies. What happens? Often, people don't read them or are completely confused. That means they miss some of the most important ones, like how to organize and style content, which is often called the manuals of style. You then have a situation where people are creating lots of pages and edits that don't follow your guidelines. What tends to happen next? Most often the user gets warned, then banned, and the wiki may lose its next great contributor.

If you need to create policies, ask yourself whether those policies are necessary. Look at the part of wiki editing or community interaction that the policy aims to cover. Is that area a problem? If not, then don’t try to fix what isn’t broken. If it is a problem, is the policy you’re implementing a practical solution? If not, consider trimming it down. And worse comes to worse, share the policy with new members of your community, and if they get it, then you know that you’ve passed the Keep it simple test.

Policies Webinar 2013 Slide15

Policies Webinar 2013 Slide16
Content Policies

Content policies deal with what is and isn’t allowed on a wiki. One of the kinds of content is text, and this policy can say what kind of text is and isn’t allowed. This distinction can be as general as a canon wiki not allowing fan fiction, or more in-depth such as policies that handle mature themes. Another kind of content is files, such as images and videos. Some wikis have policies that deal with sourcing images that are used. Others allow videos, but perhaps only certain kinds, and some don’t allow videos at all. Policies can be setup to make all of that clear.

Policies Webinar 2013 Slide17

I mentioned that some policies deal with not allowing fan fiction on a canon wiki. Wookieepedia is an example of that. They have a policy that deals with making sure that any fan-related page on Wookieepedia is sufficiently notable to warrant being part of the canon wiki, whereas fan fiction and fanon should be added to a fanon wiki such as Star Wars Fanon.

Some canon wikis have adopted fanon into their wiki, though. The Avatar Wiki has an entire section of their wiki for fanon. Rather than having an entirely separate fanon wiki, this has allowed the two wikis to combine their efforts and work together on two different, but ultimately very similar goals.

I also talked about how wikis can have policies that deal with mature themes. Star Wars Fanon has a content policy that limits profanity, graphic violence, overly-sexual themes, racism, and more. This is done to make sure that the wiki is accessible to all Star Wars fans, rather than just ones who have a higher tolerance for more mature themes.

Policies Webinar 2013 Slide18
Style Policies

Style also deals with content, and style policies are important to make sure that pages on a wiki look the same and so all readers know what to expect when they read a page. Wikis often have a policy known as the Manual of Style which covers the style and format of a wiki's page to make sure that each page is consistent with all the others. Some of the areas that a manual of style can cover are page layout, naming conventions, category structure, spelling and grammar, and much more.

Policies Webinar 2013 Slide19

A great example of a content guide is on the Marvel Database. They have an entire layout guide that makes sure users know how to format pages when they’re writing on the wiki. Another, separate policy deals entirely with how to name a page.

Policies Webinar 2013 Slide20
Behavior Policies

Ultimately, content and style only matter because of who writes the pages: the community of users. A wiki can only be at its best when users are treating each other well and acting responsibly. That’s why wikis also need policies that deal with how people behave on a wiki. This kind of policy covers important points like assuming good faith, not getting into edit wars, not disrupting the wiki, and being civil to everyone even when you disagree. This policy lets people know what’s expected of them when they edit on a wiki and become part of the community. I generally like to think of this as one policy with multiple parts, like a Code of Conduct; keeping it as short and simple as possible goes a long way to making sure people read and understand it.

One of the other behavioral policies is one of the most necessary but also the one that’s the least enjoyable to have and create: the blocking policy. We all hope that no one ever has to be blocked, but we also know that it’s sometimes necessary. The blocking policy covers what people will be blocked for and how long they will be blocked. This acts as a roadmap for admins and makes sure that the community has approved how blocks are carried out, rather than having an admin arbitrarily decide on a block length for each specific issue.

Policies Webinar 2013 Slide21

A great example of this kind of policy is on the Adventure Time Wiki, where they have a Code of Conduct. This policy says that users can't make personal attacks, use excessive language, spam, troll, vandalism, and more. It also covers a Code of Conduct for chat and what users shouldn't do when chatting with the community, such as discussing controversial topics such as religion, politics, drugs, and violence.

Policies Webinar 2013 Slide22

Policies Webinar 2013 Slide23
Creating Policies

Creating policies is an act of decision making, and we strongly encourage you use a consensus decision making method as opposed to just a few admins making policies and enforcing them. Consensus on a wiki is a group decision making process that everyone can participate in, giving the entire community the chance to shape a policy.

Policies Webinar 2013 Slide24
How to use Consensus

In practice, consensus means that a wiki’s community works together to create their policies. This kind of decision-making generally takes one of two forms. One, there could be a discussion about what kinds of things users want to see in a policy. They can talk about what the best ideas are, what kinds of punishments there should be for not following the policy, and anything else that they think that policy might need to make it work. That makes the writing of the policy a collaborative effort. Ideally, that lets all opinions be heard and lets the best ones make the cut.

The second way of creating a policy is that a smaller group of people, or maybe just one person such as an admin, writes a policy and then puts it up for a community vote. That lets the community review the draft policy and vote on whether or not they support it. If a user has an objection, they can talk about it and the community can work through it. Perhaps the objection will be withdrawn, or maybe the policy draft will be amended.

Policies Webinar 2013 Slide25

There are a number of ways that wikis can go about discussing policies and voting on them. Polls, blogs, and forums are the typical methods that wikis use to do this. Polls make it easy for users to vote and gives you a clear look at how many people have voted and what they have voted for. I generally discourage the use of polls, though, because they’re fairly unreliable when it comes to official votes. Polls don’t tell you who voted for what, so you can never be sure if anyone is using sockpuppets and who is actually voting.

The two most reliable methods are blogs and forums. In both of those, users can see the main message, which might include a draft of the policy, and then comment on it. The commenting methods are different, but not too dissimilar. Many wikis end up using forums, as they’re generally the best setup for this kind of conversation.

Once you set up the forum or blog, you want to make sure it’s given a framework so it can be completed in a reasonable amount of time. You want to give everyone the chance to participate, but you also don’t want to spend months on the same topic. Too much groupthink can bog down a discussion and lead it around in circles, when really all that needs to happen is that a decision is made. Keeping a discussion moving generally falls on the admins. Admins aren’t making decisions about policies on their own, but that doesn’t mean they shouldn’t show leadership by guiding the process along whenever they can.

Policies Webinar 2013 Slide26

Remember, keep it simple. You don’t want to go crazy with rules, and you only want to have rules that are necessary. When you’re making them and talking about them, always remember to write in ways that people can understand. Shorthand terms, like nicknames for policies or other aspects of the wiki, may be understood by more experienced users, but a new user might be lost when they read about that. One example of a shorthand way of saying something would be MOS, which stands for Manual of Style. Just writing MOS might confuse those who don’t know what it stands for.

Policies Webinar 2013 Slide27

Part of keeping things simple is also making sure that policies are easy to find. The best way to organize policies is to have a dedicated category for them to live in, such as Category:Policy. That category can then be linked to in places that new users often see, such as the welcome message they receive when they first edit, as well as the wiki navigation menu. This makes sure that users are able to find the policies as easily as possible, and it helps cut down on the amount of policy problems that may arise later.

Policies Webinar 2013 Slide28
Moving Forward

Once you’ve set up your policies, remember something important: you’re not finished. This is both philosophical and literal. All websites, wikis or not, evolve over time, and their rules always change with them. There’s always trial and error. Be flexible and open to adjustment, especially if the topic of your wiki or the tools you use change. Reviews of policies, perhaps every 6 months or every year, are always a good idea. You want to make sure that all of your policies are relevant to the wiki you have right now, so you always have only the policies you need.

Policies Webinar 2013 Slide29

Policies Webinar 2013 Slide30
Enforcing Policies

While it’s important to stick to policies, it’s also important to remember that there are exceptions to every rule and a policy can’t cover every exception. If someone is violating your policies, though, you want to make sure that they’re helping them learn what they need to do in order to avoid making that mistake in the future. You should take a good amount of time to help, but there will come a point where you will want to move past the helping stage and become a bit more formal about how you’re dealing with the user. At that point, you move on to the warning stage.

When you warn a user, you want to make sure you get your point across strongly and clearly, but also politely, especially if you’ve been helping that user. You don’t want to freak the person out by suddenly moving from helpful friend to iron-fisted authority figure once you decide to warn them. A more formal warning should focus on educating, not yelling at the user. The clearer the information is, the more likely the user will be able to fix their mistake and comply with the policy in the future. Allow for more than one chance, and remember: assume good faith.

Policies Webinar 2013 Slide31

Policies Webinar 2013 Slide32

The Harry Potter Wiki has two great ways of organizing their policies. One is a dedicated category, which I talked about earlier. Another is a policy template. This template lists all of the policies, and it lives on each policy page. That way, when you're reading one policy, you instantly know what all of the other policies are and which ones might be related to the one you're reading. It saves time from having to scroll down and click into a category, because it’s right there when you’re reading a policy.

Policies Webinar 2013 Slide33

The DragonVale Wiki is another example of policies in action, but in a different way. DragonVale has a number of great policies, but there was also a period where they were difficult to enforce. The wiki was in a bit of turmoil, so they needed to sort that out and make sure that they got to a place where they could effectively enforce their policies and have everyone play nice. Once they did, they were able to become a great community that works together to build a resource about DragonVale.

Policies Webinar 2013 Slide34

Another great example is the Monster Hunter Fanon wiki. Recently I chatted with Master Ceadeus 27, an admin there who shared with me the policies on his wiki. One page I really thought was a great idea was there simplified ruleset page, which you can see a screenshot of here. This is a simple list of local policies, which a contributor can quickly browse.

Policies Webinar 2013 Slide35

Policies Webinar 2013 Slide36

Other Webinars

This image was uploaded by FANDOM Staff.

Appears on these pages