Re: [css3-color] #rrggbbaa annotation, do we need to change the process?

On 4/7/10 6:10 AM, Mikko Rantalainen wrote:
> During every release cycle new features can be specified and changed
> (features can be added, removed and modified without restrictions)
> during the time before the freeze. During the freeze, only
> changes/tweaks required to specify details for interoperability /
> practical implementation are allowed.

That doesn't seem like it sufficiently allows the sort of wide community 
feedback the W3C supposedly encourages.

As far as I can tell, the idea of the current W3C process is that you 
have the following stages:

1)  Free-for-all stage as you describe.
2)  Last Call: feature freeze; request for reviews of the document.
3)  Candidate Recommendation: call for implementations
4)  PR/REC (equivalent from our pov, since this is mostly a matter of
     W3C Advisory committee stamping it).

It sounds like you're suggesting dropping last call altogether.  In 
particular, it sounds like you're suggesting that the gap between some 
feature being proposed and the call for implementations happening be 
dropped to 0.  That does not allow sufficient time for people to comment 
about badly conceived features.

With smaller specs, that last call period (which basically needs to 
allow enough time to read and understand the spec) can probably be 
shorter than they've typically been for recent mega-specs.

> Browser vendors are encouraged to
> implement features immediately after the start of the freeze so that
> possible corner cases can be defined and implemented during the freeze.

Browser vendors have finite resources and priorities which might not 
match yours or the working groups.  You can encourage, but that's no 
guarantee of it happening.

> Perhaps even define that all changes to specification during the freeze
> must be come from actual implementers of spec.

Given you lack of a review period, this effectively allows implemeters 
to implement whatever they want: just propose it the day before feature 
freeze, and then no one else can suggest changes to it.

> At the end of release cycle, all features of the spec that have at least two interoperable
> implementations will be marked with "Recommended" status and all the
> other features fall back to next release cycle.

The bit you seem to be missing is that the big gating factors on speed 
of spec development are:

1)  Lack of editor time to create the original text.
2)  Lack of implementor time to implement all the things that people
     care to think up all at once.
3)  Lack of people writing testcases for the test suite (CSS2.1 test
     suite coverage is ... rather poor in many areas, even with the
     large numbers of tests that implementors and a few others have
     contributed).

Are you volunteering for some or all of these?

> This would make it less fatal to miss a release of the spec (because the
> next release date would be already known and not too distant future) and
> at least some progress would get Recommended every release date (hopefully).

Maybe, maybe not.  If your release cycle is shorter than UA release 
cycles, then you may well not end up with interoperable implementations.

> The CSS specification has already been split in modules and each module
> could have a different release cycle if needed.

They already have different release cycles.  Some are in CR, some are in 
early WD.

-Boris

Received on Wednesday, 7 April 2010 12:33:20 UTC