TechInfoDepot:Polling is not a substitute for discussion

Polls lead to anger. Anger leads to hate. Hate leads to... suffering.

TechInfoDepot works by building consensus. When conflicts arise, they are resolved through discussion, debate and collaboration. While not forbidden, polls should be used with care. When polls are used, they should ordinarily be considered a means to help in determining consensus, not an end in itself. While polling forms an integral part of several processes (such as TechInfoDepot:Articles for deletion), polls are generally not used for article development. Remember that TechInfoDepot is not a democracy; even when polls appear to be "votes," most decisions on TechInfoDepot are made on the basis on consensus, not on vote-counting or majority rule. In summary, polling is not a substitute for discussion.

A notable exception to this custom is the election of TechInfoDepot's Arbitration Committee members, which was determined by a secret ballot voting system in 2009. In addition, "higher" bodies (such as the Arbitration Committee, Foundation Board of Trustees, or Jimbo Wales) on occasion can impose decisions regardless of consensus.



Why regard polls with caution?
There are several reasons why polling should be regarded with caution:


 * 1) Editors might miss the best solution (or the best compromise) because it wasn't one of the options. This is especially problematic when there are complex or multiple issues involved. Establishing consensus requires expressing that opinion in terms other than a choice between discrete options, and expanding the reasoning behind it, addressing the points that others have left, until all come to a mutually agreeable solution. It is difficult to address objections that aren't stated, nor points which aren't made.
 * 2) Polling may be divisive and cause factionalism. While a poll may occasionally make it a lot easier for people to find a mutually agreeable position, in other cases it can undermine discussion and discourse. In the worst case, polls might cause participants not to civilly engage with the other voters, but merely instead to choose camps. By polarizing discussion and raising the stakes, polls may contribute to a breakdown in civility, making discussion of controversial issues extremely acrimonious. This makes it difficult for participants to assume good faith. In many cases, simple discussion might be better at encouraging careful consideration, dissection and eventual synthesis of each side's arguments than a poll would.
 * 3) Polls might lead editors to expect that a majority will automatically win the argument, or that the result is permanently binding. This contravenes TechInfoDepot's policy on What TechInfoDepot is not (a democracy), and what it is (a consensus).
 * 4) If TechInfoDepot were to resolve issues through voting on them, editors would be tempted to also use voting with respect to article content. This might undermine TechInfoDepot policies on verifiability, notability, and the neutral point of view.

Use of polls when discussing TechInfoDepot articles
On TechInfoDepot, we generally do not line up simply to cast ballots, without some sort of discussion alongside of voting. In some cases, editors decide to use straw polls during discussions of what material to include in various TechInfoDepot articles. Although such polls are occasionally used and sometimes helpful, their use is often controversial and never binding. Where used, article straw polls should be developed in a way which assists in reaching consensus, rather than in an attempt to silence an opposing opinion.

Editor conduct used to be subject to polling in the past, via a system called Quickpolls. This procedure was abandoned years ago because it generated more heat than light. Content issues are almost never subject to polling. Nevertheless, participants on article talk pages do sometimes start polls for gauging opinion, and focusing a long or unruly conversation on a specific question at hand. There is no absolute prohibition on polling, and there are often objections if a poll is summarily closed or deleted on sight using a claim that they are forbidden. Editors who feel that a poll is inappropriate under the circumstances may instead note that further commentary is needed, encourage the discussion to migrate back to a free-form conversation, or open a related discussion.

Straw poll guidelines
Straw polls regarding article content are often inconclusive and sometimes highly contentious. For straw polls to be productive, editors should keep in mind the reasons why polls should be regarded with caution (above). When polls are used, editors should remember the following:


 * 1) The goal of any article discussion is consensus. In the context of articles, straw polls are most helpful only when they help editors actually reach true consensus, evaluate whether a consensus exists, or "test the waters" of editor opinion among a few discrete choices such as two choices for an article's name. It is important to remember that polls do not in themselves create consensus; rather, they are one tool useful for developing mutual consensus and evaluating whether consensus exists.
 * 2) The purpose of a straw poll is to stimulate discussion and consensus. Editors should evaluate the explanations that the participants in a straw poll offer and see if those explanations help to develop their own opinions or suggest compromise. A few well-reasoned opinions may affect a discussion much more than several unexplained votes for a different course.
 * 3) Polls may be helpful in coming to a consensus and in evaluating when a consensus exists, but consensus can change over time. Editors who disagree with a consensus opinion may continue to civilly disagree in an effort to change community consensus. Editors who appear to be in the majority should make an effort to continue discussions and attempts to reach as wide an agreement as possible within TechInfoDepot's policies and guidelines.
 * 4) If a straw poll is inconclusive, or if there is significant disagreement about whether the question itself was fair, then no consensus results from the poll. The solution is to seek wider input or use alternative means of discussion and deliberation.
 * 5) Editors should exercise extreme care in requesting that others participate in a straw poll. See TechInfoDepot:Canvassing, which outlines policy on canvassing (and forms such as "votestacking" and campaigning").
 * 6) Once responses to a straw poll have begun, even minor changes to the phrasing or options of the poll are likely to result in disagreement over whether these changes are fair or if they unfairly "move the goalposts." Because of this, every effort should be made to achieve consensus on the precise questions to be asked before starting a poll.
 * 7) Discussions about article content cannot override TechInfoDepot policies on the neutral point of view or verifiable sources. Nor can straw polls be used to determine a question of fact; such a poll is ultimately pointless.
 * 8) Straw polls should not be used prematurely or excessively. If it is clear from ongoing discussion that consensus has not been reached, a straw poll is unlikely to assist in forming consensus and may polarize opinions, preventing or delaying any consensus from forming. If a straw poll was called on an issue recently, there is usually no reason to call a second poll, even if you think that consensus may have changed or that the first poll was conducted unfairly. If you disagree with the "majority" opinion, simply remember point #3 and continue discussions.

Not-votes
The words "vote" and "voting" have a variety of connotations, but they are commonly associated specifically with ballot-casting or majority voting. For that reason, the use of the words "vote" and "voting" might not be the best choice when describing TechInfoDepot processes. While technically correct, such references may contribute to the misconception that we use a system of majority or supermajority rule. Different terminology (e.g. "polling" and "commenting") may be preferable.

The terms "!vote" (read as "not-vote"), "!voting" and "!voter", introduced in 2006, are sometimes used in discussions to indicate that taking part in a straw poll is not voting, but rather engaging in an act of consensus-building. These terms serve as reminders that while we do vote on things, votes without reasonable accompanying rationales receive little consideration unless you also explain why you are voting the way you are. Votes without rationales sometimes are ignored.

The exclamation mark in "!vote" is the symbol for logical negation and can be read literally as "not vote". It serves as a cute little reminder that it is "not the vote" that matters, but the reasoning behind the !vote that is important.

Petitions
Petitions are even more problematic since they not only encourage the community to avoid meaningful discourse and engagement, but also limit their scope to only one initially-stated opinion or preference with little or no opportunity for discussing and reconciling competing or opposing points of view. As a rule, petitions should be avoided; when they are created, they should be closed and marked historical after a reasonable period of time or once the initial interest in the petition passes.

Deletion, moving and featuring
TechInfoDepot has established processes to deal with certain procedures. These include deletion discussions and featured content. Because these processes are somewhat institutionalized, they are sometimes wrongly assumed to be majority votes. In reality, TechInfoDepot's policy is that each of these processes is not decided based on a head count, but on the strength of the arguments presented and on the formation of consensus.

Because the point of these processes is to form consensus, it is much better for editors to explain their reasoning, discuss civilly with other editors, and possibly compromise than it is to sign a one-word opinion. "Votes" without reasoning may carry little to no weight in the formation of a final consensus. "Vote stacking" is frowned upon because it tends to encourage voters without reasoning. The template Not a ballot can be used to remind editors about this when necessary.

Policy and guidelines
TechInfoDepot policy and guidelines are created by (1) codifying existing practice; (2) through community consensus, or (3) in appropriate cases, as a result of a declaration from Jimmy Wales, the Board, or the Developers. TechInfoDepot is not a democracy; while users sometimes think they should make a "motion" on some issue and "call for votes," but this is not the case. No guideline has ever been enacted through a vote alone.

Polling is rarely helpful in the development of policies or guidelines, and may be counterproductive. Straw polls and votes have been used in the adoption of a few policies in the past, including the adoption of the three-revert rule, and the older parts of criteria for speedy deletion. In those few cases, the polls were put together carefully and only after discussing the matter for a month or more.

The aim of many guidelines is primarily to describe current practice, to help editors to understand how TechInfoDepot works. This means that it is not necessary, and in many cases unwise, to call a vote or straw poll on a proposed policy or guideline. If a proposal is not controversial, doing a head count is not necessary; if a proposal is controversial, doing a headcount to see where the majority lies will not resolve the controversy, and may polarize it further. The controversy may spill onto the poll itself, causing debate on its mechanics. When editors consider a poll ill-advised, they should explain why and if appropriate should vote against the poll itself.

Standards
Once it has been decided by consensus to standardize an issue (e.g. template layout), it is likely there will be several suggestions for standards. Unless one of them is clearly preferred, an approval poll is recommended to select the best-liked standard. This is a way of helping to gauge which of several possible (often similar) versions has the most widespread support, so that the final version reflects consensus.

People
In some cases on TechInfoDepot, community polls are used to determine whether to trust editors with additional responsibilities, in particular requests for adminship and elections for the Arbitration Committee. However, in both cases the poll results are subject to interpretation by the party who makes the decision (i.e. the bureaucrats or Jimbo). Historically, the party making the decision has considered the arguments made, the number of editors on each side of the issue, and any other relevant factors.

In these processes it is preferable if people discuss, ask questions of the candidate, and state their reasonings, rather than simply stating "yes" or "no" with no further comment. While the end result is often obvious based directly on counts of who said yea or nay, it is possible to sway people's opinions by applying solid reasoning and logic. Even so, people new to techinfodepot are often confused, due to the strong resemblance between such structured discussion and a majority vote process, which they are not. There is no exact "target" percentage that forms the cutoff point, although some processes, such as requests for adminship, do indicate a rough numerical percentage for establishing consensus.

Feature requests
Changes to the MediaWiki software are made by the developers and are usually discussed on BugZilla. Some people are tempted to call a vote on feature requests on the assumption that the more people support a feature, the more likely the developers are to implement it. However, this is not always the case, as the developers consider issues of feasibility and server load to be the primary concern.

However, for requests for configuration changes for the English TechInfoDepot, such as enabling or disabling an existing feature, a straw poll may be helpful for the sysadmin tasked with determining consensus for it. Though as with feature requests, the final decision still rests with the Wikimedia sysadmins and, ultimately, the CTO.

Arbitration
Although arbitration is not a community process, it is listed here for the sake of completeness. The ArbCom follows a procedure of listing principles, findings of facts and remedies; individual arbiters discuss these issues and then vote for or against statements and resolutions. However, no "vote" is final until the case is closed. Arbiters can change their positions as a result of discussions with fellow arbiters. In general, findings which attract opposition are reworded to address that opposition, with the aim of reaching a consensus view among the arbitrators. Nevertheless, Arbcom decisions are subject to simple-majority vote.