Last of the messages in my list:
On 10/8/13 3:56 PM, S Moonesamy wrote:
The intended status of draft-resnick-on-consensus-05 is
Informational. What we have here is a document about consensus which
will reflect the consensus of the IETF. Should the document reflect
the consensus of the IETF or not?
See other messages. I think the intention is to make it a consensus
Informational document.
...Section 1...introduces the term "full consensus". I took a quick
look and I found at least one occurrence of the term in IETF
discussions [3]. However, none of the IETF process documents use that
term.
See my reply to PSA. I don't think that there's a real need for a formal
definition. I've thrown in the word "unanimity" to clarify.
"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, and the working group has made an informed decision
that the objection has been answered or is not enough of a
technical problem to prevent moving forward, the chair can declare
that there is rough consensus to go forward, the objection
notwithstanding."
The word "objector" emphasizes that there is one person who dissents.
My preference is to consider the objection and address it instead of
viewing the issue as dissent from one person.
That's what the example above says. It is the *objection* that is
answered, not the objector. It is, after all, a hypothetical.
"This document attempts to explain some features of rough consensus,
explain what is not rough consensus, and suggest ways that we might
achieve rough consensus and judge it in the IETF."
The title of the document is "on consensus and humming in the IETF".
According to the above sentence the document attempts to discuss about
rough consensus. In my opinion there a nuance between "consensus" and
"rough consensus".
It's more than an nuance. It is the distinction made between sections 2
and 3.
As a quick reaction I would say that rough consensus provides a faster
path to shape up a proposal. It helps to cut down on document
delivery time to the IESG. The consensus part is sought by getting a
broader perspective.
I'm not clear on what if any change you intend here.
Section 2 sounds like objection-based processing. A binary choice
(re. technical question) can end up polarizing a discussion. The
section provides a good discussion about lack of disagreement.
See my response to Ted on this point. I think objection-based processing
is part of how we come to consensus (rough or otherwise). And I think
this section does talk about the problems of posing binary choices. I've
added text to section 5 on this.
One of the questions I wondered about is whether the person making the
determination should use technical judgement or whether the person
should only make a determination about the comments received. I
mentioned in an unrelated discussion that if it is the consensus of
the group that the sky is green, that's what goes in the document.
The person making the determination can flag it as an issue as a
matter of technical judgement.
I think section 3 is pretty clear that the chair must exercise technical
judgment in many cases. Your hypothetical is the extreme case not
mentioned in the document. If the group says that the sky is green,
*and* nobody questions that assertion, *and* the chair suspects the sky
is not green, I believe it is reasonable for the chair to pose the
question to the WG: "Are we sure the sky is green?" If the working group
simply says "Yes" without explanation, I think the chair is within
bounds to say, just as they are if someone else had raised the issue, "I
don't think the group has truly considered and weighed this issue such
that I can declare (rough) consensus on this point." But this must be
done *extremely* carefully. Chairs who insert their technical judgment
too often or too heavy-handedly risk losing the confidence of the group
as an impartial consensus caller. Better might be for the chair to
(perhaps quietly) solicit a review from a sky color expert from another
working group, asking for them to comment on this sky being green issue.
But having the document go forward with a technical issue that the chair
knows about but that the rest of the working group hasn't noticed is, I
think, to shirk responsibility as a member of the community.
All that said, I wonder if it's necessary to say this in the document.
It's a more general comment about the chair role rather than about
consensus per se.
I'll highlight a point from Section 3:
"Remember, if the objector feels that the issue is so essential that it
must be attended to, they always have the option to file an appeal."
There are very few people who exercise that option.
I think (hope) that if we start thinking about consensus the way the
document describes, appeals (at least in the early form, where it's
simply discussing the issue with the chair or the AD) would not be
nearly so fraught.
According to the title of Section 4 humming should be the start of a
conversation, not the end. BCP 25 states that:
"Consensus can be determined by a show of hands, humming, or any
other means on which the WG agrees (by rough consensus, of course)."
I am not sure whether hums are for a starting point or not. It can be
argued in different ways, for example, see Section 4. Humming helps
to get a sense of the room without people making a decision under
duress. It is a useful way to resolve a controversy. I would say
that it ties in Section 5, i.e. consensus is the path, not the
destination. A show of hands is a disguised way to vote [4].
Yup. See my response to Russ, and some of the changes I've made in the
document. I think this is handled more clearly.
Section 5 identifies a few issues with the way people talk about
"consensus". I understand what Pete Resnick wrote as he has explained
that to me in an unrelated discussion. The text discusses about
"making the call". I don't know whether the reader will easily
understand the meaning of that.
I've added a bit to section 5. Send text if you think it is not sufficient.
Section 6 and Section 7 attempt to explain that a high percentage of
votes in a direction does not necessarily mean that there is rough
consensus for that. I agree with the conclusion in Section 8.
Excellent.
With that, I will send out a new version ASAP. As I said earlier, Jari
has pushed the magic "please let it through" buttons so that I can post
this week.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478