Re: Trimming the Rec Track Process?

Getting the size of (any of) the chapter seems a pretty good idea.
Any approach that might helpful to dismiss bottlenecks might be useful . At least, communication s we know, is not one-sided.
Please if you are so kind to send me a copy of your draft, this is where are you now, Ill be glad to.
BR

Delfi Ramirez
skype:segonquart
IRC: segonquart
twitter:delfinramirez
tel + 34 616537635
delfin@delfiramirez.info
es.linkedin.com/in/delfiramirez/


On 13/05/2013, at 05:34, 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.
> 
> cheers
> 
> Chaals
> 
> -- 
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>      chaals@yandex-team.ru         Find more at http://yandex.com
> 
>