Posts Tagged ‘batman’

Developing communities on smaller wikis

September 8th, 2009

I originally wrote this for another purpose. I thought it might be interesting to people on my FList in regards to how we run Fan History, how we have gone about doing certain things, what has worked and what hasn’t worked. This has been slightly modified to be more applicable for a wider audience.

Fan History, like other small wikis and multifandom projects, has had a problem with community identity. Most of our contributors don’t as Fan History community members or members of fandom. Instead, they identify as say Batman fans, Harry Potter fans, Twilight fans. This is a problem that we have been working to solve, even as we try to increase identity and participation inside those specific communities. We’ve been most successful at creating identity by doing two things: Having content that interests people that is not specific to any one fan community and by creating large amounts of content that help demonstrate the size and scope of the whole fan community. We’ve found that both solutions, in terms of content development, have been rather successful. Fan History has covered several fandom kerfluffles that have brought brand awareness. The kerfluffles cross fandom lines in terms of interest, principally due to the large number of people involved. Fan History also has worked to improve our definition pages. These articles connect fandoms by offering definitions from different communities, give examples from across fandom and link to panfannish discussions regarding the terms. People can really begin to see how various fandoms are connected. As a result of these kerfluffles and terminology articles, our visitors have poked around a fair amount. We’ve also blown out our content, going from representing roughly 3,000 fandoms a year ago to representing over 36,000 now. We’ve added a over 25,000 articles about specific pieces of fan fiction, added over 50,000 articles about episodes of television, and added over 50,000 articles about LiveJournal community users. All of these articles have helped the fan community understand that Fan History is for them, that it covers topics that are relevant to them, that it is easy to plug in their own knowledge in to our framework with out fear. Both of these strategies have been successful in their own ways. Definition and kerfluffles ways have helped foster a greater sense of fannish community in the whole of the fannish community. They have helped to increase our traffic and our brand identity. Blowing out our content has not necessarily been as successful in terms of fostering community development inside and outside the wiki. It has helped some with our brand identity and it has with our conversion rates in getting people to contribute to the wiki. These solutions, going hand in hand, have really been successful for us.

Beyond content development, we’ve tried several things to encourage community development and to increase the number of edits that an individual makes. For a while, we tried to welcome new members and individually thank IP addresses that contributed to Fan History. We also tried barn stars. These strategies weren’t very successful in terms of converting a one time or occasional editor in to a regular editor. Our admin team discussed the situation, brain stormed ideas where we could be more effective at community building and helping our contributors; in response, we changed tactics. Our policy became to look more closely at specific edits and monitor for certain types and then respond to offer assistance that addresses those edits. One example involves articles about fan fiction writers. In some cases, they have changed their pen names. When we see edits that indicate that they have changed their names, we offer to help them do that or see clarification as to what they are trying to do. We have found that doing to leads to additional edits to an article to improve it once those changes are made and that the individual will frequently come back to more regularly update the article.

When you’re working on a wiki with a small community, you frequently know the one or two other contributors. You were might have brought them on board. It can sometimes be easier to just send them an IM, a text message, drop them an e-mail. This was a problem that we were occassionally facing on Fan History. Our admin team has become rather close. We often feel like we know what other admins are thinking and respond accordingly. We’ve discussed how this can be bad for a wiki. Our communication channels are not transparent when we do that. It might appear like our admin team is a clique, where our first goal is to maintain our status on the wiki and in the wider fan community. The team made a commitment to using talk pages to discuss all manner of things that we are doing. This includes how to avoid drama that may reflect poorly on us, what sort of content we want to develop, issues with templates, where we need a bot to be run to fix spelling or categorization issues and more. We tried to make sure that in discussions with contributors that more administrators were engaging the community. We tried to balance that so it wouldn’t look like we were dog piling on our contributors. This has been rather successful. Our engagement on the wiki has help our community relations outside the wiki because people can see what we are doing, have the tools to more fairly evaluate our decision making processes and members of the broader fannish community feel like they can approach on wiki or off to deal with concerns that they may have regarding our content. It has also helped internally by improving our communications with users, by making it easier to implement contributor feedback and by fostering a sense of internal community.

Wikis tend to need to define the size and scope of their mission, how to create content to meet their mission, policy creation and how they will enforce their policies. Much of this involves internal decision making that will have an impact on external factors. If the scope is too big, it will be hard to develop content or make the project feel overwhelming. If it is too small, the wiki may turn into a pet project that doesn’t have a large possible pool of contributors to draw from. If they create content with complex templates when they are first starting off, that may prove a barrier to entry for some people who read the content. If the wiki policy is too restrictive, people may not feel like they can contribute because they don’t want to break the rules, understand complex categorization policies or how to create stub articles that are acceptable. If it is too open, there is the potential for a lot of drama as people seek to dominate in certain places by sheer force of will. These are issues that we’ve been working on with Fan History. We’ve worked on policies with both the internal community and external community in mind. The point of the policies has always been to serve the community that exists on the wiki, to serve the information and make it as best as we can, and to be accessible and culturally appropriate when dealing with external critics. For content, we defined our scope and then went the automated route to create stub content to make it clear where the borders of our scope was. According to occasional contributors we’ve surveyed informally, it made the wiki feel less scary as they had base content to start from and they had many examples they could pull from regarding what is acceptable and what is not acceptable. For policy, we made a point of having policy discussions on the wiki and rationalizing those steps so that future wiki users could understand our thought processes. While a well developed community of users does not exist, we went outside the community to our acquaintances who were occasional editors. We surveyed their opinions, incorporated their comments in to our discussion. We invited them to participate in the discussion on the wiki. We also listened to external criticism regarding policies and incorporated that feedback as we developed our policy. The results of this that we are the most proud of involve our deletion policy found at . Community develop on wikis for ones that don’t have the good fortune to go viral is hard. This is a lesson that we’ve learned at Fan History.

It takes a great deal of work to be successful. It can be especially challenging to build a community because for wikis, it is often easy to overlook community aspects because wikis so often focus on content. We’ve learned that it takes building content with the idea of how random contributors will feel comfortable editing, actively engaging contributors in a way that will solicit a response, being transparent in terms of what the admin team is doing to avoid feelings of cliques, making organizational patterns easy to understand so as not to confuse your contributor base, not being too harsh when enforcing policies, and thinking about what your internal community building will mean in the wider community that your wiki is part of. We hope that you can take our lessons and learn from them as you develop a community on your own wiki.

Canonical URL by SEO No Duplicate WordPress Plugin