The Longest Now

A recent discussion thread on the Wikimedia mailing list led to a somewhat emotional exchange about the pros and cons of publishing budgets and annual plans.

I have worked in organizations that avoided writing annual plans, and did so only when required by a partner. Why? Because it was easier to “get work done” without wasting time producing a summary of our work to show to outsiders. Time invested in summarizing the work of the past year was unnecessary overhead; and time invested in projecting the work of the coming year was unnecessarily binding our hands — what if we wanted to make a sudden change? These orgs also tend to make it very difficult to get a copy of their Form 990s.

I have also worked with organizations that publish everything – their current burn rate, income, future goals, what money will be spent on until it all ran out (and exactly when it will run out!). Most stick to a yearly report and analysis, though some are more flexible.

Wikimedia is firmly in the latter group. We publish our 990s as soon as they are approved; we make our fundraising totals visible in real-time; we produce thoughtful annual plans, and complement them with wonderfully thorough monthly summaries of all of our activities, following monthly metrics meetings which anyone in the world can dial into.

And we develop both our strategic plans and our individual project plans in public — anyone can comment on and make suggestions to each individual project we have ever run. For the most part, this is a warm collaboration: people leave comments, feedback, and suggestions; point to bugs and feature requests filed; and generally track the progress of their favorite projects. Sometimes people share concerns when they don’t like how a project is affecting their editing or reading. And sometimes they are critical of projects they don’t think should be there in the first place.

Across our movement, we have steadily moved towards more and more transparency in our operations and planning. Starting this past year, most Wikimedia chapters publish their annual plans before they are approved. The largest chapters have those plans vetted by an international community body, which oversees distribution of a shared pool of funds. During this process their plans, like most things involving our Projects, are publicly displayed on the Meta-wiki – along with discussion and review of them.

However the Foundation itself remains reluctant to share its plans and particularly drafts of its budget in this fashion. There is perhaps a fear that a public community discussion will lead to (unspecified) bad results, or will be distracting for WMF staff, who will feel compelled to respond to every comment. This does not seem directly tied to any past barrage of comments on plans or budgets – each year this is the source of a fairly small number of comments overall, and most of them are not negative.

The one area in which there is an explicit “call for public comments” followed by a thorough public discussion is in the area of software feature rollouts.

This is a sporadic ritual for software features (not only in this community!).  It is not uniform: some features are simply implemented without great fanfare; Other features are developed with an active body of testers, and then rolled out (with a public page for feedback, but no possibility of reverting the change). Still other features, particularly those that affect the workflow of active editors and reviewers, are tested on a subset of pages and wikis, and then presented for detailed public discussion and a vote. Those that don’t have consensus support in the community are not necessarily implemented; but natural inertia and personal preferences lead to some of those being pushed through despite clearly articulated concerns remaining unaddressed. In those cases where the discussions are not much heeded, they feel to participants like lost time, and can be the most unhealthy of all approaches.

In some language-communities (including German and French), these complex rollouts have been supported by a regional chapter that speaks that language. In the English Wikipedia community, this has not happened. Staff on occasion have developed a tool over many months, which is then not used by EN:WP. This naturally has a negative impact on the enthusiasm of both the developers and the community for such features. And here an odd negative cycle kicks in: the WMF is largely an english-speaking foundation, and does most of its own outreach and communication in English. So it rarely asks for help from one of the English-speaking chapters when organizing a feature rollout. On the other hand, there is an internal narrative about how difficult it is to get community approval for anything – since the feedback process can be long and critical and can end up declining months of work. So most work is done in private, with limited elements exposed to public engagement; and teams spend longer trying to perfect updates before they are rolled out, leading to larger changes in one fell swoop and more surprise and pushback; and rather than rapid release / revision or reversion, with a crunch period after a release, the crunch period is internal in the time leading up to a release, after which any updates or even communication is relatively slow.

We can do so much better. To honor the potential of our collaborative approach, and of our movement (whose default approach to dynamic rolling consensus is the antithesis of this slow uncertainty!) we must. Our communities are made up of people deeply committed to helping one another communicate clearly, understanding all sides of an issue, and iterating through the inevitable wrong versions of things to something rewarding and beautiful.  We are spending most of our time wrestling with self-imposed challenges and frameworks that don’t fit our collective spirit, when flexible iterative approaches would resonate with ambient culture and sources of expertise and strength. We also do much better in many arenas but haven’t turned that into a playbook for all seasons.