Consensus

Change is hard, especially in a consensus-oriented environment. This page seeks to provide guidance about how one achieves adequate consensus to make big changes in the MediaWiki software stack.

Definition

There are many different definitions of "consensus", and even different terms, depending on context:

• "Consensus decision-making" w:Consensus decision-making (English Wikipedia article): "Consensus decision-making is a group decision-making process in which group members develop, and agree to support a decision in the best interest of the whole. Consensus may be defined professionally as an acceptable resolution, one that can be supported, even if not the "favourite" of each individual."
• "Consensus" w:WP:Consensus (English Wikipedia policy): "Consensus refers to the primary way decisions are made on Wikipedia, and it is accepted as the best method to achieve our goals, i.e. to achieve our five pillars. Consensus on Wikipedia does not mean unanimity (which, although an ideal result, is not always achievable); nor is it the result of a vote. Decision-making involves an effort to incorporate all editors' legitimate concerns, while respecting Wikipedia's policies and guidelines."
• "Consensus" meta:Consensus (meta.wikimedia.org): "a mixture across the community of those who are largely agreed, some who disagree but 'agree to disagree' without disaffection, those who don't agree but give low priority to the given issue, those who disagree strongly but concede that there is a community view and respect it on that level, some vocal and unreconciled folk, some who operate 'outside the law'. You find out whether you have consensus, if not unanimity, when you try to build on it."
• "Rough Consensus" - (see also IETF RFC 7282 - On Consensus and Humming in the IETF). To quote the summary: "The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus."
• "Advice process" from http://www.reinventingorganizationswiki.com/Decision_Making - On this wiki (and in the corresponding book), the authors downplay "consensus" and define a new thing similar to "rough consensus", which they call the "advice process". "It is a misunderstanding that self-management decisions are made by consensus. The advice seeker must take all advice into consideration, but can still make the decision. Consensus may sound appealing. But if everybody has a power of veto, this may result in a plea for someone to please make a decision. In the advice process, no one has power over anybody else. Ergo, there is not the power to block progress. Ownership stays clearly with one person: the decision maker. Convinced she made the best possible decision, she can see things through with enthusiasm. The advice process, then, transcends both top-down and consensus-based decision making." The advice process is defined as "Any person can make any decision after seeking advice from 1) everyone who will be meaningfully affected, and 2) people with expertise in the matter. Advice received must be taken into consideration."

Building consensus

Here are the main stages of building (rough) consensus for an idea. Some ideas are so self-evident that they can breeze through all of these steps with the able guidance of a trusted leader. Other ideas are more controversial, and need thoughtful progression through these stages. When an idea to solve a problem encounters resistance, the consensus-minded approach is to get the group to agree on where we are at in the list below (with respect to solving the problem), and build necessary trust to move to the next stage of consensus-building.

Here are 4 stages of building consensus around a complicated engineering ideas and complicated strategic directions:

• Straw dog - Talk in depth about an engineering idea that doesn’t have consensus, potentially evangelizing that idea. At this stage, the goal is to get more people to know about the idea, and maybe more people agree that it’s a great idea. Important exit criteria for this stage:
  • Clear idea of the problem the straw dog is intended to solve
  • Is something we should just "be bold!" about? How do we reverse the decision if it was a mistake? Are there any consequences?
  • Is this an experiment? If so, how do we keep from over-investing in the experiment, thus setting ourselves up for a future sunk-cost fallacy. Find agreement on a framework for evaluating the results of the experiment.
• Problem definition - Figure out what problem we're really trying to solve, and if it's really a problem. Important exit criteria for this stage:
  • Clear definition and agreement on the problem the straw man is intended to solve
  • Agreement that the problem is an important one to solve
  • Consensus on the priority about the importance of solving this problem (or consensus that it isn’t a problem after all)
  • A list of clear problem statements that can be prioritized and can help evaluate proposed solutions
  • A reasonably complete list of viable options for solving the problem

• Field narrowing - Narrow down choices for solving a problem. Important exit criteria for this stage:
  • Consensus about which options are truly viable, where stakeholders have had opportunity (not necessarily obligation) to be part of the conversation.

• Consensus - Arrive at rough consensus about the best solution to a problem. Important exit criteria for this stage:
  • Consensus on the single most viable solution to a problem, with agreement to postpone or eliminate competing solutions from consideration.
  • Bonus outcome: a plan to implement the solution. This is obviously desirable in many cases, but it may be worthwhile to agree on a direction/strategy rather than deciding on an explicit plan of action.

Depending on the complexity and gravity of the solution/direction consensus is needed for, it may be important to hold a meeting (or multiple meetings) at each stage of the consensus-building process. The "Good meetings" page describes this in more depth.

Evangelization

Once you've built consensus to implement something, your work isn't done. If your proposal is innovative enough, that means that it may not make sense to people who are comfortable with the status quo. Furthermore, you should still be open to the idea that you might have been wrong about the idea (and not draw people into supporting it purely via the sunk cost fallacy)

Important elements of evangelization:

• Enlist - recruit people to help implement a solution we have consensus around. In the case of a direction, the enlistment process never ends. For implemented solutions, get people to support/maintain/use the solution
• Educate - Teach people about the solution or feature. In the case of an engineering direction, the enlistment phase may be done, but people will still need education to teach them how to get on board.
• Assimilate - Fit the solution into the wider ecosystem. In this process, you may discover even better solutions to the problem or better directions to pursue. Prepare to work with the wider world, and accept that someone else's solution may be better.
• Evaluate - solid evidence-based evaluation of a solution is often the most effective evangelization. Beware, though, you may learn the direction or solution was a bad idea. Be humble, and figure out how to undo the damage.