Re: Purpose (and Naming) of LCCR

On 11/28/2013 07:15 AM, Jeff Jaffe wrote:
> fantasai wrote:
>> Based on the new Process proposal, I would expect spec work to follow
>> the following steps:
>>
>>   1. Cycle through WD for a long time as feedback and implementation
>>      and testing and usability experience is gathered. (Since CR
>>      doesn't signal anything except "we're going to REC in 4 weeks",
>>      and carries a lot of extra overhead for making substantive edits
>>      there is no justification at all to move the spec out of WD.)
>>
>>   2. Once you have proof of implementability and all the other
>>      criteria for REC are satisfied other than the last 4 weeks of
>>      review, and you publish LCCR to give people that last chance
>>      to stop the presses.
>
> This seems different from what is anticipated in the current proposed Chapter 7.

It is, however, the most efficient workflow I can come up with
and seems to match best what is intended *as written in the
proposal*, without consideration of any statements made by the
AB outside the text of the proposal.

Perhaps your interpretation of the new proposal is clouded by what
you know of the old Process and the discussions in the AB. There
is very little in the new Process that leads me to believe that a
spec should enter LCCR for any reason other than "we're going to
REC in 4 weeks". And plenty enough statements to imply that if your
LCCR period isn't approximately 4 weeks and doesn't end in REC,
you're doing something wrong.

> You don't need to have proof of implementability to enter LCCR.

Sure. But if the goal is that LCCR lasts only 4 weeks and ends in
REC, I as a responsible editor wanting to follow the Process in
letter and spirit as efficiently as I can, will not request LCCR
until I've got all of my REC-entry requirements in order. Because
proof of implementability takes a *lot* longer than 4 weeks to put
together. The 4 weeks is just enough for everyone to check that
everything's in order, not enough to write a test suite or an
implementation for any non-trivial technology. And if I'm still
proving implementability, I'm still at significant risk of needing
to take substantive changes.

The workflow I outline is based on the following conclusions:
   * By contrast with the old CR, the new LCCR is not intended to
     signal anything wrt implementation readiness.
   * A spec should only be in LCCR for something like 4 weeks.
   * LCCR transitioning back into LCCR (and thus any substantive
     change to an LCCR) is not expected. Only LCCRs transitioning
     to RECs are expected.
which are drawn directly from the text, as described in my post.

If you have a dispute with the workflow I outlined either

   A. Dispute the connection between my conclusions and my workflow
      by showing an alternative workflow that is more consistent with
      the Process proposal including the conclusions outlined above,
      and explain how it is more consistent.

   B. Dispute the conclusions I drew from the text by showing how
      they are wrong, using direct quotes from the Process proposal.

   C. Dispute that the Process proposal matches your expectations
      by outlining your desired workflow and informing the AB that
      the new Process proposal does not encourage it.

C. would be, presumably, hitting this "if" clause:
> (If, on the other hand, it's not actually what the AB intended,
> then its new Process draft is all wrong.)

~fantasai

Received on Thursday, 28 November 2013 18:03:55 UTC