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.ar...@piuha.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/