This is a VERY useful document, and I look forward to compelling my WG
participants to read it, with a pop quiz afterwards.
The only issue I see is its length; while dedicated IETFers won't have a
problem reading such a lengthy document, the people who could benefit most -
new, potential or casual participants - will give up early, I fear.
Could we have someone take an editorial knife to it? Some of the descriptions
of situations are quite long, and there's a fair amount of repetition in the
document. Some of the paragraphs are quite long as well. I reckon 2-4 pages
could be saved, making it appealing to a much wider audience.
Beyond that, the only suggestion I'd make is an alternate title -- "Why We
Hum." Or maybe "The Things We Hum And Do Not Say" (apologies to Jerry Maguire).
Cheers,
On 07/10/2013, at 8:03 AM, Jari Arkko <jari(_dot_)arkko(_at_)piuha(_dot_)net>
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
--
Mark Nottingham http://www.mnot.net/