Wikivoyage:Consensus/Draft

Shortcut:
Consensus

Wikivoyage determines virtually everything by consensus. As a rule decisions are not made on this site by majority-rule voting. Please remember that the result of any Wikivoyage article will be the consensus view of contributors to that article.

Definition of consensus

What consensus is

When you edit an article you impose your view on it. But the person after you imposes theirs. Only that which all the contributors can accept ends up being left in the article. As a result most articles will end up being fair—that is a view that all contributors accept—in short—consensus.

Consensus is not just a policy; it is a fact of life on a Wiki. Because anyone can edit, anyone can change what is already there, or write something new or different. Then somebody else can come along and change it again, take things away, move things around or even change it all back to what it was to start with, perhaps even deleting the article entirely.

Wikivoyage does not use voting because, unlike consensus, it does not require that contributors present their arguments and carefully respond to each others' arguments. In short, it depresses the kind of careful analysis and discussion that ensures that changes are made thoughtfully. Moreover, voting is complicated by the realities of the semi-anonymous online world; it is often not possible to ensure the one-person one-vote model of majoritarian democracy. There are a couple of pages specifically devoted to voting, most prominently Project:Votes for deletion, but even there, the voting model is not majoritarian and voters are required to justify their vote with a deletion rationale.

What consensus is not

• Consensus is not unanimity. While we should always try to find a solution that works for everyone, in practice this is not always possible. Make sure all concerns are discussed and addressed, but consensus can still be reached even if compromises that please everyone cannot be found.
• Consensus is not a majority. While it would be rare that consensus would be declared when the result represents a minority opinion, well-reasoned arguments based on existing policies and practice should carry more weight than a "support" comment that is unaccompanied by any sort of reasoning or justification. Similarly, attempts to game a consensus-building discussion by canvassing or using sock-puppet accounts may be ignored when determining whether a consensus has been reached. Note that the bar for determining a consensus should be higher when changing a past consensus, so while a small majority might suffice for resolving a minor issue, a super majority backed by strong arguments should be required before changing past consensus (see also #Status quo bias).
• Consensus is not created without participation. Plunge forward when updating articles, but if there is disagreement, or if you want to change a site policy or practice then feedback should always be solicited, and the more important the decision the more voices should be included in the discussion. Ensure that interested individuals participate in a consensus-building discussion by soliciting feedback in the Pub and at Wikivoyage:Requests for comment; particularly in regards to changing site policy, never declare a consensus when there is a lack of participation in a discussion.

How to build consensus

Congenially ready to move forward

Start a discussion

When changing an article, unless you feel the change will be controversial simply plunge forward and make the change. If anyone cares enough to undo your change then they will need to at least explain why, and discussion will need to take place to come to a mutually acceptable agreement. Note that while you should usually just plunge forward when changing articles, for policy pages all non-trivial changes should be discussed first.

Consensus is most often built on the talk pages of the articles to which a significant change is being proposed. First scan the talk page (and its archives) to make sure that your issue has not already been discussed (if it has, make sure you understand the previous discussion, so you can respond to it). Then leave a message either at the bottom of the existing discussion or under a new section header, in which you explain your proposed change and your arguments for that change.

Consensus building can sometimes happen quickly, as a flood of Wikivoyagers pour in their support for your new proposal, exclaiming "Why didn't I think of that?!". In such cases it is abundantly clear to all participants that there is agreement, and the consensus can be implemented quickly.

Solicit feedback and be persistent

Most often consensus building is hard work that requires persistence.

Sometimes it is most difficult to find someone else who is interested in the issue at all. If no one responds to your talk page message there are some options for soliciting comments. One avenue is to leave a request at Project:Requests for comment or in the Pub. If you are proposing a change where there is existing discussion, try leaving messages on the talk pages of the contributors to that discussion, asking them to comment on your proposal.

Be prepared to wait. Add the discussion to your watchlist and be prepared for the fact that no one might be interested in this proposed change for a long time. While a wiki is constantly being edited and grown, individual articles may at times languish in obscurity before growing in leaps and bounds over the space of a few days. While no one may be interested in your proposal in the present, someone may come along later who agrees with you and is enthusiastic about working on your proposal with you.

Structured consensus building

In almost all cases consensus building begins as an informal discussion where ideas are discussed and individuals offer feedback. In simple cases the consensus resulting from that discussion will be clear, but in many cases that informal discussion will not result in an obvious solution that most of the participants can agree to. In these types of discussions changes to the original proposal may be suggested, people will express a variety of opinions, and a more structured discussion will often be the only way to determine a path forward.

When there is no clear consensus a structured discussion can take place that begins with a specific proposal (in its own sub-section of the talk page) that is developed from the informal discussion and takes into account feedback that has been provided. In some cases this proposal may be wording to add to a policy page, a list of options to choose from, or some other change that is to be decided upon. It is very important that the proposal be clear about what is to be changed and incorporates feedback from the informal discussion - if there are still details to be worked out, continue the informal discussion in order to draft a proposal that makes it obvious what will be done if consensus is reached.

Once a specific proposal has been made, those contributing to the discussion should then respond in a way that clearly indicates that they Support, Oppose, are Neutral, etc, and also includes a sentence or two explaining the reasoning for that opinion. When possible, cite existing Wikivoyage policy or practice. See Wikivoyage:Votes for deletion for an example of this discussion format in use. If you change your opinion during the course of the discussion, strike out your previous comment (example: Oppose Support), or in some other way make it clear that you have changed your mind.

Determining consensus

After an appropriate amount of time it may become clear what the preferred solution should be, but remember that consensus-building is not the same as voting, since the strength of the arguments being made is more important than the number of individuals expressing support (or opposition). If there is no obvious consensus after an appropriate amount of time, solicit an admin (preferably one who has not been involved in the discussion) to review the discussion and declare an outcome. The reviewing admin should consider the strength of the arguments being made, the intensity of support for the proposal, and then summarize their opinion of the consensus. If support is split but arguments on one side are weak, consensus should generally favor the side with stronger arguments. If support is noticeably higher for one argument and arguments are equally strong for either side, consensus should generally favor the position that has received more support.

Results of the consensus-building discussion may be to implement the proposal, not to implement the proposal, or if support is split it may be "no consensus". In a case of "no consensus" the discussion can continue, but most often a lack of consensus means that the status quo should be maintained. Note that a lack of sufficient participation can also be a reason to declare "no consensus" - in general, bigger changes should require greater participation, so while a discussion about changing a minor article's lede image might be done with just a handful of participants, a major change to a longstanding policy should include enough participants to ensure the discussion reflects a representative sample of the site's editor community. If consensus is declared, or if "no consensus" is declared and the discussion does not continue, the {{consensus}} template should be placed at the top of the discussion to indicate the result of the discussion.

Contributing to a consensus building discussion

• Address existing arguments. Having a strong opinion is fine, but simply voicing opinions is unhealthy for collaborating on a wiki. In objecting to a proposed change, it is necessary to address any specific arguments given in favor of the change, and to explain why you think they are not sufficient to sway your opinion. This process, of responding analytically to arguments you disagree with, will help you understand the other side of the issue (and help those who disagree with you understand your side), and therefore will help all parties involved to work together to come to a final resolution.

• Keep an open mind as new arguments are introduced—there is no shame, only wisdom, in being convinced by other discussants and changing your opinion. As consensus does not require unanimity, it is considered classy to state that you will respect the consensus being built and stand aside if you find yourself alone in your position, even when you feel sure that your position is correct. This helps to build good will on the wiki (known to the wiki world as BarnRaising) and to build respect for you and your account!

• State a positive case. Say how you think things should be, not just how they shouldn't. Adding ideas, rather than just criticisms, leaves more room for compromise and can lead to an overall better solution. Who knows, maybe your idea will be the one that is ultimately accepted! If you can't think of a positive case, perhaps reconsider your arguments in that light. The current proposal may not be ideal, but may be the best solution available right now.

• Avoid ad hominem. Focus on the arguments being raised and not the people raising them. Not only is it bad form, but it is an unlikely way to convince people of your point of view.

Status quo bias

Overturning an existing consensus is very difficult to do. If hard work was put into establishing a consensus in the past, people will be reluctant to accommodate proposals that would undo that hard work unless 1) new facts or compelling new arguments are introduced into the discussion and 2) there are compelling advantages to do so. If the benefit of your proposal is marginal, but would undo a consensus that took a lot of work to accomplish, it is unlikely that people will support your proposal.

In the case that a consensus becomes impossible—those involved have carefully responded to each others' arguments, but remain in disagreement—we stick with the status quo practice. (If there is no status quo practice, a compromise solution may be necessary.) This lends Wikivoyage a strong status quo bias. While sometimes frustrating when you want to make a change, this bias is deliberate because it encourages Wikivoyagers away from endlessly debating intractable issues and towards the purely productive work of adding new content, rather than sparring over existing content.

Pitfalls

Slippery slopes

As a project, we must be able to include X and explicitly exclude Z. A slippery slope argument—"'X' leads to 'Y' which leads to 'Z', therefore 'X' leads to 'Z'"—is usually a fallacy, and we do not want proposals to be vetoed because of unjustified fear of where it may lead us. Yes, we can discuss both X and Y and draw the line before Z. For example, we can discuss the best country music to come out of Tamworth, but a list of Golden Guitar winners would be out of scope. The irrational fear that we will become a discography should not stop a Wikivoyager from writing about a destination's musical importance. The reverse is true as well: the mere fact that we may include some musical information when relevant doesn't justify adding a list of your favourite mp3s for a bus trip.

Disagreements

Always remember that whatever you write will be changed by the next person to contribute. The more controversial or disagreeable your writing, the more likely it will be changed. You cannot stop this from happening. If the views of the various authors of an article disagree too much an edit war will ensue. Radical or controversial changes should always be discussed - first.

If you do plunge forward and make significant changes to an article, give a reason for it. Use the summary line on the edit form, and, if you feel you are making changes someone else might oppose, also put an explanation on the talk page.

Unless it is clearly vandalism or graffiti, simply reverting somebody else's changes will normally be unhelpful. If you disagree with the changes that have been made, try to find a midpoint between your position and the other person's; something you can both agree on.

See also

{{WikivoyageDoc|policies}}