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

[Stephen Farrell <[e-mail]>]

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/