How to Propose a New Policy or Guideline on Wikipedia: A Step-by-Step Guide

Imagine you find a recurring issue in an article that current rules don't cover. Maybe it's about how to cite obscure sources or how to handle biographies of living people who are controversial. You want to fix it, but changing the rule isn't just about editing the text; it's about getting the community to agree. Wikipedia policy is a set of agreed-upon rules and guidelines that editors follow to maintain consistency and quality across the encyclopedia. Unlike hard laws, these are social contracts enforced by peer review. If you want to change them, you need a strategy that respects the culture of consensus building, which is the primary method for resolving disputes and making decisions in collaborative projects like Wikipedia.

Many new editors jump straight into editing the policy page itself. This is usually a mistake. It signals that you've already decided the outcome before discussing the problem. Instead, you start on the periphery and work your way inward. The goal isn't just to write a good document; it's to build a coalition of editors who believe the change is necessary. Without that support, even a perfectly written proposal will be reverted.

Understanding the Hierarchy of Rules

Before drafting anything, you need to know where your idea fits. Wikipedia has a specific hierarchy of documentation. At the top are Core Policies, which are the fundamental rules that almost all editors must follow, such as Neutral Point of View (NPOV) and Verifiability. These rarely change because they define the project's identity. Below them are Guidelines, which are recommended practices that provide more detailed advice on specific topics, like citation formats or naming conventions. Finally, there are Essays, which are personal opinions or explorations of topics that do not have the weight of official rules.

Your proposal likely belongs in one of three places:

• New Policy: Only if a major gap exists that causes widespread confusion or conflict. Examples include creating a new standard for handling copyright issues.
• New Guideline: If you need to clarify how to apply an existing policy in a specific context. For example, expanding on how to handle infoboxes for fictional characters.
• Revision of Existing Rule: If the current rule is outdated or poorly worded. This is the most common type of proposal.

Choosing the wrong level sets the wrong expectations. Proposing a "Policy" for a minor formatting issue will alienate experienced editors who see it as over-engineering. Start with the lightest possible touch that solves the problem.

Preparation: Research and Gap Analysis

You cannot propose a solution without proving the problem exists. Spend at least two weeks observing the relevant talk pages. Look for patterns. Are multiple editors arguing about the same thing? Is there a high rate of reverts? Document these instances with links. This evidence becomes your foundation.

Next, check if someone else has tried this before. Search the Wikipedia Village Pump, which is a forum where editors discuss site-wide issues, technical problems, and policy proposals. Also, look at the archive of the relevant Talk Page, which is the discussion area associated with a specific Wikipedia page where editors debate content changes. If a similar proposal failed five years ago, you need to know why. Did it lack support? Was the wording confusing? Addressing past failures head-on shows maturity and respect for the community's history.

Finally, identify your target audience. Who does this rule affect? If you're proposing a change to biography standards, you need to engage the editors who specialize in biographies, not just generalists. Finding these specialists early ensures you get feedback from the people who actually use the rules daily.

Drafting the Proposal

Now you write. But where do you put it? You do not edit the main policy page yet. You create a draft space. There are two main options:

1. User Page Draft: Create a subpage on your user page (e.g., User:YourName/Draft_Proposal). This is safe and clearly marked as yours.
2. Project Space Draft: Some communities allow drafts in the project namespace (e.g., WP:DRAFT). Check local customs first.

The structure of your draft should be logical and persuasive. Include these sections:

• Problem Statement: Briefly describe the issue. Use the examples you collected during research. Keep it objective.
• Proposed Solution: Write the exact text you want added to the policy or guideline. Make it clear, concise, and actionable. Avoid vague language like "should consider." Use "must" or "shall" only if it's a strict requirement.
• Rationale: Explain why this solution works. How does it align with existing core policies? Does it reduce workload? Does it improve accuracy?
• Alternatives Considered: Show that you thought about other ways to solve the problem and explain why your choice is better. This preempts common counter-arguments.

Keep the tone neutral. Remember, you are writing for skeptics. If your draft sounds too aggressive or too self-congratulatory, readers will tune out. Aim for clarity above all else.

Building Consensus: The Discussion Phase

Once your draft is ready, you move to the public stage. The standard venue for this is a Request for Comment (RFC), which is a formal process where editors seek input on a proposed change before implementing it. You can initiate an RFC on the relevant project's talk page or, for broader issues, on the Wikipedia Village Pump (Policy section).When you post the RFC, include a link to your draft and a brief summary. Then, go out and recruit support. Don't wait for people to find you. Visit the talk pages of articles affected by your proposal. Leave a polite note: "Hi, I'm working on a proposal regarding [topic]. Since you edit this area often, would you mind looking at my draft? Your input would be appreciated." Personal invitations yield much higher engagement than passive posting.

During the discussion phase, expect pushback. This is normal. Listen actively. If an editor points out a flaw, acknowledge it and update your draft. If they disagree with the premise, ask for their reasoning. Avoid circular arguments. The goal is to reach a state where most participants feel comfortable with the final text. In Wikipedia terms, this is "consensus," which doesn't mean everyone agrees, but that no one strongly objects to moving forward.

Implementation and Maintenance

After a reasonable period of discussion (usually two to four weeks), assess the mood. If there is broad support and few unresolved objections, you can proceed to implementation. This involves editing the actual policy or guideline page. Make the edit cleanly, adding the new text in the appropriate location. Cite the RFC discussion in the edit summary so others can trace the decision.

However, your job isn't done. New rules often need refinement after real-world application. Watch how editors use the new guideline. Are they misinterpreting it? Are edge cases causing confusion? Be prepared to make small tweaks based on feedback. This iterative process is healthy and expected. It shows that the rule is alive and responsive to community needs.

If the proposal fails, don't take it personally. Sometimes timing is off, or the community simply isn't ready. Wait six months, gather more evidence, and try again with a revised approach. Persistence, combined with flexibility, is the key to successful editorial governance.

Frequently Asked Questions