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