Re: Idea for a process experiment to reward running code...

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 01 December 2012 22:56 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FE021F872C for <ietf@ietfa.amsl.com>; Sat, 1 Dec 2012 14:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAPrwzAwGu8G for <ietf@ietfa.amsl.com>; Sat, 1 Dec 2012 14:56:26 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ED29C21F8702 for <ietf@ietf.org>; Sat, 1 Dec 2012 14:56:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 23B49BE4D; Sat, 1 Dec 2012 22:56:04 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DS8yW2Tohdv; Sat, 1 Dec 2012 22:56:03 +0000 (GMT)
Received: from [10.87.48.10] (unknown [86.42.22.137]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4AC3ABE49; Sat, 1 Dec 2012 22:56:03 +0000 (GMT)
Message-ID: <50BA8B03.7070002@cs.tcd.ie>
Date: Sat, 01 Dec 2012 22:56:03 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: dcrocker@bbiw.net
Subject: Re: Idea for a process experiment to reward running code...
References: <50BA64AB.3010106@cs.tcd.ie> <50BA6A45.2000409@dcrocker.net> <50BA6FF4.4030706@gmail.com> <50BA8106.6050503@dcrocker.net>
In-Reply-To: <50BA8106.6050503@dcrocker.net>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Dec 2012 22:56:26 -0000

Hi Dave,

On 12/01/2012 10:13 PM, Dave Crocker wrote:
> 
> On 12/1/2012 1:00 PM, Melinda Shore wrote:
>> On 12/1/12 11:36 AM, Dave Crocker wrote:
>>> What actual problem is this trying to solve?  I see the reference to a
>>> 'reward', but wasn't aware that there is a perceived problem needing
>>> incentive to solve.
>>
>> I gather this is one of those "everybody knows" problems, where
>> "everybody knows" that it takes what's perceived as too long to
>> get documents through the post-wglc/pre-publication process.
> 
> 
> Yes.  Longstanding opinion held by many folk.  Might even be valid.
> 
> The problem is a failure to look carefully at wg lifecycle and consider
> where meaningful -- as opposed to 'appealing' -- improvements can be made.
> 
> At a minimum, any proposal for change should be expected to justify the
> specific problem it is claiming to solve -- 

Disagree. RFC 3933 says:

"A statement of the problem expected to be resolved is
      desirable but not required..."

There's a reason for that IMO - all proposed process changes seem
to generate *lots* of comment that there's a better problem to
solve elsewhere.

> that is, to establish the
> context that makes clear the problem is real and serious -- and that the
> proposed solution is also likely to have meaningful benefit.
> 
> I share the frustration about lengthy standardization, and particularly
> with delays at the end.  And certainly there is nothing wrong with
> adding parallelism where it makes sense.
> 
> However absent a consideration of the lifecycle, the current proposal is
> a random point change, quite possibly an example of looking for lost
> keys under a lamppost because that's where it's easiest to see.

You may be right, I don't make any claim that this is going to
be super-good. OTOH maybe this is worth trying to see if we like
it or not.

Cheers,
S.

>> There's probably some sort of sympathetic vibe running between
>> this document and recent discussion of nearly-cooked work being
>> brought to the IETF for standardization.
> 
> rumblings of free-floating dis-ease, perhaps.  but are they really related?
> 
> 
>> If somebody hasn't already documented how long it takes to get
>> through the various steps once a document is into wglc, it
>> would be worthwhile to start taking notes.
> 
> If a wg takes 2 years to get into wglc, a difference of a month doesn't
> matter, does it?  That's why I mean about total lifecycle.  Otherwise
> we're committing the classic system engineering error of inappropriate
> local optimization.
> 
> d/