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

Dave Crocker <dhc@dcrocker.net> Sat, 01 December 2012 22:13 UTC

Return-Path: <dhc@dcrocker.net>
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 EAE9E21F8B5D for <ietf@ietfa.amsl.com>; Sat, 1 Dec 2012 14:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Z2chNJ4OE-Ih for <ietf@ietfa.amsl.com>; Sat, 1 Dec 2012 14:13:35 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 73CDA21F8B5C for <ietf@ietf.org>; Sat, 1 Dec 2012 14:13:35 -0800 (PST)
Received: from [192.168.1.9] (adsl-67-127-190-125.dsl.pltn13.pacbell.net [67.127.190.125]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id qB1MDYBc019500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Dec 2012 14:13:34 -0800
Message-ID: <50BA8106.6050503@dcrocker.net>
Date: Sat, 01 Dec 2012 14:13:26 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Melinda Shore <melinda.shore@gmail.com>
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>
In-Reply-To: <50BA6FF4.4030706@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 01 Dec 2012 14:13:34 -0800 (PST)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
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:13:36 -0000

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 -- 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.


> 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/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net