Wikipedia:Method for consensus building

This is a recommendation of a consensus building method for Wikipedia talk pages and other discussions. Participants should observe from their experience what changes are needed. The intent is to adhere to keeping it simple and avoid instruction creep as much as possible.

Wikipedia typically uses consensus to make group decisions. Left to their own devices, discussions often don't end well. Wikipedia's decline in participation has been the subject of a Wall Street Journal front-page article. Dissatisfaction with unproductive discussions has been cited as a major problem for participants. A WikiMedia Strategy task force also considered ideas for improving consensus-building processes. And that decline has still continued for years.

This consensus-building method encourages results that include all the editors' stated positions. Importantly, it also mitigates the ability to filibuster or obstruct a discussion. It does that by requiring editors to state their positions up front, and obligating editors who object to a proposal to make a better proposal that includes all sides. An editor who does not make an effort to meet those obligations is more visible in having not made an effort to include others' views, and may be excluded from the discussion if necessary to reach a conclusion. It makes it easier to show who is acting in good faith.

Even with that said, we're all human. So it can't possibly be perfect. We're looking for an improvement good enough to make Wikipedia more fun, or at least not setting up valuable volunteers to drive each other away, while retaining its basic principle of large scale consensus-based decision making. Remember the saying, Perfect is the enemy of done. So let's find what it takes to achieve these needed improvements in consensus building!

The consensus-building method

edit
 
Flowchart of basic consensus decision-making process.

In general, these steps follow the basic recommended consensus decision-making process.

Discussions start as usual

edit

If the matter can be resolved through simple direct discussion, then this consensus-building method does not get involved.

Editor posts a position

edit

See position message box below

Consensus building can be useful in issues where people take sides. In order to begin this consensus building method, an editor posts a message box with their position. The message box links to the procedure document.

Others post positions

edit

Each editor is encouraged to post their position, or agree with an already-posted one.

Though it's acceptable to respond in opposition to a position, it's better to first post one's own position. That makes sure it's among the positions other editors are requested to include in a resolution. In some cases, posting an alternative position may be all the response that's necessary.

Discussion continues

edit

Once positions are known, editors may discuss them. The goal is to find a solution everyone can live with.

Editor posts a proposed resolution

edit

See proposed resolution message box below

Any editor may make a proposed resolution which they believe will satisfy all the parties involved. Each editor participating in the discussion will respond (with traditional bolded wording or a provided template) indicating strong support, support, weak support, neutral (can live with it), weak oppose, oppose, strong oppose.

After a proposed resolution has been posted, any new positions are considered late. Late positions are not valid until that editor posts a counterproposal.

Others make counterproposals

edit

Editors indicating opposition to a proposed resolution are obligated to make a counterproposal which they believe will satisfy the participants. The counterproposal is made with the same proposed resolution message box. Though it may refer to a previous proposal and only specify changes.

"Spoilers" may be excluded

edit

A central point to this method is to channel or mitigate effects of "spoilers", editors who might never compromise in a discussion. It gives them a productive direction and an expectation to compromise. Editors who do not participate in a good-faith effort to move the discussion forward are considered "spoilers" and may be excluded from the result, if necessary to achieve a result. Examples of spoiling behavior include not posting/supporting any position, posting opposition without making/supporting counterproposals, or posting proposals which make no attempt to include the posted positions of other editors. This part of the process is intended to be different.

Consensus is reached

edit

See consensus message box below

A proposed resolution in which all the responses are at least "neutral" is deemed to have achieved consensus. Everyone has in effect said they can at least live with it. The definition of "all" is responses after 72 hours or by all the editors who have posted or responded to positions in the discussion.

Consensus is not reached

edit

See no-consensus message boxes below

If all the proposals fail and there are no new counterproposals, the discussion is considered to be in deadlock and without consensus. Any editor who posted or responded to a position may propose that it is in a state of deadlock, and an action to take. However, alternative proposed resolutions may also continue to be posted.

An editor proposing that consensus has not been reached must in the same statement propose an action to take. The same reaction templates are used in response to these proposals.

  • Postpone the decision because a resolution still appears possible. Perhaps some time is needed for research. Maybe a break is needed for a day so heads can cool down.
  • Accept a resolution which has an existing 3/4 majority supporting it.
  • Accept a resolution which has an existing majority supporting it, and include a minority opinion. The minority opinion may be some text or a link to a user essay. For anyone who wants to make a statement, this gives them all the room they want.
  • Select a neutral third party to refer the question for a binding decision.
  • Abandon the issue as deadlocked. (This should be avoided. But reality dictates it has to be included here.)

See also

edit
edit