Re: Purpose (and Naming) of LCCR

On 12/2/2013 10:20 AM, fantasai wrote:
> On 11/28/2013 06:45 PM, Jeff Jaffe wrote:
>> fantasai wrote:
>>> 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.
>> This might work for you and might work for many groups.  But if a
>> group does not want to go through implementation experience and
>> interoperability testing until the Director has signed off that
>> the spec has achieved wide review and met the requirements it might
>> not work.
> I'm not saying whether it works for me or other groups. I'm saying
> that this is the workflow the new Process is designed to support,
> and any other workflow would be working around the letter and
> ignoring the spirit of the new Process.

I am disputing that this is the only workflow that the new Process is 
designed to support.

> Which, if I may point out
> again, is *very clear* that a document which spends more than the
> comment period (of approximately 4 weeks) in LCCR or which does
> not then move forward to REC, is not following the Process as
> intended.

I don't see where this is very clear.

>> For a close community (like CSS) the community might feel that they
>> can iterate at WD level, and only enter LCCR when they are 4 weeks
>> from REC.  For a diverse community (like tracking protection) the
>> community might want to reach LCCR before they take the additional
>> steps.
> Tracking Protection is special because of all the politics.
> It is the only case I know of in which getting the Director's
> sign-off might mean something special to the implementation
> community.
>>> 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.
>> I'm not sure where that conclusion comes from.  Certainly some groups
>> will decide on implementation readiness prior to LCCR.
>> But others may not.
> My point exactly. LCCR does not itself indicate anything about
> implementation-readiness of the spec. The CR phase did, which
> gave us a reason to want a spec to be marked as CR other than
> "it's a step we have to go through to get to REC". But LCCR
> does not, which gives us no reason to transition into it
> except as the transition to REC.

Well I previously pointed out that there are activities that the new 
process projects happening after LCCR.  And I accept your assertion that 
the process allows them to be done prior to LCCR.  Some groups should do so.

>>>   * 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.
>> I don't know how you reached your first two conclusions.
>> I don't see where they are supported in the current text.
> The first conclusion is due to lack of any evidence for the
> either of the following statements:
>   * LCCR is intended to signal implementation readiness.
>   * LCCR is intended to signal implementation unreadiness.
> Since neither statement is supported by the text, we must conclude
>   * LCCR is not intended to signal implementation readiness or
>     unreadiness.

The fact that at LCCR you need to show the plan for implementation 
experience and at REC you need to show implementation experience is the 
new process's way of saying that LCCR is intended to signal 
implementation readiness.  It is not so explicit because *by design* we 
are trying to be less prescriptive to give people the flexibility to do 
things at different times.  So if you want to do implementations prior 
to LCCR, the process supports that (and a 4 week to REC time frame).  
But saying that the new process tolerates earlier implementation does 
not mean that the new process insists on earlier implementation (or even 
encourages earlier implementations).

> The second conclusion is from the following text:
>   # must specify the deadline for comments, which must be at least
>   # four weeks after publication, and should be longer for complex
>   # documents,
> This specifies a "deadline for comments". A "deadline for comments"
> means "we need your comments by this date in order to process them",
> not "we will make sure we leave at least this much time for comments".
> If the spec is in LCCR beyond the deadline for comments then it is
> in this weird state where all the comments that are guaranteed to
> be processed before REC must already be in, but the spec is still
> waiting for something.

Yes, the waiting could be for the implemenation experience of the 
interop testing.

> So of course any reasonable working group will continue to process
> comments that come in. Which makes the "deadline for comments" not
> much of a "deadline". To make the "deadline for comments" actually
> function as a deadline, the group needs to keep the LCCR period to
> approximately the same length as the comment period, hence, in the
> case of CSS and any other specs with a similar LC period, 4-6 weeks.

But the comment period is encouraged to be longer for complex 
documents.  It may be 4-6 weeks for CSS Modules, but not universally.

>> I'm not sure if C hits the "if" clause. I'm not saying that your
>> process workflow is inconsistent with the new proposed process.
>> It could be consistent and correct for some groups.  I'm only>
>> saying that your process workflow is not the only workflow that is
>> consistent with the new proposed process.
> Show me an alternate workflow that is consistent with the new proposed
> process.

Get to LCCR and use the period between LCCR and REC to demonstrate 
implementation experience and interop testing.

> ~fantasai

Received on Monday, 2 December 2013 16:48:55 UTC