Re: Trimming the Rec Track Process?

On Mon, 13 May 2013 08:34:29 +0500, Charles McCathie Nevile  
<chaals@yandex-team.ru> wrote:

> Hi,
>
> I have been working on an idea about the Rec Track Process. I'm not the  
> only one.

And now I have a document, published with permission.  
http://yadi.sk/d/Zikwkr385JG8f (You'll want the button called "Скачать" to  
download it).

(I didn't upload this as a draft report, because it isn't clear that it is  
one, and in any event I only have permission to publish what I have, not a  
derivative. If people think this should become a "draft report" I am happy  
to make it one).

It attempts to identify new things and things that have changed, but does  
not show what got removed (which is a lot). And there are probably issues  
that are not properly identified, and almost certainly dodgy links and bad  
markup.

All comments welcome, as normal contributions to this CG. At some point if  
people think this is worthwhile I will edit another version and ask for  
permission to publish that too...

cheers

Chaals

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


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

Received on Wednesday, 29 May 2013 20:05:15 UTC