Incremental Consensus

Synopsis

This is a conversational-dynamics pattern that can be used to help a discussion move from brainstorming to consensus and decision.

In this pattern, one member of the group becomes the "Editor" of the emerging consensus. The Editor contributes periodic summaries of the consensus so far. All participants present all suggestions in the form of improvements to the consensus of the moment. Participants discuss and vote upon improvements; when approved, an improvement is added to the consensus document.

This pattern is significantly modeled on the IETF process for developing Internet Standards (RFC2418). However, most of that document is concerned with levels of structure that only become necessary when the interest group grows quite large; this pattern extracts the core discussion principals from the RFC and applies them as more appropriate to groups in the handful-to-dozens range.

Context

It's often helpful, in making a complex decision such as a design, to get many people involved in open discussion of the possibilities and requirements. It can, however, be hard to bring such a group to a concrete conclusion. This is particularly a problem when the topic stimulates many participants to great creativity (the well-known "too many cooks" problem, if not the bikeshed problem).

This pattern is invoked at a point when it appears that consensus is significantly accomplished, but the natural discussion does not seem to be able to recognize or capture it.

Forces

• A problem is complex enough to justify the creativity of several people.
• The various experts are well-engaged with the topic.
• General consensus appears to exist, or appears immanent.
• The size of the group interested in contributing to the outcome is modest, say less than fifty.
• It's particularly suggestive if the discussion seems to draw out a lot of "violent agreement," where two or more contributers begin repeating themselves (often with increasing emphasis), and yet some observers see no material disagreement between the points.

Anti-forces

• This approach is unlikely to resolve matters if there are two or more clearly conflicting, mutually exclusive ideas on the table, particularly if they differ as to the fundamental goals or user models.
• This approach is unlikely to resolve matters if there is no group member whom the others can trust to fulfill the Editor role thoroughly and honestly.
• This approach is insufficient by itself when the contributer group is quite large, in the hundreds or thousands (in which case, consider incorporating more of the process of RFC 2418).

Solution

1. The group should agree explicitly to following this process. A sketch of the procedure should probably be presented, so everyone has a common understanding of the process itself. Particular details deserving emphasis:
   • Discussion will center around a proposal document which represents as much consensus as the group can establish toward the solution. At any given time, the proposal document may not be complete, nor acceptable to anyone as a complete solution, but it must be the core of an acceptable solution.
   • Further ideas will be described in the form of improvements to the existing proposal document, linking to existing features and details, explaining in similar terms.
   • Periodically, votes will be taken in some way to add decisions to the consensus document. The group may choose the mechanics of voting as well as the standards for acceptance.
   • An Editor will be the sole curator of the consensus document. As new decisions are added to the consensus, the Editor will add them to the document and submit the new document to the group to confirm that the consensus has been well and fairly incorporated. The Editor may also participate in the discussion, of course, but his contributions as a participant must be clearly separated from his contributions describing the state of the consensus.
2. When the approach is accepted, an Editor is designated. His first responsibility is to capture as much consensus as the group presently has and present the first draft of the consensus document.
3. There are two kinds of Editor contributions:

   Discussion topic lists

   Periodically, the Editor will publish a list of current topics under discussion and, where appropriate, topics that have been explicitly rejected by the group. These should be given some consistent name or identifier, to make them easier to refer to in subsequent conversations, and to search out in archived mail lists. One naming scheme that works well is to number them based on the draft version of the consensus document which was current at the time the idea was first presented: the Editor responds to a contribution containing a new idea with a brief summary of the idea, and the suggestion "let's call that topic 2.13." The topic retains this number even if the consensus document advances to draft 3.0.

   New consensus document drafts

   When the the group reaches consensus on additional points, the Editor adds them to the consensus document. The updated document is published to the group for confirmation that it fairly captures the new consensus. There will generally be other topics on which consensus has not yet been reached; the Editor should also list these along side the new draft in the same way as they are listed in the "Discussion topic list" contributions. Discussion in response to the new consensus document draft should briefly focus on the accuracy with which the Editor has captured the current consensus (and the topics where it's still lacking), before returning to the more general discussion of the remaining open topics.

4. When discussion on a given topic seems to have reached consensus (either for or against), anyone may call for a vote on that one topic. Acceptance of a topic should trigger the Editor to create a new draft of the consensus document. Explicit rejection of a topic (that is, acceptance of the meta-proposal "we reject this idea") does not trigger a new document draft, but should trigger a new Editor contribution, listing the current consensus, the current open topics, and the current rejected topics.
5. Of course, it's always possible that some topic formerly agreed to may need to be reopened, and even that some article of the consensus document may need to be changed or tossed. But this should be treated as an exception: voting for a topic should reflect a sincere belief that the topic will in fact be a part of the ultimate solution.
6. When it seems that the consensus document has converged on an acceptable total solution, a "last call" vote must be held to confirm the document as the final decision of the group. There will often be some topics still open at this point, and closing the document without these topics is not the same thing as rejecting them. But it does mean that they are not part of the core solution; re-proposing them at some later time would be in the nature of an "ECO" or similar process change, and could be required to meet additional qualification criteria, such as showing why conditions have changed to justify reconsidering the matter, since it failed to "gain traction" in the last go-around.

Consequences

• All participants, at all times, have a single clear statement of the consensus so far; there is no doubt as to "what we've decided."
• All participants have a common language (the language of the consensus document) for describing the current state of the plan; no confusion can arise as to which feature is referred to in any remark.
• All new ideas are presented within the context of the current consensus; the suggester applies some of his creative thought to making the new concept fit the established framework: new proposals are made more concrete than in an open brainstorming session.
• A solid, unambiguous record of the debate, easily indexed by the topic identifiers, is available from list archives or meeting notes.
• The final version of the proposal emerges automatically from the discussion, as a side effect of the evolving consensus document; minimal additional edit time is needed after consensus is reached.

Implementation

• It's important that the Editor contributions remain impartial and accurate, and clearly distinct from the general contributions of the person who happens also to be the Editor. If an Editor begins "passing" his own ideas by placing them in the consensus document, people lose faith in the whole process. The immediate review of the document drafts serves primarily to ensure that the whole group agrees that this document reflects the consensus accurately.
• The Editor needs to balance the pace of the discussion, ensuring that everyone is able to contribute, but still making progress toward a final solution.
• If the meeting dynamics become awkward, it can help to glance over RFC 2418 for additional ideas. You might, for example, want to designate a "Facilitator," responsible for keeping the discussion on topic and civil. Or, you might want to appoint Design Teams to create prototypes or mock-ups to validate and demonstrate particular topics. You probably don't want to adopt the entire paraphernalia of the RFC, however: it's a process tailored for the largest cooperative effort ever tackled by humankind; your problems are probably not of quite that scale.

Related Patterns

The most elaborate implementation of this general philosophy can be found in RFC 2418 (also known as BCP 25), IETF Working Group Guidelines and Procedures.