Re: [mpowr] WG Formation
Dave Crocker <dhc@dcrocker.net> Sat, 21 February 2004 21:11 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14744 for <mpowr-archive@odin.ietf.org>; Sat, 21 Feb 2004 16:11:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AueOl-0006zN-F5 for mpowr-archive@odin.ietf.org; Sat, 21 Feb 2004 16:10:55 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1LLAtif026859 for mpowr-archive@odin.ietf.org; Sat, 21 Feb 2004 16:10:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AueOl-0006z8-96 for mpowr-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 16:10:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14722 for <mpowr-web-archive@ietf.org>; Sat, 21 Feb 2004 16:10:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AueOj-0006hb-00 for mpowr-web-archive@ietf.org; Sat, 21 Feb 2004 16:10:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AueNn-0006f3-00 for mpowr-web-archive@ietf.org; Sat, 21 Feb 2004 16:09:56 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AueMu-0006cf-00 for mpowr-web-archive@ietf.org; Sat, 21 Feb 2004 16:09:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AueMv-0006sY-Ac; Sat, 21 Feb 2004 16:09:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AueMt-0006sA-QL for mpowr@optimus.ietf.org; Sat, 21 Feb 2004 16:09:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14693 for <mpowr@ietf.org>; Sat, 21 Feb 2004 16:08:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AueMs-0006c9-00 for mpowr@ietf.org; Sat, 21 Feb 2004 16:08:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AueLw-0006Zk-00 for mpowr@ietf.org; Sat, 21 Feb 2004 16:08:01 -0500
Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AueLg-0006Wp-00 for mpowr@ietf.org; Sat, 21 Feb 2004 16:07:44 -0500
Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1LLFVd05636; Sat, 21 Feb 2004 13:15:34 -0800
Date: Sat, 21 Feb 2004 22:41:29 +0900
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <1974503943.20040221224129@brandenburg.com>
To: John C Klensin <john-ietf@jck.com>
CC: mpowr@ietf.org
Subject: Re: [mpowr] WG Formation
In-Reply-To: <79230247.1076863665@scan.jck.com>
References: <Pine.LNX.4.56.0402040844140.19559@internaut.com> <327742548.1076153200@scan.jck.com> <1943493383.20040214081341@brandenburg.com> <38529151.1076758786@scan.jck.com> <14410174609.20040214094846@brandenburg.com> <19274234.1076779857@scan.jck.com> <52955238.20040214145840@brandenburg.com> <p06100d16bc545a46cf5e@[216.43.25.67]> <1461962205.20040215075530@brandenburg.com> <p06100d1bbc554a8e204c@[216.43.25.67]> <747830562.20040215100030@brandenburg.com> <79230247.1076863665@scan.jck.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: mpowr-admin@ietf.org
Errors-To: mpowr-admin@ietf.org
X-BeenThere: mpowr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-request@ietf.org?subject=unsubscribe>
List-Id: Management Positions -- Oversight, Work and Results <mpowr.ietf.org>
List-Post: <mailto:mpowr@ietf.org>
List-Help: <mailto:mpowr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,DATE_IN_PAST_06_12, PRIORITY_NO_NAME autolearn=no version=2.60
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
John, JCK> One problem I have with your suggestion -- I think the major one JCK> -- is that it would actually reduce our ability to say "no, go JCK> away, this doesn't belong here" in a prompt and efficient way. It does not do that at all. I think, perhaps, you've taken my suggestion as meaning that performing the steps I described would be "sufficient" for gaining working group status. My suggestion is not meant to remove any other criteria that we already have. And let me again stress that my suggestion is nothing but codifying existing practise, in or to have it be applied consistently, as Bert has essentially pointed out. JCK> As Pete points out, it would save surprisingly little in terms JCK> of the other things we do. I'm frankly surprised that the difference in management and administrative overhead seems such a small thing to you. JCK> Can that be fixed by "changing the context"? Not, I think, in JCK> the way you suggest. If we stop the circumlocutions, I think JCK> you are saying "the IESG doesn't have what it takes to shut down JCK> WGs that are not being productive". The problem is bigger and deeper than that. Working group creation is a particular moment of incentives and leverage. After chartering, the only real leverage is changing chairs or disbanding the working group. First of all, those are big hammers. Absent smaller ones then we should do as much as we can to make sure the big hammer is not needed. More stringent "entrance requirements" is a pretty obvious way to make sure we are getting better "students" of the IETF process. As for the IESG track record, you are kidding, right? Do we have a solid pattern of wasteful, thrashing working groups that drag on, being disbanded? I could have sworn we did not. That leaves the IESG question to one of "they will do better". And that leads to the questions "why, how and when"? Your suggestion requires no procedural changes. So the IESG could have started taking this more stringent position anytime. Yet they haven't. JCK> I think that is a problem, JCK> a big one. But, if you believe that can't be changed, then why JCK> is it reasonable to believe that they won't permit WGs to be JCK> created with half-baked evidence of viability and then permit JCK> _those_ to go on forever? I'd rather see us Your question is particularly important given that any reasonable evaluation of the IETF's track record would say that, indeed, that is exactly what has been happening. The idea is to change the IETF culture about the requirement, so that it is a community thing, rather than an IESG thing. The idea is to have the high bar for entrance be a shared value, with complete transparency. JCK> this suggests we ought to be spending more time on JCK> technical work, and monitoring of technical work, than JCK> on charter nit-picking (regardless of what does, or does JCK> not, precede chartering). If a group cannot formulate a clear, focused problem statement and a clear, focused, practical statement of the solution path, then concern over the charter is not nit-picking. It means that the group really has no idea what it is going to do. This being an engineering group rather than a research group or coffee klatsch, it is rather serious for them to lack a shared sense of the problem and how to approach solving it. JCK> * Make sure the IESG understands that they will have JCK> strong community backing for killing off WGs that don't JCK> appear to be functional and/or worth the resources they JCK> consume. So, rather than put the affirmative burden on the group supposed to do the work you want to increase the responsibility on the IESG to perform a negative action. This seems like a very bad process design. JCK> My strong impression is that, in the past, the JCK> perceived lack of that backing has been an important JCK> contributor to the problem of letting these groups My strong impression is that that your strong impression is crap. First of all, working groups thrash for a reason. Threats are rarely successful against that reason. So the "simple" step of somehow giving ADs more resolve entirely ignores the core problem. Feel free to cite a pattern that shows otherwise. Second of all, my strong impression is that ADs who are diligent and forceful about shutting down wayward working groups do just fine. Third of all, the model of expecting people who are not senior management in their day job to display the kind of management understanding and skill this requires is just plain inappropriate. And lastly, relying on ADs to do post-hoc quality control is entirely the wrong model. Note the constant return to the question of "trusting" ADs. The IETF's problems are not really about ADs. They are about working groups doing their work. So if we are going to make changes, let us try to make sure that they change how working groups work. Once again: You are seeking to change a possible community failure to give proper support for ADs who might otherwise get the resolve to shut down bad working groups. I hope both the fuzziness and indirectness of your model is clear in that description. By contrast, I am merely suggesting that we require a group that is going to consume IETF resources demonstrate that it has the skills necessary to do the job it is contracting for. JCK> drift: often, when one is shut down, the people who JCK> still care about its work raise a mighty outcry, while JCK> the rest of the community ignores the situation. Of course they raise a mighty cry. That does not mean anything. Have we suddenly become afraid of noise? What means something is an appeal and a reversal. Do we have a track record of shutdowns being reversed? Do we have a track record of groups that are shut down later doing well (presumably elsewhere)? JCK> That JCK> makes it, for most ADs, a lot easier to let a moribund JCK> group drag on Now you are at the heart of the matter: Shutting down a group is a painful act. That's why we need to make it a true last-resort. What you want to do is to make it a primary management tool. JCK> -- at least to the point that its JCK> ineffectualness is painfully obvious to everyone I might have thought that, too, but then we get groups like IMPP that went through 4 years, 3(!) sets of working group chair, and still did not have its act together. JCK> The procedural change we may have a place for in this is a WG JCK> with a specified sunset time. E.g., a "Here is a charter, you JCK> are now subject to all of the normal WG rules, but you have X JCK> months to demonstrate that you are worth the trouble. If you JCK> can demonstrate within that period that you are functional, we JCK> can negotiate a new charter. Given our limited resources, why in the world would this sort of "say yes easily and then try to figure things out later" model work? Where can we look for an example that shows a pattern of success with such a model? d/ -- Dave Crocker <dcrocker-at-brandenburg-dot-com> Brandenburg InternetWorking <www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253> _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr
- Re: [mpowr] Why MPOWR? John C Klensin
- Re: [mpowr] Why MPOWR? Melinda Shore
- [mpowr] Why MPOWR? Bernard Aboba
- Re: [mpowr] Why MPOWR? Joel M. Halpern
- Re: [mpowr] Why MPOWR? Pekka Savola
- Re: [mpowr] Why MPOWR? Spencer Dawkins
- Re: [mpowr] Why MPOWR? John C Klensin
- [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation Pete Resnick
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation Pete Resnick
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin