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

Boris Zbarsky wrote:
> 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.

Could you further describe (or provide examples) of cases where you
believe that the changes I suggested would cause problems?

I understand that the time window for feedback would be much shorter but
 I fail to see actual problems caused by this change. It's not like I'm
proposing no time for feedback but instead only a couple months instead
of years (in practice).

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

Implementors are already independently selecting which features they
will even try to implement. A spec that describes some nice to have
feature that is not implemented anywhere does not matter. I think that
if a feature is badly conceived, either the implementors will notice
that even before trying to implement the said feature or they will try
to implement the feature and hit the problem during the implementation.
In the latter case, it would probably be the case regardless of longer
Last Call phase.

I honestly believe that Last Call could be dropped altogether. Just keep
the requirement that there must be at least two independent
interoperable implementations before a feature can reach Recommended status.

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

I agree with that. As a result, a feature that browser vendors do not
deem important enough will not get Recommended status even though it
were included in the spec before the freeze.

Notice that I'm suggesting that the actual parts that hit Recommended
status will be decided *only* by ready implementations. The suggested
specification could reach Recommended state only partially (for example,
the Recommended Colors CSS spec could include only #rgba variant if
#rrggbbaa has not been implemented by two implementors - even if it
really did not make sense logically). I think that this is reasonable
close to the difference between CSS 2.0 and 2.1 - the 2.0 should have
never been a Recommendation because there were no compatible
implementations.

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

They can already do that today. However, such tricks cannot be used to
achieve the Recommended status unless another independent implementor
decides to also implement that feature. If that happens, I believe that
the feature is good enough (and specified with enough detail) to be
Recommended. If a single vendor is the only implementor, then the
feature will fall back to next release cycle after the release date. If
the time between two releases is short, this shouldn't be a problem.

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

I agree that this is a problem. For example, the HTML5 wouldn't be in
the shape it's today if Ian Hickson weren't the editor. The editor makes
all the difference and the editor must have enough time to do his work.
Hopefully somebody pays for that work, too.

> 2)  Lack of implementor time to implement all the things that people
>     care to think up all at once.

This is the most important part in my mind. My point is that
implementors are already independantly deciding which parts they will
implement. For example, no implementor has tried to blindly implement
all of CSS2 before implementing even a single feature from CSS3.

As a result, the process should be changed more towards the situation
where Recommended spec documents the features that implementors have
considered worth implementing.

I guess I'm suggesting more power to implementors on deciding which
parts get Recommended but if we want to have a spec that has real world
usage, it must much the available software.

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

It would be great if a feature couldn't receive Recommended status
without a test suite testing every part of the feature. However, I
understand that such test suite requires really much work.

If I have to choose between a feature that has been already implemented
interoperable and a feature that has test suite and hopefully gets an
implementation in the future, I will rather take the former.

> Are you volunteering for some or all of these?

Unfortunately, I don't have enough time (I don't get paid for that in my
job). I think that this is the same reason that there aren't enough
editors in part 1).

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

That's fine. Then all the features will be transferred to next release
cycle and hopefully they get implementations there or will be removed by
the editor in the future.

The real problems raise when the specification release cycle is much
longer than the release cycle of the UA releases. This is the current
situation.

-- 
Mikko