Re: Purpose (and Naming) of LCCR

On Fri, 29 Nov 2013 12:45:33 +1000, Jeff Jaffe <jeff@w3.org> wrote:

>
> On 11/28/2013 1:03 PM, fantasai wrote:
>> 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.
>
> Well, imho, the fact that 7.4.2 only shows the plan for implementation  
> experience; while 7.4.3 shows the achievement of implementation  
> experience - and that testing requirements are met in 7.4.3 anchors my  
> view "as written in the proposal".  Not to say this is the right  
> ultimate process - but it is what is there.

As Jeff says later, an important design principle is not to constrain too
many people. Frankly, I agree with Fantasai that the "best" approach is to
get to "LCCR" with everything lined up and ready.

But the naming discussion is one I would rather avoid. Either Last Call,
Or Candidate Recommendation, would be great names IMHO - they provide
continuity of a sort, and mean about the same thing to people who aren't
bound up in W3C process.

Since I have the luxury of not chairing the AB task force who owns the
decision, I'll defer to the resolution of that task force until such time
as there is a new resolution. But to be honest, I don't think there is
much point arguing between Last Call and Candidate Recommendation. I do
think that not introducing Yet Another Name is helpful though.

cheers

chaals

>> 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.
>
> 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.
>
>>
>>> 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.
>
> I'm not sure where that conclusion comes from.  Certainly some groups  
> will decide on implementation readiness prior to LCCR.  But others may  
> not.
>
>> * 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
>
> I don't have a dispute, per se, I'm only reflecting what I think the  
> current document suggests.
>
>>
>>   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.
>
> I don't know how you reached your first two conclusions.  I don't see  
> where they are supported in the current text.
>
>>
>>   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.)
>
> 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.  The new proposed process is designed to give  
> more flexibility for different groups to traverse the path to REC in  
> different ways based on their needs.
>
>>
>> ~fantasai
>>
>
>


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

Received on Sunday, 1 December 2013 07:18:05 UTC