User:Johan (WMF)/On Change

This is a personal essay. It doesn't necessarily reflect the views of the Wikimedia Foundation as an organisation. It's not a piece of communication from the Foundation to the world, but published openly on mediawiki.org merely out of a desire to be transparent.

Change is hard.

Part of why change is difficult is culture. Culture shapes what we see as possible or desirable. At the Wikimedia Foundation, there have been several attempts to describe the various cultures that exist just within the organisation to explain where people are coming from when we internally disagree with each other. Josh Minor has a vastly simplified but apt and helpful division which talks about four cultures in different parts of the organisation. In a lighthearted analysis, he talks about the true believers (recruited from the movement, strong focus on general Wikimedia norms), the yahoos (product development recruits who want to use a vast range of available tools to help the Wikimedia movement grow and become better), the warriors (tech recruits with a strong commitment to open source principles) and do-gooders (people who see Wikimedia as a social movement among other social movements who want to make the world better). But the Foundation doesn’t exist in a vacuum: our decisions are shaped by the Wikimedia movement in general. And so Wikimedian culture helps determine what change is politically permissible, even internally within the Foundation, because we’re not an isolated entity but part of a larger whole. A for-profit exists in a network of vendors, dealers, investors and others who set the limit for what is realistically possible. As a non-profit foundation we are free from those chains, but have to negotiate change in other ways.

On audiences and size

Any well-functioning organisation will listen to its users. They know what issues they are facing, what their current impediments are and what they would want to achieve. At the same time, any well-functioning organisation has to be aware that by listening to its existing users – editors, or contributors, in our case – it is listening only to the people who found the current situation good enough. They will have knowledge and skills that those who have tried to start editing, or have yet to try, lack. They have more advanced workflows and need other tools. And so we face different audiences – which can each be split up in many other smaller groups – with different needs. By listening exclusively to the existing editor corps when looking at what we need to do, we’d risk sacrificing recruitment to replace the attrition of existing editors or bring in knowledge currently missing from the Wikimedia wikis.

When developing new features, we fight the problem of size. Partly because it seems to influence our understanding of success: can we defend spending resources on a feature used by merely ten thousand readers every day? But a key problem is a severe institutional inertia, because anything affecting editing affects hundreds of wikis and more languages than almost any other tool on the planet. Coordinating feedback, making sure we don’t mess with key workflows, and trying to adapt to all the various and very different ways to editing – most communities being blissfully unaware of how different many things work across the Wikiverse, and the near impossibility of having all tools work in a way that accommodates all of them – takes a lot of time and effort. It also makes technical development of the Wikimedia wikis very expensive.

We’re not responsible for handling the content. We don’t merely risk alienating the writers, but more importantly the users who function as the editorial board. At the very least, we need to not actively make their work more difficult than we absolutely have to.

Edits can’t be isolated

A central part of Wikipedia isn’t what is written, but what happens after someone has clicked “publish”. There is nothing particularly sophisticated with our systems for adding information. What we have spent more than twenty years developing is the workflows, practices and tools to handle the effects of anyone being able to edit. For every edit, we need to keep in mind that there is a mirror activity: How will this affect patrolling?  

The iOS and Android Wikipedia apps are good examples. The Wikimedia Foundation started developing apps in 2012, and where the web versions of the wikis had had years to develop tools and scripts and nifty functions, the apps started with a lot of work to be done to catch up and few developers to do it. The project was therefore initially aimed at readers rather than contributors, prioritising the reader experience at the cost of developer time for editing features. This couldn’t continue forever: the Wikimedia wikis depend on readers being able to edit. Reading without editing is an evolutionary dead end for us. The only options for a Wikipedia app without functioning editing – unless the attempt to edit is to throw one out of the app and into the mobile web experience, a confusing option – is an app which doesn’t do much harm because it has too few users to cause much damage, or an app which cannibalizes readers in a way which might actively hurt us by preventing editing. But beyond the good arguments for the Wikipedia apps – they allow us a certain amount of control, being less reliant on fickle search engine traffic –  the limited audience and lack of major community participation allowed them to try out new things to see what could work, something which is more difficult for us to do on the web. The iOS app could experiment with nice reader features, and the Android app with various types of contributions specifically designed for the mobile experience. Since few active editors used the apps to contribute to the wikis, it was a more sheltered environment for testing and trial and error.

But everything we do to edit casts a shadow on the wikis, and when the Wikimedia communities started voicing concerns about the app features, or lack thereof, it wasn’t because these users used the apps themselves, but because they had to handle the effects of others doing so. Both apps, but especially the iOS app, came under fire for the lack of efficient communication tools, frustrating patrollers who tried to help newcomers but felt unable to get through to them, arguing that they had to choose between leaving new editors to make the same mistake over and over and over again for others to fix or blocking good-faith contributors. The Android app, on the other hand, heard concerns about the quality of its micro-contributions. This is a key limitation of change in the Wikimedia world: everything we do has to be handled, and the curators of our information on our large wikis feel stressed and beleaguered, constantly worrying about not having enough time to go through the edits, always feeling like the wikis are under a siege of mistakes, vandalism and disinformation.

And so our inability to isolate new projects makes change difficult, and forces us to re-focus on the familiar needs at the cost of experimenting with ways of reaching new readers and editors. We Wikimedians are human beings, and as human beings we are far more afraid to lose access to tools we currently use than we are eager to win the benefits of the unfamiliar. Loss aversion is a powerful factor in the development of our tools.

Our solutions

We handle this in various ways. In some rare cases we start new wikis, like Wikidata or Wikifunctions. This works for some time. Wikidata was allowed to grow because it didn’t need to adapt to the Wikipedian way of doing things. And yet, to fulfil its role, the Wikidata content needs to be integrated into the other Wikimedia wikis. This is the stage we’re currently at. Sometimes we see that the conflict was merely postponed: while Swedish Wikipedia is happy to use Wikidata for infoboxes or short descriptions for the mobile web, English Wikipedia argues that it doesn’t live up to their norms of sourcing or patrolling, and avoids it. More commonly, we increasingly work with individual Wikipedias, trying to engage one or three wikis in the early development stages of new tools with the help of part-time contractors who know the local community well. That way, we can start small and hopefully have the time to grow from a reasonable size, having a more mature product when it is introduced to more wikis. This doesn’t just make it easier to work closely with the wiki, but also makes it possible for the team to work in an environment where they can be enthusiastic about small numbers of early adopters.

Similarly, beta features are useful not only for testing, but also to be able to isolate the feature for a smaller number of users before it becomes the default. The new is always at a disadvantage in that we know how the old thing worked, and we have to relearn or at the very least get used to the unfamiliar. Here it helps to have a smaller number of users test something while having the option to turn it off if they want to, leaving them in control of their environment. That way, when it’s time to make something the default option, it will have proponents who can advocate for it from a position of having evaluated the tool and had the time to figure out how it can help their editing, rather than reacting with the first initial scepticism most of us exhibit when we have to adapt to something new without actively having asked for it. Those of us who work on developing features tend to overvalue our own innovations, while users tend to overvalue their current practices; this makes it more difficult to find common ground without interlocutors.

We are limited by the fact that we don’t fully own all involved processes, but to some degree share them in partnership with the rest of the movement. This is different from merely having users or customers, who can decide to readjust or go somewhere else: the Wikimedia communities will instead assert their ownership of their workflows, and insist on their share of influence on the tools they use.

In many ways, this is a blessing. But it also makes it difficult to introduce change when change might be needed. Such is the price of success.