|
Re: Musing on draft-resnick-on-consensus-01
2013-02-15 11:39:26
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:
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:
On 2/14/13 5:02 PM, SM wrote:
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.
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.
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".
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.
"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:
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.
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.
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.
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.
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
|
|