Wikimedia Foundation — Back to its roots
Back when there were about a dozen of us at the Wikimedia Foundation, there were tons of blogs and articles about how Wikipedia “got something wrong” and “they” were unreliable. This seemed ludicrous to me, not because the project was always reliable, but because the fundamental feature of the project was that anyone could edit. If someone reading a page knew something was wrong and had a credible source to back it up, why not fix it? Was it really that much easier to write a huge blog post about a few mistakes than just correcting it?
Yes. Yes it was. Becoming a new editor on any of the wiki projects was an unbelievably painful experience. We knew it back then, and we wanted to fix it.
Fast-forward to the present. The staff is rapidly approaching 300. I haven’t been active in the wiki world for a while, and I can see plenty of good work that the foundation is doing. But becoming a new editor is still horrendous.
Why is that? What went wrong? How can we fix it? That’s what I’d like to answer here, in incredibly long detail.
Who would want fewer editors?
Would anyone want to make it harder for people to contribute? The wikimedia mission is to gather “the sum of all human knowledge”. This ultimately means getting knowledge from people’s brains on to a wiki page and updating as appropriate. So, to facilitate this, everybody should have the easiest and most encouraging experiences imaginable to put information into a wiki. What could go wrong?
Attack of the Trolls
In the mid-to-late 2000s, Wikipedia’s popularity became a double-edged sword. Instead of spreading information, people would use it to boast of their friends’ sexualities, sell various commercial wares, push their own agendas, etc. Although one of the major tenets of the wikimedia movement was (and is) to assume good intentions of people editing, this wasn’t always well adhered to, and the existing community took a fairly aggressive, protective stance against new edits.
As a side-effect, newcomers who might need some level of guidance also got burned. This was recognized as being an issue, but you can’t force someone to be nice. And this is, more or less, where the conversation has been stuck at for the last few years.
An alternative: people are just busy
The main interest that (productive) editors share is that they want to write and maintain an encyclopedia.
Contrary to popular opinion, fighting vandalism and reverting clearly biased edits seems to align with the above interests. The software makes it easy enough to revert an edit, and there are various tools editors have developed to assist in this general maintenance activity and do so with zeal across the projects.
Acclimating new users, however, is a different story. For a new editor, we know that their first few edits are incredibly indicative of whether or not they will continue with the project. Those have to be treated differently, and although there are user initiatives to try and help, many early users are still left in the dark, or have a sour enough experience to not return.
By process of natural selection, a good new user in this ecosystem is someone who is OK finding out how the community works on their own. They’re hard to offended, and are good at arguing for their perspective using established community policy and precedent without external guidance or validation .
Some see this as built-in quality control, and maybe the above would be good selection criteria for community leaders, but they shouldn’t be the only people able to put information in to the wiki projects. As it stands though, they are.
My proposal is to have the Foundation work on these problems directly by having paid staff who can identify new contributors, test out different intervention methods, look at their success rates, and iterate and improve on them. This doesn’t seem so radical, but there’s one more component to analyze to understand why it hasn’t happened yet.
The ambiguity of The Community
As a whole, members of the Wikimedia Foundation staff adore the volunteer community they serve. Everyone understands that the “staff” are beholden to the “community” and wouldn’t ever have it the other way around. But on a day-to-day level, it’s not clear what that means.
Say you’re a software developer fixing or adding a feature. You get an email from someone asking you to change how you’re doing your work to accommodate them, and doing so would take a few days. But you also have coworkers who rely on what you do those few days. How do you deal with this? Is this the community giving you a mandate or is it some individual just seeing if you can do something for them? Does it matter if they’re an administrator on a project? Should you bring this issue up during during a team meeting next week, or do you drop everything to deal with this?
These questions were actually very easy to answer in the early days of the Foundation. You were a part of the greater community initiatives and in constant dialog with community members. You knew the relevant people involved, so you could make that kind of call, not as an employee, but as a member of the Wikimedia movement as a whole. It would be the same call any other well-informed volunteer would’ve made.
This changed later as the Foundation grew. While community liaison employees have helped with some of the communication, there’s still lots of tension and ambiguity in terms of when the community can override the Foundation. The most notable example of this is the Foundation creating a super-protected page status, which explicitly allows Foundation employees to override project administrators.
So, rather than dealing with these kinds of tensions and ambiguities, there’s been a natural shift towards taking on projects that are tangential to editing, rather than projects that deal with the daily realities of the editor community, as these will cause less perceived resistance.
This causes a strange paradox: the Foundation dedicates itself to growing and maintaining the project, only to veer away from the core, day-to-day activities involved in growing and maintaining the community behind the project. I only see this trend continuing, and, while it’s a natural human reaction, I think it should stop.
Explicit agreement with the community
Again, in the early days, it was clear that we were working towards a common goal. This was never formalized, as it never needed to be, but it’s something that’s missing from the conversation now. The community has several processes in place(including voting) when someone wants to fundamentally change course. These processes can be slow, but ultimately the community stands by the results of these processes.
While it wouldn’t make sense to use this kind of voting to govern day-to-day affairs in the Foundation, it would make sense to use such voting and discussions to get a consensus on the goals that a particular project is trying to achieve and on the success criteria to determine whether a project met those goals. Then the Foundation would be free to work towards those goals, experimenting and ultimately evaluating these results jointly with the community, all the while knowing the actions they’re taking are being supported by the community as a whole.
Here is my proposal in full:
- Establish some agreed-upon goals in handling the training and support of new editors. This could be as simple as “no new editors will leave due to a lack of understanding of community process”
- Put these goals through standard community processes and refine until they are agreed upon
- Develop the tools/scripts necessary to evaluate success or failure of any given intervention with respect to those goals
- Establish a team of paid employees to try out, refine, and evaluate such interventions, sharing their findings along the way
Adhering to something as simple and straightforward as the above could really help bring the community and the Foundation together, as they were before.