W3C home > Mailing lists > Public > public-w3process@w3.org > December 2013

Re: Purpose (and Naming) of LCCR

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 02 Dec 2013 07:20:38 -0800
Message-ID: <529CA546.5080209@inkedblade.net>
To: public-w3process@w3.org
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. 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.

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

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

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.

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

~fantasai
Received on Monday, 2 December 2013 15:21:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:09 UTC