Re: Purpose (and Naming) of LCCR

On Mon, 02 Dec 2013 16:20:38 +0100, fantasai  
<fantasai.lists@inkedblade.net> wrote:

> On 11/28/2013 06:45 PM, Jeff Jaffe wrote:
>> fantasai wrote:
[...]
> 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. 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 think so. The *minimum* period to spend is 4 weeks, and complex  
documents *should* spend longer. There is no maximum period, intentionally.

The spirit is to *optimise* for a workflow like you describe, without  
making the process *force* that approach.

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

There are a number of other specs that this applies to - and they aren't  
necessarily obviously political.

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

It is the last phase you can get to before you MUST demonstrate  
implementation-readiness. Some groups will choose to use that as a signal  
to start getting implementations finalised, others will use it as a signal  
that they think implementation is finalised.

The process doesn't force that decision, it leaves it open.

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

It's waiting for the comments to be processed. A spec that is moving fast  
will spend a day or so in this state. A spec that gets a lot of comments,  
or where the group is slow, or where there is a complex comment, might  
spend far longer.

> So of course any reasonable working group will continue to process
> comments that come in.

This depends on the comments, and in some cases I certainly hope the group  
does not do that, but instead finishes the spec and holds the comments  
over for version 2.

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

No it doesn't. The group determines how it handles deadlines. If a really  
important comment comes, then a group probably should deal with it  
whenever it arrives, but unless the group sets a deadline it can too  
easily be spun around by endless comments that could easily be deferred to  
version next...

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

Group writes a spec, makes a FPWD, gets some issues, resolves them in  
batches publishing three more WDs over 12 months, and when there are no  
more, it goes to CR. It sets an 8 week deadline for comments in CR, during  
which it gets 14 further comments of which 8 are proposed extra tests.  
Over the next 8 weeks it addresses one comment per week, all resulting in  
no actual change, and accepting 7 of the 8 tests while rejecting the other  
as invalid. It gets a comment 12 weeks after it publishes, which suggests  
changing a method name. The group decides not to address the comment in  
any formal way. Then it requests publication as a Rec. The AC review  
continues for 4 weeks, and everyone is happy. The document gets published.

I'm not sure this represents best practice but it is perfectly consistent  
with the requirements of the process.

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Monday, 2 December 2013 15:56:26 UTC