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

"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.

"If implementations are what's needed for further progress,
it goes to CR. That is what CR is for."
No, that is not what CR is for. We should not move to CR to 'make further progress' on something that still hasn't been implemented (as if calling something CR created 'further progress'). If there is no implementation experience for it a feature has no business going to CR; either it won't get anymore implementation experience and will be removed, or it will get some and the resulting will take the spec back to WD. This is not an approach to reach a stable spec; it's a method to stay in CR forever. (Which, admittedly, the WG has historically been good at).

"The key point is that the switch to CR is not dependent on
whether there are implementations. " No wonder the WG has produced so many CRs that never went anywhere. The "key point" here is that any standardization approach that does not depend on any implementation in order to reach the final stage in the process - the one where testcases and implementation reports are created - is broken and in dire need of fixing. If the standard track does not reflect any kind of concrete implementation progress then it is effectively meaningless.
________________________________________
From: www-style-request@w3.org [www-style-request@w3.org] on behalf of fantasai [fantasai.lists@inkedblade.net]
Sent: Thursday, August 18, 2011 1:36 PM
To: Brian Manthos
Cc: www-style@w3.org
Subject: Re: [CSSWG] Minutes and Resolutions Telecon 201-08-17

On 08/18/2011 01:14 PM, Brian Manthos wrote:
> Unfortunately I find this more confusing rather than less confusing.
>
> To simplify...
>
> Assume:
> A. We have a module at WD.
> B. Some of the module is ready to be unprefixed.
> C. The rest of the module is not ready to be unprefixed.
>
> How do you get to...
>     1. The feature is in CR.
> ... for the features in B, while respecting the C constraint.

1. Strip the module of all features that are known unstable;
    push them to the next level or whatever.
2. Take all the features that are considered stable (or stable
    awaiting implementation feedback) to CR.

The key point is that the switch to CR is not dependent on
whether there are implementations. It's whether we're stuck
on waiting for implementations to making further progress.
If implementations are what's needed for further progress,
it goes to CR. That is what CR is for.

~fantasai

Received on Friday, 19 August 2011 06:48:00 UTC