Subject: Musing on draft-resnick-on-consensus-01

From: SM <[email-masked]>
Date: Thu, 14 Feb 2013 15:02:02 -0800

Hi Pete,

I was musing on draft-resnick-on-consensus-01.  In the Section 1:

  "We don't require full consensus; that would allow a single
   intransigent person who simply keeps saying "No!"  to stop
   the process cold.  We only require rough consensus: If the
   chair of a working group determines that a technical issue
   brought forward by an objector has been truly considered by
   the working group ..."

The above is about working group consensus.  I suggest adding some 
text in the Introduction Section which mentions that it is about 
that.  The "We only require rough consensus" can be misunderstood as 
being the bar in an IETF-wide call.

  "Participants ask, "Why are we bothering with this 'humming'
   thing?  Wouldn't a show of hands be easier?"

The IAB recently had a discussion about "bottom-up organizational 
modes".  If I am not mistaken (please correct me) the IETF is the 
only organization that uses "humming".  I would say that it works in 
the IETF as it is part of the culture; it cannot be grafted on an 
organization.  There are cases when a show of hands can be used.  The 
sentence that follows the quoted text explains when to use "humming".

In Section 2:

   "The key is to separate those choices that are simply unappealing
    from those that are truly problematic."

I leave it to you to see whether you want to use the following:

    "Any attempt to determine consensus is difficult if the issues 
are technical,
     economic and political. Impassioned discussion, with little 
technical content,
     leads to an impass. It is up to the chair to tease apart the 
points and find
     out how to reduce the amount people disagree on. Find the bounds of the
     conversation. Separate out the technical issues."

Credits to Ralph Droms for the above.

   'This also brings up an important point about reaching consensus:
    Consensus does not really involve compromising.  "Compromising"
    implies that there remains something wrong with the outcome, but
    that the objector has simply given up.'

I read "compromise" as something intermediate between two 
things.  Consensus is used for conflict resolution.  It's not 
possible to resolve an issue if the two sides are not ready to 
compromise.  If you have two sides you end up with a King Solomon 
scenario.  It is very difficult to resolve the issue then.  Maybe 
"conciliatory" may be a better term to express the idea (see text 
quoted above).

The draft uses "objection" and "objector" in discussing about 
consensus.  That works in a formal or legalistic context.  In an IETF 
context you end up being the person standing out as you raised an 
objection.  Arguments do not have to be for or against 
(objection).  It's difficult for me to find the words to explain 
this.  I see that you used the word "concerns" in Section 4.

In Section 3:

   "If the chair finds, in their technical judgement, that the issue
    has truly been considered, and that the vast majority of the working"

Is it "technical judgement" or "the technical issue has been 
considered"?  For the former, the chair ends up taking a technical 
decision.  For the latter, the chair only has to use judgement.

   "that the vast majority of the working group has come to the conclusion
    that the tradeoff is worth making"

If you consider the arguments instead you don't have to get into 
majority and minority.

  "Now, a conclusion of only rough consensus relies heavily on the good
   judgement of the consensus caller..."

I like that paragraph.

RFC 3929 broaches consensus from a different angle.  I'll highlight 
the following: "There must be a clear statement of the decision to be 
reached".  The decision process used to get there is based on 
consensus.  However, it is not easy to attain consensus.  Rough 
consensus is the lesser barrier when consensus is not possible.  In 
other words rough consensus is not the default choice (re: rough 
consensus and running code).  The draft explains that by using 
"single intransigent person" as an example.  Section 2 discusses 
about lack of disagreement.  Lack of disagreement can also be a sign 
that the working group has not carefully considered the question.

It is not possible to reach consensus on the musings in the 
draft.  I'll pick a sentence: "it is a good solution to a real 
problem, even if the non-experts don't have the ability to fully 
judge the details".  There is a theory that the good solution would 
be chosen by a group which includes a significant number of 
non-experts.  If the questions being asked are too complex, it can 
end up with the wrong decision being taken.  If the group is 
segmented (e.g. multishareholder :-)), it can lead to a biased decision.

There are different types of consensus; e.g. the consensus of the 
girls, which is unappealable.

Regards,
-sm

---

From: Melinda Shore <[email-masked]>
Date: Thu, 14 Feb 2013 15:37:19 -0900

On 2/14/13 2:02 PM, SM wrote:
> modes".  If I am not mistaken (please correct me) the IETF is the only
> organization that uses "humming".  I would say that it works in the IETF
> as it is part of the culture; it cannot be grafted on an organization. 
> There are cases when a show of hands can be used.  The sentence that
> follows the quoted text explains when to use "humming".

It seems to me that this kind of misses the point.  Consensus-
based decision making is not simply not voting, but it's processy
and a mechanism for reaching a decision collaboratively.  Unfortunately
it's been the case for a very long time that the IETF does not
actually do that, that participants don't understand what it
means to use "rough consensus" for reaching decisions, working
group chairs often don't understand, IESG members often don't
understand, etc.  So if people in the process tend to see it
as a particular variant on voting, and they're incorrect, it's
probably a mistake to use mechanisms that tend to support the
incorrect view.  Hand raising looks so much like voting that
it's confusing.

> It's not possible to resolve
> an issue if the two sides are not ready to compromise. 

This is probably *the* principal problem in consensus
decision-making.  The participants have to be invested
in making the process work, and in having a mutually
satisfactory outcome.  That's very, very often not the
case in the IETF, and I'm enthusiastic about Pete's draft
as a result - as much about culture transfer as about
process normativity and improvement.

In some sense what's under discussion actually exists in
the IESG, with DISCUSSes being blocking, etc.  The difference,
of course, is that at some level there's an expectation of
altruism from IESG members but not of IETF participants.

There's a huge issue here with education.  And again, kudos to
Pete for taking this on.  It's a very steep hill.

> There are different types of consensus; e.g. the consensus of the girls,
> which is unappealable.

Whut?

Melinda

---

From: SM <[email-masked]>
Date: Fri, 15 Feb 2013 01:27:28 -0800

Hi Melinda,
>and a mechanism for reaching a decision collaboratively.  Unfortunately

Yes (not including the first sentence).

>incorrect view.  Hand raising looks so much like voting that

Consensus-based decision-making is expensive.  The IETF has settled 
for lesser as it is less work for the decision-maker and less work 
for the other side.  The IETF proudly presents:

   We reject: kings, presidents and voting.

   We believe in: rough consensus and running code.

And that created a belief system.

Working groups use polls and "hand raising" nowadays as a disguise 
for voting.  It is understandable (to me) that it confuses 
participants.  One might gain an external view of the IETF by taking 
a look at draft-bollow-ectf-06.

>process normativity and improvement.

Agreed.  I like your usage of "mutually satisfactory outcome".

>altruism from IESG members but not of IETF participants.

Agreed.

>Whut?

I should have written "not subject to appeal".  It means that the 
appeal will be rejected unless there is a miracle.  In the IETF there 
is, for example, consensus by exhaustion.  A girl explained to me the 
meaning of "consensus of the girls".  I don't know whether it is 
applicable to the IETF.

Here's an unrelated story.  A group of people go out to dinner at a 
fancy restaurant.  There is an implicit understanding that everyone 
shares the bill.  However, after the last course you find out that 
one of the persons in the group does not have any money.  What would 
you do an why (an answer is not expected)?

Consensus is not necessarily about compromise; it can be about 
finding the third way.

Regards,
-sm

---

From: Pete Resnick <[email-masked]>
Date: Fri, 15 Feb 2013 10:51:55 -0600

Just to level set: I had not really intended for this document to be 
discussed on the IETF general list quite yet. It still has quite a few 
gaping holes. So even though it is posted as an I-D, I'm inclined to 
have people send comments to me individually for the time being. If and 
when I think it is ready for wide-ranging discussion, I'll be sure to 
solicit comments here. If you do insist on discussing it here, 
understand that sometimes the answer will be, "Yep; gotta think about 
that. Not done yet."

Also note the disclaimer in the document:

       Note: This document contains the musings of an individual.  Right
       now, it is just some rough notes and has lots of holes that need
       to be filled in.  Even if those holes are filled, in its current
       form, it is not intended to be published as an RFC, let alone
       being a BCP for a change of IETF policy.  If it evolves into such
       a thing, great.  If it simply sparks discussion as an Internet
       Draft, that's a perfectly fine outcome.

That said, I'll answer some of SM's comments publicly since he posted 
publicly:

> being the bar in an IETF-wide call.

No, "We only require rough consensus" *is* the bar in an IETF-wide call. 
If I need to make that clearer in the document, I shall. We use exactly 
the same decision criteria for working groups and for the IETF writ-large.

> organization that uses "humming".  I would say that it works in the 
> IETF as it is part of the culture; it cannot be grafted on an 

Melinda addressed this quite well. "Humming" is simply a practice meant 
to reinforce that we use consensus rather than voting as our basis for 
decision making. But as the document says, it is possible to "hum" when 
what you are really doing is voting, and it is possible to use a show of 
hands to help guide consensus. (See section 4, paragraph 4.) The 
practice of humming is not *really* what's important; it's getting 
consensus and not allowing majority rule. Another organization could 
adopt humming *if* it was interested in consensus-based decision making.

> I leave it to you to see whether you want to use the following:

Thanks. One of the big holes I haven't attempted to fill is more 
specific practical advice. That might serve usefully.

> I read "compromise" as something intermediate between two things.  
> Consensus is used for conflict resolution.  It's not possible to 
> resolve an issue if the two sides are not ready to compromise.  If you 
> have two sides you end up with a King Solomon scenario.  It is very 
> difficult to resolve the issue then.  Maybe "conciliatory" may be a 
> better term to express the idea (see text quoted above).

Yes, a couple of people have brought up this section, and I will need to 
expand. The main point is that neither "giving up" (i.e., believing that 
an issue is a real problem, but no longer being willing to discuss it) 
nor "horse trading" (i.e., "I'll let you put your broken thing in the 
document if you let me put my thing into the document that you think is 
broken") is coming to consensus. "Giving up" and "horse trading" are 
failures of consensus. (I distinguish "giving up" from "deciding that 
the document has made a good engineering tradeoff" and "horse trading" 
from "discovering common ground", the latter of which in each case are 
*good* things.) I have to figure out how to make that point more clearly.

> objection.  Arguments do not have to be for or against (objection).  
> It's difficult for me to find the words to explain this.  I see that 
> you used the word "concerns" in Section 4.

Note the title of section 2. Figuring out the objections is the 
important part of coming to consensus. "Thoughts" or "concerns" are 
often distracting to figuring out consensus. I'll try to explicate in 
the document.

> decision.  For the latter, the chair only has to use judgement.

I really meant "technical judgement". This is one of the trickiest bits 
of *rough* consensus. There are times where a chair is truly going to 
have to use their technical judgement to figure out whether the WG has 
truly addressed an outstanding issue that someone maintains is still a 
problem. This is hard. And it requires the good faith of the chair, and 
the trust of *all* of the participants (including the person(s) who end 
up in the rough). And it's where appeals can happen. And it's a 
cornerstone of how rough consensus works. More text necessary.

> RFC 3929 broaches consensus from a different angle.

Quite. 3929 is much more about practical advice. I am likely to get to 
some of that (and will cite/incorporate from 3929 as I can when I do 
so). But mine is more of a "getting our minds around the issue" 
document. And there are certain things in 3929 that I think are serious 
points of disagreement (on the theory) between Ted and I. Those I'll 
also likely need to address.

> Rough consensus is the lesser barrier when consensus is not possible.

That's not quite right. See the discussion re: chair's judgement above. 
When the consensus is rough, it is much more precarious and much harder 
to determine. It's not a lesser barrier; majority rule would be a lesser 
barrier. I'll have to find some words to express this.

> Lack of disagreement can also be a sign that the working group has not 
> carefully considered the question.

That goes back to the "everyone working in good faith" premise. If a 
working group has not carefully considered a question, that's a failure 
across a huge number of people, from participants up through the IESG.

Thank you for your comments.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Feb 2013 12:36:58 -0500

Not to oversimplify the problem or the pursuit for a solution, I think 
there are some possible simple, but perhaps not practical, solutions to 
the concerns you cite.

- Faster Reviews, Resolutions by external people, i.e. IESG or a new 
technical review group specifically for this purpose.  When the WG 
itself is at a impasse, the AD should be able to resolve it, but not 
always there too, due to the issue below.

- IETF needs to recruit more leaders, not overload existing ones. IMO, 
we have fewer leaders responsible for wider cross areas.  This is good 
for proper integration and management but without experience, there 
could be a lost of synergism, diverse engineering insights.  Singular 
mindsets and philosophies can and do emerge (perhaps just with aging).

Currently, I think the system is designed for appeals to occur. When 
apathy develops, lack of confidence in the work, the threats of appeals 
are the last efforts for corrections.   Its no wonder you see new 
process pressures to produce ideas to circumvent them, i.e. fast 
tracking, filtering or watering down concerns, even using tools to 
excommunicate (moderate, block) participants, etc.

Overall, I think more diversity needed, not less.   These actions can 
help with minimizing potential conflicts.  (Note, this is not suggesting 
your ideas is not about diversity).

--
HLS

On 2/15/2013 11:51 AM, Pete Resnick wrote:
> have people send comments to me individually for the time being. If 
> and when I think it is ready for wide-ranging discussion, I'll be sure 
> to solicit comments here. If you do insist on discussing it here, 
> No, "We only require rough consensus" *is* the bar in an IETF-wide 
> call. If I need to make that clearer in the document, I shall. We use 
> exactly the same decision criteria for working groups and for the IETF 
> writ-large.
>
> Melinda addressed this quite well. "Humming" is simply a practice 
> meant to reinforce that we use consensus rather than voting as our 
> basis for decision making. But as the document says, it is possible to 
> "hum" when what you are really doing is voting, and it is possible to 
> use a show of hands to help guide consensus. (See section 4, paragraph 
> 4.) The practice of humming is not *really* what's important; it's 
> getting consensus and not allowing majority rule. Another organization 
> could adopt humming *if* it was interested in consensus-based decision 
> making.
>
>> resolve an issue if the two sides are not ready to compromise.  If 
>> you have two sides you end up with a King Solomon scenario.  It is 
>> very difficult to resolve the issue then.  Maybe "conciliatory" may 
>> be a better term to express the idea (see text quoted above).
>
> Yes, a couple of people have brought up this section, and I will need 
> to expand. The main point is that neither "giving up" (i.e., believing 
> that an issue is a real problem, but no longer being willing to 
> discuss it) nor "horse trading" (i.e., "I'll let you put your broken 
> thing in the document if you let me put my thing into the document 
> that you think is broken") is coming to consensus. "Giving up" and 
> "horse trading" are failures of consensus. (I distinguish "giving up" 
> from "deciding that the document has made a good engineering tradeoff" 
> and "horse trading" from "discovering common ground", the latter of 
> which in each case are *good* things.) I have to figure out how to 
> make that point more clearly.
>
> I really meant "technical judgement". This is one of the trickiest 
> bits of *rough* consensus. There are times where a chair is truly 
> going to have to use their technical judgement to figure out whether 
> the WG has truly addressed an outstanding issue that someone maintains 
> is still a problem. This is hard. And it requires the good faith of 
> the chair, and the trust of *all* of the participants (including the 
> person(s) who end up in the rough). And it's where appeals can happen. 
> And it's a cornerstone of how rough consensus works. More text necessary.
>
> document. And there are certain things in 3929 that I think are 
> serious points of disagreement (on the theory) between Ted and I. 
> Those I'll also likely need to address.
>
> That's not quite right. See the discussion re: chair's judgement 
> above. When the consensus is rough, it is much more precarious and 
> much harder to determine. It's not a lesser barrier; majority rule 
> would be a lesser barrier. I'll have to find some words to express this.
>
>> Lack of disagreement can also be a sign that the working group has 
>> not carefully considered the question.
>
> working group has not carefully considered a question, that's a 
> failure across a huge number of people, from participants up through 
> the IESG.
>