This article was originally published in Diff on 3 July 2026 by Lodewijk, licensed CC-BY-SA 4.0. He has been a Dutch Wikimedian since 2005 and is now Chair of the Wikimania Steering Committee. He is a researcher in computational social science, working on technology and innovations in deliberative democracy.

This post makes the case that internal decision-making is quietly stuck. A later post will introduce a prototype to see if we can do something about it. This post describes a project of a working group that formed after the Futures Lab in Frankfurt earlier this year, asking itself what open knowledge communities could look like in the age of artificial intelligence.

Wikipedia has proven to be a remarkable way of bringing together different viewpoints on a range of difficult topics, presented in the form of encyclopedia articles. The Wikipedia community manages all this through an approach based on fundamental trust in the ability of its users to collaborate: an open-source spirit of mutual help, and a liberating invitation for people to 'be bold' and just fix the mistakes. It also puts faith in conversations, through the 'talk pages' connected to every article.

Below, I make the case that Wikipedia communities often do not live up to their intent to be inclusive in internal policy-making; that our policies are more conservative than we realize; and that a large part of the reason is structural – the twenty-year-old format we use to make decisions is quietly working against us. Our processes have been designed with an abundance of time in mind, in an era of exponential growth. That time is over. The good news, which I'll come back to in a companion post, is that there are tangible ways to make these processes better.

When I talk to my friends in some of the larger editing communities across the world, I hear less enthusiastic characterizations about our ability to make decisions internally. In a way, that is hardly surprising: Wikipedians are a peculiar type of people, often more motivated by content than by process. And that is OK. But when I ask those same friends what their editorial and behavioral policies look like compared to a few years ago, the same story comes back again and again: the policies were often written in the early 2000s, and haven't changed much. Not for lack of wanting to, but because it is simply hard.

Notable exceptions are projects small enough to fit in a room: they can simply meet, online or offline, and agree on a new direction. The exact size will depend on the amount of trust, cultural coherence, and so on – but communities where you can recognize all your colleagues by their writing style are fundamentally different from communities where you occasionally wonder why someone isn't an admin yet. Another notable deviation is communities that incorporate the policies of another project by reference or direct translation (e.g. Bangla Wikipedia's NPOV policy).

I am myself active on Dutch Wikipedia, one of those sizable communities with a lot of policies from the 2000s. We have added some (the 2005/2006 Biographies of living persons rules, the Universal Code of Conduct), but serious rewrites have mostly fallen flat. I don't know how well my Dutch experience extrapolates here, but this is one rule of thumb I've heard: policies can often be expanded, new rules can be added to deal with edge cases or novel problems – but it is really hard to agree to rethink how we do things. And not because the current policies are so good.

We know from academic literature that implementing change in an organization is notoriously hard to begin with. In our Wikimedia universe, we seem to have encoded even more thresholds – formalized or implied – that make it hard to change policies.

While there are many corners of Wikimedia policy-making that I have not yet explored, my understanding is that there is a spectrum between "consensus-based" policy-making on one extreme and "voting-based" procedures on the other. English Wikipedia, for example, has an interesting blend of the two, built around the Requests for Comment (RfC) process, which sits mostly on the consensus side. Many of our Wikimedia decision processes, whether it is on-wiki, or in committees, take some elements and assumptions from this process. It would be impossible to discuss each different version and process here – and I will focus on the Requests for comment.

The open-source developers who were a driving force in the Wikipedia community around 2001 were probably more familiar than most people today with what a Request for Comment is supposed to look like. The process is often used to decide on standards, through formal rounds of feedback on a proposal. That makes it very suitable for a setting where you want every expert to weigh in with their best judgment to reach an almost-objectively-correct result.

The way many policy discussions actually play out in Wikimedia is unsatisfactory. In a typical RfC, the proposal is written by a small group of users who often have some incentive to push the policy in a direction. It is then put to their colleagues, who can discuss and criticize it – but who at the same time give opinions on whether it should be adopted. They share arguments, respond to other arguments, propose specific changes that might make them more amenable to support it, and so on. In other words: there's a lot going on at once. The turnout is rarely what you would hope for, in a collaborative project. 150 editors on English Wikipedia, or 50 on Dutch, is considered meaningful.

It is also a very discouraging process at an individual level: when a colleague who is not intimately familiar with these processes wants to participate, it takes a lot of reading-up to understand how the process works, where the discussion is at and how to engage effectively. Not only that, but the process encourages the production of enormous amounts of text and discussion, nearly impossible to process in any reasonable amount of time. This likely biases effective engagement toward a small group of enthusiasts. And the time investment is enormous.

All in all, I see a few challenges that are worth spelling out:

• They do not involve a broad enough representation. Not everyone has the time and energy to participate. By the way we organize it, the cost of participating in a meaningful way goes up. Especially when you are not a native speaker.
• There is no reliable way of closing these processes. Especially in an RfC where the topic or proposal text may shift, and where a lot of interpretation is involved. This is particularly visible on Meta, where many proposals are not closed at all, or do not reach a conclusive result.
• A very small group can dominate the process by simply out-debating everyone else ('veto by attrition'). There are limits to this, but especially on a complex topic, most users who are not very used to the process may feel overwhelmed, and may simply choose not to participate, because they feel they cannot process the entire amount of information to form an informed opinion.
• Herding is possible (although I am not sure this is definitively established to happen) people may form their opinion based on who has participated before them. This could even be negative herding: once you see that someone you do not like has voted a certain way, you may subconsciously find reasons to object to it.
• Anchoring. Once people write down that they have a preference for a certain outcome – especially publicly – it's hard to change their minds.
• It is really, really taxing. It takes a tremendous amount of time to process pages like this, and most of it is not exactly relevant. So when people do, they are likely to miss very good arguments and objections.
• We make it unnecessarily personal by forcing people to use a forum-style discussion to really just collect feedback and preferences.

This brings risks for representation – but it also just makes the process really exhausting. I have not met many Wikipedians who look forward to these discussions. In Dutch Wikipedia, our processes are a bit different with a cleaner split between discussions and voting, but otherwise a lot of my concerns from above apply as well.

These concerns play out differently depending on the size of the community. This is not a small-wiki problem or a big-wiki problem, but the same format fails in different ways. On a large wiki, the challenge is noise: more voices than any thread can aggregate. In such a messy scenario, a bold veteran may be expected to interpret the whole thread and assess some consensus from two hundred comments. On a small wiki, the challenge is scarcity: discussions die of silence, a handful of regulars may constitute the entire "community", and a single dissenter is both a meaningful percentage of opinion and impossible to outlast – there is simply no one to do the outlasting.

Regardless of size, both scenarios risk drifting toward the in-crowd: when the same few people decide everything, every proposal implicitly critiques something they built. Newcomer dissent reads as social friction with people you'll meet in every future discussion, and conservatism follows almost mechanically. Which deters new participants, which keeps the circle small, which hardens the in-crowd. This is exactly what we do not need, when we need to welcome more colleagues into our movement.

I want to be clear about what I am not saying: that Wikipedians are bad at deliberating. The research suggests the opposite: our policy discussions are remarkably argument-driven and grounded in shared principles. The problem is not the people or the quality of their reasoning; it is that we ask a single, twenty-year-old format to do five different jobs at once: generate ideas, refine wording, measure support, change minds, and legitimize an outcome. Each of those jobs needs a different mindset, and arguably a different structure.

Luckily, the world of democratic innovation has not been on hold for the past two decades, and there are models out there from which we could learn a thing or two. I don't pretend to have the definitive answer, but the failure modes above point to a few design directions worth exploring. At a high level:

• Separate the phases. Collecting ideas, improving wording, measuring where the community stands, drafting a good compromise and making a decision are different activities. When they happen in one thread, they sabotage each other – a wording nitpick reads as opposition; an early straw poll freezes a half-baked proposal.
• Make participation accessible. If expressing a position took a few minutes instead of half an hour of writing and reading, we would hear from many more people – including the silent majority that currently only shows up in our imagination.
• Decouple opinions from identity. Most of the herding, anchoring, and personalization problems disappear when you can't see who holds a position while you form your own. On a small wiki, it does something more radical still: it makes disagreeing with the in-crowd costless for the first time.
• Look for agreement. Our current formats surface disagreement by design; you respond to a comment because you object to it. Yet what we usually want to know is the opposite: where does the community already agree? That common ground is the natural foundation to build a proposal on, and today we discover it mostly by accident.

None of this is hypothetical. The civic-tech world has spent the last decade building and testing exactly these ideas – most famously in Taiwan, where the vTaiwan process used a tool called Polis to find unexpected common ground on regulating Uber.

In a later piece, I go a step deeper on what each of these directions could mean in practice – and introduce a prototype that tries to put them to work in our own communities. This prototype may initially work better for committees, wikiprojects or other targeted processes, but hopefully at least manages to trigger the imagination of what a solution could look like where the policy processes take less effort and engage more people. What I hope at least, is that we think and talk about it. Please don't think that your current method is the only possibility!

If this interests you, please reach out! We would love your feedback.

Twenty-five years ago, we built an encyclopedia. I refuse to believe that the way we made decisions in 2004 is the best we can do in 2026. The editors who join us next year deserve rules they can actually read, trust – and change.