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

From: <[email-masked]>
Date: Thu, 17 Jul 2003 10:51:05 +0300

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:[email-masked]]
> Sent: 16 July, 2003 16:22
> To: Brian E Carpenter
> Cc: [email-masked]; 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
> 
>

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 17 Jul 2003 10:47:44 +0200

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 [email-masked] 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:[email-masked]]
|> Sent: 16 July, 2003 16:22
|> To: Brian E Carpenter
|> Cc: [email-masked]; 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  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

---

From: Erik Guttman <[email-masked]>
Date: Thu, 17 Jul 2003 11:28:25 +0200

Martin Stiemerling wrote:
> 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. 

Martin,

When I have written consensus statements, I always list the conflicting
positions which were taken and the contours and result of the debate.
The summary reduces complex matters to a synopsis, sufficient for
someone who is interested (but not involved) to follow up on.  Debate
participants can tell immediately whether the synopsis is fair or
slanted and can insist on proper representation in the statement.

 > It should be documented what are the choices have been for voting on.

Presenting things as 'Joe, John, Jim and Jazz argued blah, while
Kevin and Karl maintained bleh.  The WG went with blah because...'
makes the decision resemble a vote; we list people by name, give
numbers of participants and so on, to justify the decision.  By
writing down the grounds for decision, we have a concrete statement
which can be criticized and evaluated.  But this is not a vote. It
is a judgment call based on the generally acknowledged technical
strength of the arguments presented.

We trust in the integrity and insight of the WG chairs and IESG
members to be fair and correct.  A written record improves
accountability.

 > Sometimes there
 > is not only a yes/no decision, but a choice a,b, or c decision.

I agree that a consensus decision may involve a merging of
different positions.  This is subtle stuff.  The output of a
decision is in many cases specific instructions to the document
editor.

Erik

---

From: Scott W Brim <[email-masked]>
Date: Thu, 17 Jul 2003 12:08:06 +0200

> strength of the arguments presented.

Saying who said what is for the meeting notes (so those participating
only by mail can have a deep understanding of what went on there).
Consensus documentation can stick to the issues.