Wikipedia:Edit this proposal

This is an essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints.

You're most likely here because a proposal page referred you. If that's so, the original contributor has expressed the desire that you boldly edit "their" proposal as a way of reaching consensus. This is not a general policy or guideline. Only if a proposal page explicitly links to here should you be bold in editing proposals; on other pages, you'll have to apply your own common sense and dig up appropriate policies.

No, really, you must. Don't say what you don't like about it—change what you don't like about it, then use the talk page to explain why you made those changes.

This is an experiment in

. Normally, proposals are authored by one person, possibly after some discussion with others, and discussed to death on the talk page while undergoing very little change: everything must be OK'd by the original author. Then a vote comes, and all the people who disagreed anyway shoot it down, along with a flock of voters who've never even seen the discussion and are voting on first impression because they have to speak now or forever hold their peace. Another fine waste of time on Wikipedia.

This proposal is different. It's not going to get voted on unless a large number of people express support and agreement, preferably after having edited what they don't like. If this proposal goes up for a vote and is shot down, it means we put it up prematurely.

Ideally, this proposal should never be voted on if we can't get agreement on the basic idea. That just shows the basic idea is flawed, and we need a completely new proposal.

So be bold and edit, but don't be reckless. Use the talk page to discuss and defend contentious changes.

A proposal is not an article. Think very carefully before you wholesale revert a change, because it's essentially saying that the person before you had a bad idea. That's certainly possible, but it's equally possible that it's actually a good idea that you just don't happen to like because it's not what you were thinking of. The goal is not to push through any one person's view; such proposals are not consensus and will never survive. The proposal is the star, not our egos. So:

• Try thinking about why the idea might be good after all.
• Identify clearly what it is that rubs you the wrong way.
• See if you can remedy the problem with a compromise.
• Consider opposing viewpoints

The talk page is your friend here. Please tolerate "bad ideas" until such time as we've succeeded in convincing the originator that it's really a bad idea. Ideally, they'll retract it themselves, or we come up with a workable compromise. Only in exceptional cases should we override ideas that are wholly incompatible with everyone else's.

Discussion is good, but it's also time-consuming. There's no point in spilling a lot of words over things everybody actually agrees with, and it's only slightly more useful to discuss things everybody actually disagrees with. To quickly gauge whether there's overwhelming (dis)agreement with an idea, use a straw poll on the talk page.

Keep in mind that a straw poll is just a tool for quickly probing opinions. Straw polls should not have opening and closing times as votes do. Instead, just give everybody a chance to chip in with a simple yes or no. Straw polls may trigger discussions instead—that's not a failure, it just means you know that the issue is not clear-cut, which is what you set out to determine in the first place.

A straw poll is not a binding vote, or a way to beat dissenters over the head with the will of the majority. Even if a large number of people vote for one option but some don't, this doesn't mean that that's the "outcome". It means some people are disagreeing, and that has to be addressed.

Another thing everybody is encouraged to do is to refactor the talk page. Not archiving,

. This is a tremendously useful but sorely underused tool; in fact, you'll notice that very few article talk pages use refactoring, and instead people opt for the much easier (and much less useful) archiving.

Refactoring is doubly important for proposals: there is a big tendency to keep discussing the same objections or misconceptions over and over again, just because people think they can formulate it "even better" than their predecessors, or are unsatisfied with existing rebuttals. Editing the proposal to clear up things and address objections helps a lot here, but it can't eliminate the problem altogether: a proposal must remain concise and understandable, and editing to address every objection explicitly results in instruction creep we can do without.

talks at length about how to refactor a talk page properly. Refactoring helps a goal-oriented process, and in this case the goal is to get a proposal we all agree on. Some general tips that are particularly useful for proposal talks:

• Move discussions on a single topic to a single section.
• If discussions on one thing get very large without, move them to a clearly named subpage, and encourage people to use it.
• Use FAQs to address common misconceptions that cannot be eliminated by editing the proposal. Do not add "frequently asked questions" that have never been asked just so you can provide convenient answers yourself—this stifles consensus building because people will be reluctant to override them.
• Encourage people to focus comments on one topic, not to post large brain dumps. If they do post brain dumps, encourage them to refactor themselves.
• Summarize ideas; draw conclusions from lengthy discussions to prevent them from going stale and ending unresolved, sparking the "but I thought we already agreed on this/but we have already discussed this fully" problem. Don't artificially close discussions, but don't allow them to fade away either.

If refactoring turns into pointless edit wars, then take a step back. If someone disagrees with your refactoring, then encourage them to do it themselves. You may find the disagreement was over a trivial matter. If all else fails, then just don't refactor and accept that this particular discussion will be less accessible to readers. Refactoring is a tool, not the Holy Grail of discussion.