Wikipedia:Edit this proposal
From Wikipedia, the free encyclopedia
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.
Contents |
[edit] Editing the proposal
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 consensus decision-making, something we talk about a lot on Wikipedia but usually end up equating with votes and majoritocracies. 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.
[edit] Be bold, but not reckless
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.
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.
[edit] Using straw polls
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.
[edit] Refactoring talk
Another thing everybody is encouraged to do is to refactor the talk page. Not archiving, refactoring. 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.
Wikipedia:Refactoring 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.
