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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 01 December 2012 23:04 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 7F70821E80B7 for <ietf@ietfa.amsl.com>; Sat, 1 Dec 2012 15:04:58 -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 lXxoIi23iMNc for <ietf@ietfa.amsl.com>; Sat, 1 Dec 2012 15:04:57 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 763F311E8099 for <ietf@ietf.org>; Sat, 1 Dec 2012 15:04:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7E785BE58; Sat, 1 Dec 2012 23:04:35 +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 j4EjQM1SJWry; Sat, 1 Dec 2012 23:04:34 +0000 (GMT)
Received: from [10.87.48.10] (unknown [86.42.22.137]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EE29DBE53; Sat, 1 Dec 2012 23:04:33 +0000 (GMT)
Message-ID: <50BA8D01.1050508@cs.tcd.ie>
Date: Sat, 01 Dec 2012 23:04:33 +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: Barry Leiba <barryleiba@computer.org>
Subject: Re: Idea for a process experiment to reward running code...
References: <50BA64AB.3010106@cs.tcd.ie> <CAC4RtVD0x3JsPR8qJ1BbVytU-yL96z-Sbr5hW9GetnEX-U3FQQ@mail.gmail.com>
In-Reply-To: <CAC4RtVD0x3JsPR8qJ1BbVytU-yL96z-Sbr5hW9GetnEX-U3FQQ@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: IETF-Discussion <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 23:04:58 -0000

On 12/01/2012 10:22 PM, Barry Leiba wrote:
>> [1] http://tools.ietf.org/id/draft-farrell-ft
> 
> I have a serious problem with the premise of the proposal.
> 
> The short version is that if the process we're talking about is
> useful, we should not shortcut it as a "reward" for anything.  

I disagree. The process is neither useful nor just a PITA. Its both,
depending on what document and point of view you pick. So yours is
a false dichotomy I think. And even the process now were useful 100%
of the time, shortcutting it might still be an improvement. So I just
don't think you have a winning argument based on logic.

> And if
> it's not useful, we should not be doing it, regardless of whether we
> want to provide incentives or not.
> 
> In particular:
> 
>    1.  Working group last call (WGLC), IETF last call (IETF-LC) and Area
>        Director (AD) review all run in parallel over the same two-week
>        period.
> 
> Note that WGLC is not a part of our formal process, 

Whatever. Its a reality.

> and that AD
> Evaluation can take as little time as it takes for the responsible AD
> to click the "Go directly to Last Call Requested" button in the
> datatracker.  

Or longer. Much longer sometimes if an AD is slow or
authors need to re-spin and are slow. Both happen.

I had meant to try measure that from Jari's data before shooting
the draft out but didn't get a chance. My bet is that if this
worked well, it might save about 6 weeks on average, for drafts
where its suitable. Or maybe more. We should see if we can get
some numbers though, I do agree with that.

But more blow-by-blow responses will only likely rathole us
here so I'll stop here for now. (But I'm happy to do send that
if you think its useful.)

What's wrong with doing the experiment and finding out if its
better, worse or not detectably different?

I, and I believe lots of us, do want to encourage running code
more than now. This is one attempt to help with that. Why not
try it and see?

S.

> Therefore, making this step happen today is entirely up
> to the working group chairs and the responsible AD.  Any chair who
> thinks that a document has had enough review in the WG already can
> send the document to the AD directly.  That chair can also ask the AD
> to expedite her review and get Last Call started ASAP, and it's up to
> the AD to decide whether that's appropriate.  We don't need a process
> experiment for that.
> 
> That said, AD Evaluation often (VERY often) turns up things that would
> otherwise come up in Last Call comments, including in directorate and
> review team reviews.  It often corrects problems or gaps in the
> protocol specification, issues with IANA requests, security issues,
> and so on... which would take up a lot of other people's time as the
> Last Call review goes on.  An AD who has been following the document
> already might be happy going directly to Last Call Requested with just
> a quick glance at the document (as I have with some documents), but
> might have extensive comments about other documents, regardless of
> whether there are implementations or not.
> 
> Kicking off Last Call is something that requires AD judgment, not some
> sort of "reward" system.
> 
>    2.  Only comments that would be "DISCUSS-worthy" according to the
>        IESG Discuss Criteria [DCRIT] need be handled during last call.
>        Other comments can be handled or not, at the authors/editors
>        discretion.
> 
> I'm puzzled by this.  First, a lot of things fall under the DISCUSS
> criteria, but ADs decide not to give them DISCUSS status, depending
> upon the situation.  I guess in item 3 you cover who decides this, but
> as it's specified here it seems entirely too fluffy.  And it appears
> to devalue the non-blocking comments more than they already are.
> Again, if our process of making comments *of all sorts* has value,
> then we shouldn't short-cut it.  It's already the case that the
> responsible AD and the IESG as a whole get to decide which Last Call
> comments "need to be handled" and which don't, so this really isn't a
> process change either.  But I wouldn't want to say outright that
> last-call comments that don't meet DISCUSS criterial will likely be
> ignored in some "fast path" process that "rewards" a protocol for
> having implementations.
> 
>    3.  After fast-track last-call, the document must either be returned
>        to the WG, or else enter IESG review as soon as any changes
>        required are made.  The relevant AD makes the decision as to
>        whether changes are required and when those are completed
>        sufficiently to move to the next stage.
> 
> This is no different to what we normally do: after Last Call ends, the
> document goes into "Waiting for AD Go-Ahead" state, and the
> responsible AD decides whether it's ready for IESG Evaluation or not.
> 
> I very strongly dislike the idea of saying that we'll "reward"
> something by trimming (by a mere two or three weeks; what real value
> does that have?) a process that we consider as adding value to our
> documents.  And, again, if we think it doesn't add value, then let's
> just do this as standard procedure, as we already can today, with no
> process experiment at all.
> 
> Just tell all your WGCs that they can skip WGLC, and you'll send their
> docs straight into Last Call as soon as you get them.
> 
> Barry
>