You spent weeks drafting a new Wikipedia policy proposal to clarify how biographies of living persons are sourced. You posted it on the village pump, waited for feedback, and then watched as experienced editors tore it apart. The vote was overwhelming: reject. It feels personal, but it rarely is. Most rejections stem from structural flaws in the proposal itself, not from malicious gatekeeping.
Understanding why proposals fail is the fastest way to get your next one accepted. Whether you are trying to tweak the Manual of Style or introduce a new deletion criterion, the community’s reaction follows predictable patterns. If you can spot these pitfalls before you hit publish, you save yourself months of debate and potential frustration.
The Consensus Misconception
Many new contributors think Wikipedia operates by majority rule. They gather ten friends, cast ten votes, and declare victory. But Wikipedia consensus is not about counting heads; it is about weighing arguments. A single editor with a well-reasoned objection based on existing MediaWiki software limitations or core principles like Neutral Point of View (NPOV) can block a proposal that has twenty supportive comments.
If your proposal relies solely on popularity, it will likely be tagged as "no consensus." To avoid this, you need to engage with dissenting voices early. Ask critics specifically what evidence they need to change their mind. Often, a small amendment addressing a technical edge case turns a hard "oppose" into a neutral stance, which allows the proposal to pass.
Vagueness and Lack of Testability
Editors hate ambiguity because it creates work. If your proposed policy says "editors should strive for clarity," administrators cannot enforce it. What does "strive" mean? Who decides when clarity is achieved? Proposals that use subjective language often fail because they don’t provide a clear metric for compliance.
Successful proposals usually include concrete examples. Instead of saying "sources must be reliable," specify that "blogs hosted on free platforms without editorial oversight are generally considered unreliable unless the author is a recognized expert." This gives editors a checklist. When you write your draft, ask yourself: Can two different administrators apply this rule to the same article and reach the same conclusion? If not, your wording needs tightening.
Ignoring Existing Guidelines
Wikipedia already has over 300 policies and guidelines. Before proposing something new, check if an existing rule already covers your concern. For instance, many users propose strict rules against promotional edits, only to find that Conflict of Interest (COI) guidelines already address this extensively. Duplicating efforts leads to confusion and clutter.
Read the talk pages of related policies. Often, the reason a current guideline seems weak is that previous attempts to strengthen it failed for specific reasons. Ignoring this history makes you look unprepared. Cite past Requests for Comment (RfCs) in your proposal to show you’ve done your homework. Acknowledge why previous attempts failed and explain how your approach differs.
The "Big Change" Trap
Radical shifts scare the community. If you propose rewriting the entire citation format for scientific articles, expect resistance. Editors prefer incremental changes. A proposal that tweaks one subsection of Citing Sources is far more likely to succeed than one that overhauls the whole system.
Break large ideas into smaller, testable chunks. If you want to change how images are licensed, start with a pilot program for a specific category, like historical maps. Gather data on whether the new license reduces disputes. Use that data to argue for broader adoption. Small wins build trust, which you can spend later on bigger reforms.
Technical Infeasibility
Sometimes, good ideas die because the software can’t support them. Wikipedia runs on MediaWiki, and while it’s powerful, it has limits. Proposals that require complex database queries or real-time analytics often stall because volunteers maintain the site, not paid engineers. If your policy requires manual checking of every edit against a complex external database, it’s unsustainable.
Check the Phabricator tracker for feature requests related to your idea. If developers have rejected similar features due to performance costs, mention that in your proposal. Showing awareness of technical constraints demonstrates maturity. It also helps you pivot: maybe the policy doesn’t need automation; maybe it just needs clearer instructions for human reviewers.
Comparing Successful vs. Failed Proposals
To see these pitfalls in action, let’s look at common scenarios. The table below contrasts typical failure modes with strategies that lead to acceptance.
| Pitfall | Why It Fails | How to Fix It |
|---|---|---|
| Vague Language | Subjective terms like "best practice" lack enforcement power. | Use measurable criteria and concrete examples. |
| Duplication | Overlaps with existing guidelines cause redundancy. | Cite existing policies and explain the gap they miss. |
| Lack of Support | No engagement from key stakeholders or admins. | Pre-discuss on project talk pages before formal RfC. |
| Unintended Consequences | Fixes one problem but breaks another workflow. | Run simulations on sample articles to predict impact. |
| Scope Creep | Proposal tries to solve too many issues at once. | Split into multiple focused proposals. |
Navigating the Request for Comment (RfC) Process
The Request for Comment (RfC) is where most proposals live or die. Timing matters. Posting during major news events or holidays means fewer eyes on your text. Aim for mid-week mornings in US time zones, when active editors are online.
During the RfC, respond to every comment politely, even if the critic is harsh. Anger drives people away; patience draws them in. Summarize the discussion periodically. After three days, post a summary of points raised and amendments made. This shows you’re listening and helps undecided voters see the evolution of the idea.
Building Alliances Before You Launch
Don’t go into the arena alone. Identify editors who care about the topic area. Leave messages on their user talk pages inviting them to review your draft. Ask for constructive criticism, not just approval. If three respected editors say "this looks good," others are more likely to agree.
Also, consider the perspective of administrators. They enforce policies. If your proposal makes their job harder, they’ll oppose it. Frame your proposal as a tool that simplifies admin tasks. For example, if you’re clarifying notability for local businesses, explain how it reduces the number of ambiguous deletion discussions admins have to adjudicate.
What to Do After Rejection
A rejection isn’t permanent. Many successful policies were rejected initially, revised, and resubmitted six months later. Analyze the opposition. Was it about wording? Scope? Technical feasibility? Address those specific concerns. Wait until the emotional heat dies down, then launch a new thread referencing the old one. Say, "Based on feedback from [Previous RfC], I’ve adjusted the proposal to..."
Keep a log of rejected proposals. Over time, you’ll notice patterns in what the community accepts. You might discover that proposals involving content creation pass easier than those restricting editor behavior. Use this insight to shape future drafts.
How long should I wait before resubmitting a rejected proposal?
There is no fixed rule, but waiting at least three to six months is advisable. This allows community sentiment to shift and gives you time to significantly revise the draft based on previous feedback. Resubmitting too soon can annoy editors who feel their input was ignored.
Can I appeal a consensus decision?
Yes, but appeals are rare and difficult. You must demonstrate that the consensus was flawed-perhaps due to sockpuppetry, lack of notification to relevant projects, or misinterpretation of core policies. Simply disagreeing with the outcome is not grounds for appeal.
Do I need administrator support for my proposal?
While not strictly required, having several administrators express support increases the likelihood of success. Administrators enforce policies, so their buy-in suggests the proposal is practical and won’t create excessive workload. However, broad community support is ultimately more important.
What happens if there is no consensus?
If an RfC ends with "no consensus," the status quo remains. Your proposal effectively fails, but nothing prevents you from revising it and starting a new discussion later. Sometimes, splitting a controversial proposal into smaller parts helps achieve partial consensus.
Are voting mechanisms used in policy proposals?
No, Wikipedia uses consensus-building discussions, not simple votes. While some informal polls exist, official policy changes rely on reasoned arguments. A proposal with 10 supporters and 5 detailed objections may fail, while one with 5 supporters and 1 strong objection that gets resolved may pass.
