Re: Last calling draft-resnick-on-consensus

On 10/8/13 8:56 AM, t.p. wrote:
> 1) It does not state its target audience until, perhaps, the reference
> in the Conclusions, to WG Chairs.  [...]  Are
> ADs assumed to be above and beyond the considerations in this I-D:-(
>    
An excellent point. No, *every* consensus caller in the IETF should in 
my view be taking these points into consideration, ADs and chairs alike. 
The examples are full of WG/chair stories, but exactly the same kinds of 
things should happen, IMO, when ADs make consensus calls.
As I said elsewhere, my primary (though not sole) audience is IETF 
leadership (ADs, chairs, editors, secretaries, etc.) and experienced 
IETFers who already understand the basics of our process and/or might 
some day wish to be in such roles. Hopefully the document is somewhat 
accessible to newer or once-in-a-blue-moon participants, but I hope the 
main consumers of this document are folks who need to make consensus 
calls or might some day.
> 2)  There is an extensive discussion on the show of hands and the hum.
> What technology allows you to conduct those on a mailing list?
>    
I don't really talk about mailing lists, and I think you're right that 
it's worth spending at least a bit of time on in the document. In fact, 
neither a "hum" or a show of "hands" (messages?) on a mailing list makes 
a bunch of sense. Methodologically, I think the best way for chairs (or 
ADs) to deal with a mailing list is to checkpoint every so often, 
summarizing issues and perhaps even keeping an issues list, and then 
explicitly calling the consensus: "I hear that people are in favor of X 
and I haven't heard strong objections. Unless there's anyone who can't 
live with X, I am going to say that we have consensus for it." It's the 
same sort of thing I describe for f2f conclusions of consensus. I think 
that's worth pointing out.
> 3) References to working groups with 100 active participants sound like
> a chimera.
>    
The only place where there's mention of large groups is in the last two 
sections, which are specifically the extreme examples. They are 
illustrative examples of the worst case scenario, not meant to be 
representational of the common case.
> 4)  "Five people for and one hundred people against might still be rough
>      consensus".  Can you see the presumption in that?  Read on and the
> following text makes it clear that five are 'right' and one hundred
> 'wrong', but you are presuming that "for" is the right answer.
Yes, that's the example I've used. In this example, the five people have 
made their case for a technical solution, one person has made an 
objection, the five people fully address the objection, and therefore 
there is rough consensus. So in this case consensus was "for". The 
example is meant to show that 100 people blindly piling on the "against" 
side does not make them "right" and does not change the consensus.
> The
> right answer to a consensus call is a consensus,which can be "against",
> as much as "for", something that does not seem to be contemplated here.
>    
Sure. But that would be a different example.

I don't understand your concern here.

> 5) Good WG chairs, and happily there are plenty of them, make their
> presumptions plain, as in asking for information about implementations
> at or around judging consensus.  The views of someone who has
> independently produced rough code is then likely to outweigh those of a
> dozen people who have not, so three such expressing a view in one
> direction will prevail over several dozen who have not in the opposite
> direction.  (This is all right as far as it goes, but I would like the
> views of users and operators to count for even more, since it is they
> who have the most to gain or lose; but sadly, their representation here
> is small and often not apparent).  You quote Dave Clark's aphorism but
> then ignore half of it.
>    
Two things about this:

1. This document is about how we can come to consensus, not about the 
criteria around which we get that consensus (of which running code is 
one). And interesting document could be written about how we do (and 
sometimes don't) take running code into account, but it's not this document.
2. I take issue with one thing you do say above: "The views of someone 
who has independently produced rough code is then likely to outweigh 
those of a dozen people who have not". I think this is actually wrong: 
It is not that the implementer's view is given more weight *because it 
came from the implementer*; that would be an ad hominem judgement. The 
implementer's view is given more weight when it contains a solid 
technical case based on implementation experience. If an implementer 
says, "I've implemented this code and I can tell you that the way you 
are proposing won't interoperate", and someone with no implementation 
experience is able to say, "I can point you to implementations X Y and Z 
that implemented it my way and do interoperate", the fact that it's an 
implementer should make no difference at all. It is the existence of the 
implementation and how well it works that's the trump card, not who 
talks about it.
> 6)  The document is strangely silent about what the vast mass of the
> IETF who are not WG Chairs might do to help reach a consensus,
> such as express an opinion, clearly, technically; else, perhaps, keep
> quiet.
>    
I think the document is useful without this discussion. I certainly 
would not object to adding such a section in the future, but I don't 
think it's necessary in this version. Again, this is mostly aimed at 
discussions of how leaders can facilitate getting to consensus.
> 7) As has been said before when documents like this are up for
> discussion, the IETF is an organisation of engineers and, for the most
> part, we do it rather well.  Managing and leading loose and diverse
> groups of people is more psychology or sociology  than technology, at
> which we are mostly amateurs.  We then go beyond our capabilities and
> get it wrong.  As here.
>    
I'm not clear on how the discussions of how to manage and lead consensus 
discussion that are presented in the document you think "gets it wrong". 
Quite a few folks have found it useful and productive. More specifics 
welcome.
pr

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