Hi,
I definitely agree that this is a really useful document. Lots of good
background and general considerations. But I think it misses two
important points that should be addressed prior to publication:
1) The role WG/IETF mailing lists play in building and
gauging consensus
The draft leaves me with an impression that mailing lists don't play any
substantive role. (Said another way: if I'm participating remotely, or
miss a meeting, how do I hum/participate?) Clearly this is the wrong
conclusion!
I suspect/hope that with all the recent discussion on remote
participation that I really don't need to elaborate on this point any
further.
2) That some participants/chairs/I*s like seeing hands, and that's okay
There are different ways to achieve and determine consensus. As stated
in RFC2418:
Consensus
can be determined by a show of hands, humming, or any other means on
which the WG agrees (by rough consensus, of course). Note that 51%
of the working group does not qualify as "rough consensus" and 99% is
better than rough. It is up to the Chair to determine if rough
consensus has been reached.
I've been in and run many WG sessions where a show of hands is used to
help gauge consensus of those present. I can't speak for others, but
hands are my preference for a pretty simple reason: my hearing is such
that in a large room, hums just don't provide me any real input -- I can
gauge silence vs hums, but that's about it. I know that I've been in
rooms where my conclusion of which hummed response was "greater"
differed from others. Perhaps based on where we were each sitting,
perhaps based on hum frequency, perhaps on my/our hearing. I just don't
know.
I think a show of hands can provide the same input into the consensus
principles described in the draft, and this should be mentioned. Even
just quoting the 1st sentence from RFC2418 listed above in the draft
should help. Adding some words on how a show of hands differs from a
formal vote would be even better.
Lou
On 10/6/2013 5:03 PM, Jari Arkko wrote:
> The document talks about ways in which consensus processes can be successfully run in the IETF. After the last few rounds of versions, I believe this document is ready to move forward.
>
> My goal is to publish it as an Informational RFC. It is an explanation of principles and how they can be applied to productively move IETF discussions forward. While there is no change to IETF processes or any presumption that guidance from this document must be followed, I have found the document very useful. It has been referred to numerous times in IETF and IESG discussions. Consensus is hard and many WG discussions have complex trade-offs and differing opinions. I believe having this document become an RFC would help us apply the useful principles even more widely than we are doing today.
>
> The abstract says:
>
> 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 is a collection of thoughts on what rough
> consensus is, how we have gotten away from it, and the things we can
> do in order to really achieve rough consensus.
>
> Note (to be removed before publication): This document is quite
> consciously being put forward as Informational. It does not
> propose to change any IETF processes and is therefore not a BCP.
> It is simply a collection of principles, hopefully around which
> the IETF can come to (at least rough) consensus.
>
> The draft can be obtained from http://tools.ietf.org/html/draft-resnick-on-consensus
>
> You should see a last call announcement soon, and both me and Pete look forward to your feedback.
>
> Jari
>
>
>
>
>