Consensus for Free Software Projects|
Most software projects work either by some loose form of consensus or by a dictatorial approach of "what the primary maintainer says goes". Here is a brief description of a system of formal consensus for software projects to give a feasible decision making strategy for community projects without needing to resort to voting or dictatorships. More detail can be found in the link at the bottom of this article.
Advantages of Consensus
Firstly, some advantages of consensus to encourage people to stick with it
- It ensures that everyone has the ability to be heard. A minority view can't be "shouted down" or ignored by a majority view. In this way, it empowers individuals to ensure concerns are heard and taken seriously
- While democracy (voting) restricts decisions to a choice between two or more rigidly defined options, consensus is flexible in making proposals and adjusting them until they best suit the community's goals
- Since everybody concerned is able to participate in the decision-making, less effort is required in relaying decisions and documenting their rationale. In online community software projects for example, this can translate to online decision discussions being valid documentation describing why a decision was made.
Potential Problems with Consensus
Of course, there are trade-offs. Some potential problems with consensus follow. Later in this article, specific potential problems will be referred to by their number listed here using the shorthand "ppn" where n is the number.
- If individuals are empowered, individuals can sabotage procedure for personal gain or whim by simply blocking proposals.
- "Groupthink" can occur resulting in nobody wishing to object to an idea due to thinking everyone else wishes for the idea. In the worst case a bad decision can be made that nobody wants but everybody supports because they think the decision is popular.
- Members may be intimidated into silencing their objections in order to speed up process
- Informal consensus can stray off topic and slow procedure
- Consensus thrives on conflict. Conflict can sometimes be violent and/or aggressive. This problem is best solved by good conflict resolution systems.
Mitigation with Formal Consensus
To make consensus an adequately powerful tool for larger communities, users must be aware of its potential problems and find ways to minimise or negate their impact. To do this, formal procedures may be needed. Consensus with a formal procedure is aptly called formal consensus. Here are some suggestions on how to formalise consensus.
Codify the Community's Principles
Formal consensus relies strongly on being able to identify what is and what isn't relevant discussion. To be able to do this, what is considered relevant must be defined. Arguably the best way to do this is to codify the community's principles in some form of manifesto. It needn't be a complicated manifesto, but something which clearly lists each of the community's goals is very useful in determining what is and is not relevant discussion
For example, a software community whose goal is to produce a fast compiler for haskell may quote their principles when stopping language wars or raising concerns about how a patch may adversely affect compilation speed
Be Proposal Focused
Encourage that discussion revolves around tangible proposals rather than vague ideas. In a software community, if somebody has an idea, suggest they implement the idea in code and present the code to the community as a proposal. This way members can readily analyse the proposal, request clarification and raise principle-focused concerns. Ideas not in tangible, well-defined form instead encourage superfluous discussion as people try to clarify their understanding of the proposal.
Mitigates pp2, pp3 and pp4
This may seem strange, but consensus' strength is in conflict. Conflict is how problems are identified, discussed and solved. While dictatorships or democracies may have speedier decision turn-around, they are more likely to overlook or ignore issues that consensus will discover and find solutions for. Conflict in consensus should be a much different beast to conflict found in most other situations. While in debate situations for example, groups choose a position and defend it to the death. In consensus everybody should be encouraged to remember they have the same position described by the community's principles and work together to to achieve the best realisation of those principles using conflict as a tool to identify possible ways to do it.
Though conflict can be a positive thing, it can also turn ugly. For situations where conflict does turn ugly, be prepared with ways to manage it. Temporarily cease discussion on a heated topic and return after things have cooled down. Discourage "debate mentality", emotive words and baiting. Above all, assist each other to identify and encourage a co-operative atmosphere and identify and discourage a competitive one.
Be Concern Focused
Mitigates pp1 and pp2
Consensus is, in a way, an abstraction from decision making, freeing communities from getting bogged down in the details of decision making. While other systems focus on making a decision between dichotomies (eg which alternative, or yes or no), consensus works best by not introducing any dichotomies at all. Instead proposals are made and focus is made on identifying concerns about the proposal. Concerns are only considered relevant if they can be shown to describe how the proposal adversely affects the community's principles. If no such concerns can be found, or all concerns are suitably addressed the proposal automatically has consensus and is passed.
The upshot of this is that calling for consensus preferably should not be phrased in ways such as "does everybody agree"? Whether intentional or not, this encourages groupthink as it places people in a dichotomy of "for" or "against" the proposal. Somebody who may have a concern may not voice it because they don't wish to appear to be taking the side of "against". Consequently, calling for consensus is better voiced in a concern focused way such as "does anybody have any further concerns?". This encourages everybody to think about identifying concerns which is the heart and soul of consensus; and not get caught up in trying to decide whether they agree or disagree with the proposal.
Adopt a Procedure
Adopting a formal procedure allows the community to even more closely define what is and isn't relevant discussion. For example, adopting a proposal could be broken up into a procedure of four separate stages:
- The proposal is described by the proposer. The only discussion permitted is queries and clarification.
- Concerns about the proposal are identified by brainstorming. No detailed discussion about any particular concern is permitted other than clarification of the concern and how it relates to the community's principles.
- Each concern is given an appropriate amount of "floor time" and is discussed until time runs out. Discussion is limited only to finding potential solutions to the concern or identifying how the proposal already addresses it.
- If concerns remain inadequately addressed at the end of their allotted time, each such concern may reach conclusion using one of 3 ways:
- The concern blocks the proposal. The proposal is archived with the concern recorded as the reason for rejection
- Those who are the primary holders of the concern voluntarily "stands down". The proposal may pass but the concern is described in the proposal as one of the proposal's flaws. This ensures that the concern can easily be found again at a later time should a solution be discovered (In software, this may take the form of adding a "TODO").
- The concern is handed to a committee of specialists to discuss the concern further
With such a procedure all members are kept on the same page at all times and tangential and orthogonal discussions are eliminated. Without such procedures, discussion can easily get carried away arguing over concerns when the proposal isn't yet understood properly. If discussion of concerns is allowed at the same time as raising of concerns, more shy members may become intimidated by feeling "shot down" every time they try raising a concern. Also, discussion of some concerns can often become detailed which can distract from the job of finding other concerns or giving other concerns adequate discussion time. Procedure is a tool to ensure consensus is reached by the shortest possible path.
It should also be noted that a procedure should be constructed such that not all stages are necessary. In the example above, if after a proposal is understood nobody has any concerns, the proposal is already at consensus and needn't go through the motions of stages 2, 3 or 4. This ensures that formal consensus doesn't make simple decisions more drawn out than they would be with informal consensus.
Roles are delegated to individuals giving them the task of ensuring Formal consensus is adhered to properly. Examples include timekeepers to ensure discussion of concerns don't take more than their allotted time and facilitators who attempt to keep the discussion flowing smoothly. Roles are designed more with real-time meetings in mind and may be difficult to implement on the asynchronous communication channels generally used by community software projects. They are nevertheless useful tools so if you find a way to make it work without requiring all members to attend real-time IRC or VOIP conference meetings let me know. More information about roles can be found at the link at the bottom of this article.
The bulk of this information was sourced and adapted from A Guide to Formal Consensus. More detail can be found there for further strategies on how to use formal consensus in a variety of scenarios.
Tags: computing, general