rough consensus (was Re: "trouble maker")

[hardie at qualcomm.com]

At 4:21 PM -0400 6/25/03, Melinda Shore wrote:
>  > Someone also reminded me that sometimes you need as high as 95% for
>>  rough consensus and sometimes as low as 65%, varies according to the
>>  topic and the situation.
>
>When you frame the question of "rough consensus" in terms of
>percentages you're actually framing it in terms of voting,
>which we don't do for a number of reasons.  "Consensus" is
>really about the process of arriving at decisions rather
>than the decisions themselves - making sure that all voices
>are heard and respected, and that what you're doing is
>synthesizing information rather than selecting from
>available options.  By choosing "rough consensus" we're
>providing ourselves some protection, in theory, against
>holdouts.

I tried to cover some of the same points in draft-hardie-alt-consensus-00.txt,
which uses steals this text to describe some of the problems using
consensus in our context:
>
>The Conflict Research Consortium at the University of Colorado
>outlines the pros and cons of consensus as:
>
>	The advantage of consensus processes is that the resulting
>	decision is one that meets the interests of all the parties
>	and that everyone can support.  The disadvantage is that
>	developing such a decision can be a very slow process,
>	involving many people over a long period of time.  There is
>	also a relatively high probability of failure. If a quick
>	decision is needed, the consensus approach may not work.
>	Consensus rule processes also tend to favor those that oppose
>	change and want to preserve the status quo. All these people
>	have to do is refuse to support any consensus compromises and
>	they will win (at least as long as they can delay
>	change). (CONFLICT)

I then tried to capture some of the differences between rough consensus
and consensus

>
>     Using "rough consensus" as a guideline limits some of
>     disadvantages of consensus processes by ensuring that individuals
>     or small factions cannot easily block a decision which has
>     otherwise general support.  The second touchstone of "running
>     code" can also limit the disadvantages of consensus processes by
>     requiring that statements opposing particular proposals be
>     technically grounded.
>
>     These limitations do not change the core mechanisms of
>     consensus-building, however, and the IETF process continues to
>     require individual participants both to use their best engineering
>     judgment to select among proposals and to balance their own
>     interests with those of the Internet as a whole.  Active
>     participation and a willingness to compromise, possibly on key
>     points, are needed.  Historically, this has worked because a large
>     majority of participants have recognized that the Internet's
>     growth and enhancement are more important overall than any
>     specific short-term advantage.
>
>     In other words, the use of "rough consensus" is sufficient in most
>     cases in the IETF to ensure that individuals or small groups are
>     heard when they raise technical objections, but that they cannot
>     block progress when a general agreement has been reached.  This
>     document does not suggest changing the usual mechanisms for
>     achieving forward progress; it proposes mechanisms for use when a
>     working group has consensus that it must make a decision, but it
>     cannot make that decision by the usual rules.


Discussion of the draft, and the mechanisms it proposes for use in
these cases does not belong here (solutions at alvestrand.no would be
one place to discuss it), but the recognition of the shape of the problem
is important to scoping how individuals or small groups can affect
the normal process.

			regards,
				Ted Hardie