AB, I'm very close to take offense by the statement "...WGs' Chair just follow room's consensus, or f2f participants arguments". We have maybe 200+ working group chairs, ADs and other people that need at a rate, from several times a week to maybe once a months make a "consensus calls". I'm certain that all of does "just" consider the meeting room when doing so. I believe that we have a fairly good view of what rough consensus is, the method to get there and that we are consistently successful in making the consensus calls, the entire working group included. What Pete very successfully and carefully does is that he, investigates a number of parameters that wg chairs and others need to consider before/when making a consensus call. Not discussing "the room" would be a bad thing, but I can't find that anyone is "excluded". You are here discussing, aren't you? One thing that I could have a concern about with Pete's document is that the wg mailing lists are only mentioned twice, but I don't consider that a proposal from Pete to move away from doing most of our work on the mailing lists. /Loa On 2013-10-11 16:50, Abdussalam Baryun wrote:
Hi Pete, I object if the draft excludes remote participants opinions/feedbacks, the IETF WG list is the main place for measuring consensus not a physical limited room located in a region. Some WGs' Chair just follow room's consensus, or f2f participants arguments, which is not best practice relating to IETF procedures. The most important facility of IETF is that it works/decides remotely with individuals signatures/confirmations. AB On Fri, Oct 11, 2013 at 4:02 AM, Pete Resnick <presnick@xxxxxxxxxxxxxxxx <mailto:presnick@xxxxxxxxxxxxxxxx>> wrote: 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/ <http://www.qualcomm.com/~presnick/>> Qualcomm Technologies, Inc. - +1 (858)651-4478 <tel:%2B1%20%28858%29651-4478>
-- Loa Andersson email: loa@xxxxxxxxxxxxxxxxx Senior MPLS Expert loa@xxxxx Huawei Technologies (consultant) phone: +46 739 81 21 64