RE: [CSSWG] Minutes and Resolutions Telecon 201-08-17

[fantasai:]
> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of fantasai
> Sent: Friday, August 19, 2011 11:58 AM
> To: www-style@w3.org
> Subject: Re: [CSSWG] Minutes and Resolutions Telecon 201-08-17
> 
> On 08/18/2011 11:47 PM, Sylvain Galineau wrote:
> > "Strip the module of all features that are known unstable;
> >      push them to the next level or whatever"
> > Which is what we did in Seattle and are now reversing for no good
> reason.
> 
> We're not reversing it, we're adjusting the dividing line given new
> feedback from others, in this case the i18nWG.
That the reversal is motivated by specific feedback does not change the
fact that we have reversed a prior decision.
> 
> > If there is no implementation experience for it a feature has no
> > business going to CR;
> 
> That is not how the W3C process is set up. Implementations are explicitly
> *not required* for entrance to CR.

True. But implementation is required to exit CR. "Foot, meet shot".
> 
> 
> CR is not the final stage in the process, REC is. The intention of CR is
> to allow time for implementations and to reflect the feedback of that
> experience into the spec.
 
Since reflecting the feedback from implementation into the spec takes the 
spec back to WD it seems a singularly contradictory goal for a step that 
also aims to exit towards REC. I would maximize the odds of exiting CR
successfully and on time by entering it *once* based on actual implementation
experience already factored into the spec. As opposed to a mix of very real
and entirely theoretical features. (Crazy talk, I guess)

> The intention of the at-risk list is to allow
> the CR to drop features that do not garner implementations so that the
> rest of the spec can make progress.

But I thought CR was a call to implementation ? Do the words 'at risk' 
typically motivate implementors to commit their resources to a feature ?

I think we've established that the combination of the W3C definition for
CR and our own exit criteria make a CR spec whatever the editor wants it 
to be. Whether that is desirable or is of benefit to implementors, authors
or the WG is certainly up for debate.

Received on Friday, 19 August 2011 19:25:00 UTC