[Fwd: Re: rough consensus (was Re: "trouble maker")]

[Martin Stiemerling]

Hi,

the proposal of Erik sounds good so far, but what I'm missing is that the 
list of choices for rough consensus is missing. It should be documented 
what are the choices have been for voting on. Sometimes there is not only a 
yes/no decision, but a choice a,b, or c decision.

So writing these choices down (nailing them down on paper) would be good as 
well.

Martin

--On Thursday, July 17, 2003 10:51:05 +0300 john.loughney at nokia.com wrote:

| Hi Erik,
|
| This sounds like the best statement that I have heard on 'rough
| consensus' - one additional benefit about this is that if someone
| feels that the 'rough consensus' statement is in error, there
| are processes in the IETF for filing appeals.
|
| thanks,
| John
|
|> -----Original Message-----
|> From: ext Erik Guttman [mailto:erik.guttman at sun.com]
|> Sent: 16 July, 2003 16:22
|> To: Brian E Carpenter
|> Cc: problem-statement at alvestrand.no; Scott W Brim
|> Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")]
|>
|>
|> Brian E Carpenter wrote:
|> > Scott W Brim wrote:
|> >> I like the idea that Chairs should document why they
|> declared consensus
|> >> (or the lack of it).
|> >
|> >
|> > Agreed. But another thing that may be going on is Chairs
|> making consensus
|> > calls too late.
|>
|> The hardest part of calling consensus is its subtlety.  After 100s of
|> emails have been exchanged and a rough consensus has emerged
|> it doesn't
|> really exist (have any reality) until the consensus has been put into
|> words by the chair.  Without a coherent statement posted to the list
|> describing a consensus it is hard to know
|>   - what actions it implies
|>   - whether all dissenting views have been considered
|>   - what compromises were made among those forming the consensus
|>     (what were their positions originally and what did they agree to?)
|>
|> Defending or questioning a consensus call requires mailing list
|> archeology, which is a tedious and inexact discipline.  We should
|> do better and we can.
|>
|> ============================
|> Solution discussion:
|>
|> I have found that by documenting the
|>
|>   - final decision and action to take
|>   - summary of the dominant consensus position taken, including
|>     where they aren't in accord
|>   - well worked out dissenting views
|>   - notes from the WG chair (if needed), to clarify how a difficult
|>     decisions was made and why it is reasonable.
|>
|> This sounds like a lot of writing.  It usually comes down to a page
|> or two, even for very complex decisions.  Advantages of putting this
|> in the record are
|>
|> a) You can point at it when someone wants to bring the topic up
|>     again.
|>
|> b) If the chair overlooks something, it is easy to reopen the
|>     consensus call *for a very specific reason* without reopening
|>     the whole debate.  (Note:  Sometimes WG chairs do not fully
|>     understand the issues they are making a consensus call on.
|>     By writing this consensus document, it is easy to determine
|>     whether the argument has been correctly heard and evaluated.)
|>
|> c) It is a extremely useful to have definitive instructions *what
|>     to do* with a consensus decision.
|>
|> d) Once a consensus statement is accepted by the working group
|>     we have something much more concrete than a record in WG
|>     minutes that such and such was decided upon, etc.
|>
|> Erik
|>
|>



Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  Stiemerling at ccrle.nec.de
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de