Re: Trimming the Rec Track Process?

(Comments without having seen it.)

There are a set of needs satisfied one way or the other by these stages.

1. add to licensing obligations to those first generated at FPWD. So 
need this after last change that could increase essential claims.  
(defined in patent policy as Last Call so stuck with something that 
implements last call exclusion period)
2. need a stable reference other orgs feel comfortable pointing to in 
their specs.  If we're in a situation where Recommendation takes an 
eternity because we're waiting for test code and implementations, it 
can't be REC.  So maybe not implemented or tested, but high level of 
confidence.
3. need AC to approve something considered as some sort of W3C spec (and 
the W3C Director/Staff to weigh in too)
4. need a rock solid, it's been implemented and tested final spec (for 
those who need to know what has been thoroughly tested in multiple 
implementations)

Sure, Last Call doesn't need to be an independent stage.  It just needs 
to happen before the AC approval (so they know what they're approving).

I'm not sure how Candidate Rec can serve as that sort of stable spec it 
it happens before the Last Call exclusion period or before the AC review.

So I'd suggest:

Stages:

Candidate Rec - experimental spec status (need last call after last 
substantive change, need AC approval, doesn't have multiple 
implementations or testing)

Recommendation - final, tested spec status (W3C staff determines, if any 
controversy, needs AC approval)

Reviews:

"FPWD" and "Last Call" patent exclusion periods  - Last Call can repeat 
- must happen after last substantive change and before Candidate Rec
"AC Review" - after last Call and before Candidate Rec.  If any issues 
after Candidate Rec meets all criteria to advance to Rec, another AC 
review if AC asks for it.

Can do FPWD -> Last Call -> AC Review -> REC  (skipping Candidate Rec if 
met all the criteria).




On 5/21/2013 6:26 AM, Arthur Barstow wrote:
> On 5/12/13 11:34 PM, ext Charles McCathie Nevile wrote:
>> Hi,
>>
>> I have been working on an idea about the Rec Track Process. I'm not 
>> the only one.
>>
>> Roughly, I think it makes sense to collapse Candidate Recommendation 
>> and Last Call together. Having put this idea about, and listened to 
>> some responses and ideas about it I am becoming more convinced, so I 
>> sat down to rewrite the chapter in the Process that describes Rec 
>> Track as an exercise in seeing how this would pan out.
>>
>> It seems to work out OK. Basically to get into last call you need to 
>> have done your job in the working group, and should have done a 
>> reasonable amount of coordination with the people most likely to care.
>>
>> I clarify that the requirement for CR isn't "two implementations", it 
>> is "this spec will lead to independent implementations being highly 
>> interoperable". Two or more implementations has been used as if it 
>> were a proof by induction - the first people got the spec right, the 
>> next people got the spec right and work with the first lot, so the 
>> rest will too. But this is a pretty hand-wavy approach, which at the 
>> same time can be used to impose massive formalism on stuff that 
>> doesn't need it. (There are probably ways to make test cases for the 
>> p element that show it doesn't work entirely interoperably. That 
>> should be fixed, but the idea that we should rescind the element 
>> until it is fixed is just a bit ludicrous).
>>
>> As a sideline, I kind of "trimmed" Proposed Recommendation a bit - it 
>> isn't so much a status as a waypoint. The assumption is that Proposed 
>> Recommendations become Recommendations, but there are examples of 
>> that not happening, and for the ones I know I think with good reason. 
>> So there is still a chance for the AC to say "no, stop, wait!!!", 
>> just in case.
>>
>> And I re-cast the chapter so it focuses on who must/may/should not… 
>> do what.
>>
>> In all of that, one nice side effect is getting the size of the 
>> chapter down by about 50%.
>>
>> I haven't finished, but I am interested to hear people's thoughts on 
>> the idea.
>>
>> I've tossed an early draft of this to the AB, so they can consider it 
>> in time to present it to the W3C members at the June AC meeting if 
>> they choose to do so. Some time in the next couple of days I expect 
>> to have a bit cleaner document that I don't mind being found in 
>> archives, with clear disclaimers to reduce excuses for confusion, 
>> plus fewer dodgy links, and making sure I don't breach a license 
>> somewhere. At that point I'll happily make it generally available...
>>
>> If you want to see where I am up to in the meantime I'll happily 
>> email you a copy.
>
> I'd like to see what you have.
>
> -Thanks, AB
>
>
>
>
>

Received on Tuesday, 21 May 2013 19:07:18 UTC