Re: [Pesci-discuss] For whom it may concern..

"Spencer Dawkins" <spencer@mcsr-labs.org> Thu, 10 November 2005 15:43 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEa4-0007GC-TN; Thu, 10 Nov 2005 10:43:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEa3-0007Fy-SN for pesci-discuss@megatron.ietf.org; Thu, 10 Nov 2005 10:43:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11273 for <pesci-discuss@ietf.org>; Thu, 10 Nov 2005 10:42:47 -0500 (EST)
Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaEqH-0005lT-TW for pesci-discuss@ietf.org; Thu, 10 Nov 2005 11:00:03 -0500
Received: from s73602 (pp104-231.bctel.ca[209.52.104.231]) by comcast.net (rwcrmhc11) with SMTP id <2005111015430401300hsg6oe>; Thu, 10 Nov 2005 15:43:04 +0000
Message-ID: <023a01c5e60d$5b7e89f0$e76834d1@china.huawei.com>
From: Spencer Dawkins <spencer@mcsr-labs.org>
To: pesci-discuss@ietf.org
References: <Pine.LNX.4.64.0511100249360.7319@netcore.fi><43729E65.30506@thinkingcat.com> <Pine.LNX.4.64.0511100757470.13106@netcore.fi>
Subject: Re: [Pesci-discuss] For whom it may concern..
Date: Thu, 10 Nov 2005 07:42:27 -0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
X-BeenThere: pesci-discuss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Process Evolution Study Committee of the IETF discussion <pesci-discuss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pesci-discuss>, <mailto:pesci-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pesci-discuss>
List-Post: <mailto:pesci-discuss@ietf.org>
List-Help: <mailto:pesci-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pesci-discuss>, <mailto:pesci-discuss-request@ietf.org?subject=subscribe>
Sender: pesci-discuss-bounces@ietf.org
Errors-To: pesci-discuss-bounces@ietf.org

> So, I see only two options which do not have to be mutually exclusive:
>
>  1) we institute a new process change process which allows distributing 
> the responsibility for getting the necessary changes proposed, discussed 
> and implemented (this is actually similar to how the IAOC effort took off 
> some responsibility from the IESG and IAB), or
>
>  2) we continue to hope that the current or future leadership will drive 
> through the required changes (in addition to keeping up with "day-to-day" 
> business).

Agree that these are two options, and not mutually exclusive.

One addition to 2), though.

When we have actually DONE something, it's usually been good. I'm thinking 
about the I-D Tracker, and the semi-related PROTO work, which has had more 
impact on the IETF than all the noodling about process change we've done 
since Yokohama.

I can't speak for anyone except myself, but  - I DO have cycles to try to 
help, and accept Leslie's point from PESCI, that random proposals don't 
help. I may not be the only one.

We talked about issuing a "call for proposals" yesterday. Please don't. 
You'll get more random proposals.

What would help me, and maybe others, try to help is a "call for proposals 
in a specific problem space".

Figuring out a way to tap cycles in the larger community is important. That 
was why Gen-ART was a good idea - the cycles to do more reviews were "out 
there", they just weren't being tapped effectively.

If you get a proposal that solves a specific problem/"pain point", that 
matters, we already have enough BCPs to actually DO something as a process 
experiment. Not saying that we don't need process evolution, just saying 
that we don't have to do process evolution before anything can get better.

Thanks,

Spencer

> Call me a skeptic, but 2) has not been so successful so far, despite 
> sporadic attempts (remember for example MPOWR and ICAR which were results 
> of an IESG retreat on the topic -- not too different than the one Brian 
> was mentioning).  It just doesn't seem to be possible to devote sufficient 
> energy to do these things, while keeping the "daily business" running.
>
> Hence, my main criticism of the current leadership is not that they have 
> not been able to make these changes: rather, it is that they have not been 
> able to realize that most likely they will never be able to make these 
> changes themselves, and are not able to realize that they must "step out 
> of the way" as soon as possible. 


_______________________________________________
Pesci-discuss mailing list
Pesci-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/pesci-discuss