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

On 08/19/2011 12:24 PM, Sylvain Galineau wrote:
>>
>> 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 fact that integrating implementation feedback into a CR is impossible
without going to WD is imho a serious brokenness in the W3C Process. :(
We have a PER phase for REC, but not a PECR for CR. This is the why we keep
bouncing mostly-stable specs to LC for minor fixups. :/

But I would rather work around that brokenness (and lobby W3C to fix their
process) than distort the meaning of the WD and CR phases, which I think
are fairly well thought out.

>> 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 ?

Right. But sometimes the call is not answered. :)

> Do the words 'at risk' typically motivate implementors to commit their
> resources to a feature ?

Depends on how valuable the implementors think the feature is. If it's very
valuable, they might consider making sure it gets implemented. If it's not,
then the presence of the feature on the at-risk list would indicate that
it's not worth bothering with for completeness, since there's a good chance
it'll be dropped.

If all the relevant implementers were active participants in the CSSWG,
then there wouldn't be a need to put things in CR before we could find
out whether they would get implementations: we could just ask our members.
But it so happens that there are implementers who are not in the CSSWG.
So we need to be open to their participation in the call for implementations.
The process provides for that participation via publishing a CR. And it
allows us to reduce the risk of having things hold us back by giving the
CR an at-risk list, which allows us to drop features if they don't get
implemented or if we find out, from the implementation experience, that
they really need to go back to a WD and get rehashed. So nobody's losing
anything here, afaict.

~fantasai

Received on Friday, 19 August 2011 20:12:29 UTC