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

On Wed, Apr 7, 2010 at 10:55 AM, Eduard Pascual <herenvardo@gmail.com> wrote:
> - Become an "invited expert". That quite reminds me of the times when
> GMail was "invitational", and having a GMail account was a privilege.
> Who "invites" people to join the W3C work? How is "expertise" measured
> for potential invitees?

The individual group makes that decision (the CSSWG, in this case).
'Expertise' is measured however we want.  I think in practice it's
simply a measure of if we think the individual has a commitment to the
group and would be a valuable addition due to their skills or
knowledge.


> Another bottleneck is the way specs are organized and advanced through
> the recommendation track. How long has passed since work on CSS
> Selectors Level 3 began until all major browsers implemented it?
> (hint: while MS has announced that IE9 will implement that module,
> this has yet to happen). In contrast, how fast are things like
> <canvas> or <section> being deployed?

<canvas> was created by Apple and put in Webkit before it ever
appeared in HTML5.  <section> still isn't, I think, actually natively
supported by anyone (it still acts like a default unknown element in
FF, frex, and you have to manually set display:block on it).


> Maybe it's time to learn from HTML5's quite successful process, and
> incorporate some ideas of it into W3C's.

Most of HTML5 still isn't implemented.  The things that are
implemented are because there is significant demand there.  If CSS
features aren't being implemented, it's because there isn't a similar
level of demand for them.

(That doesn't necessarily mean they're less valuable to have, just
that they're somewhat less sexy.)


> Proposal #1: Facilitate participation on the W3C process.
> Sumary/Goals:
> - Allow volunteers to contribute on the tasks where bottlenecks are
> found (test suite development and spec text authoring seem to be the
> most prominent).

I'm in the middle of a major project that should make test-suite
development substantially easier, more open, and more useful.  I'll
have an alpha version out before winter.


> - Make more clear and simple the requirements for joining the W3C work.

They're perhaps not very clear, but they're at least simple.  It's
just a matter of making yourself useful enough to get invited in.


> - Ensure that the ability of and individual to contribute on a task is
> determine by the individual's suitability to the task, rather than by
> political/business factors such as employment status and the like, to
> the maximum possible and reasonable.

This is largely limited by w3c process itself.  As long as the CSSWG
is a w3c organization, we can't substantially change it.  If you're
part of a large enough company, the company is required to become a
w3c member and then nominate you.  If your company is small enough and
not expected to be interested in joining the w3c (or you're
self-employed), it's not necessary, but then the WG has to decide that
you're useful enough to bring in.


> Rationale:
> It's known that on many cases the specs stumble against non-technical
> walls through the recommendation track. Currently, it's fairly easy
> that two or more implementations of a feature survive the
> "real-world-usage" test, but still the spec lingers on LC stage while
> waiting for formal test-cases to be developed for them.

I'm not sure that "lingering on LC" is a fundamentally bad thing.
Yes, we want to push things to PR and then Rec, but in terms of
stability, LC is effectively the end-point for new additions.  Once we
hit LC we try to only pull it back when significant issues have been
raised, not just to add something new.

I don't see any problem with starting a new level of a module in WD if
the previous one is in LC and only waiting for a test suite.


> On other cases, a desired feature can be well-known and even easily
> implementable, but the editors might fail to find an appropriate
> wording for it. It's not that unusual that a possible feature is easy
> to imagine and even describe in the abstract; but it turns to be very
> challenging to translate it to more formal language (a.k.a.
> spec-quality text).

Do you know of anything that is actually being held up for this
reason?  I think that, in general, translating something to 'formal
language' is mostly a matter of actually figuring out what the details
are.  Some things are indeed easy to describe in the abstract, but are
incoherent or undesirable when you drill down to the precise details.


> Also, it's quite common that people contribute really good ideas, but
> they fail to describe them in terms of use-cases and requirements.
> It's a huge hassle for the few editors to extract these details from
> the contributor's description.

You don't need to be an editor to help out and pull use-cases and
requirements from other people's ideas.  I was part of the list for 2
years before I was asked to join the WG, and I did precisely that for
a bunch of things.  Doing so is an indication that you'll be a good
editor, actually!


> Specific details:
> - Create a "level" of contribution that doesn't involve so much
> bureaucracy to opt in for contributors. This could be called "External
> collaborator" or "External assistant". The key aspect is that it
> should require neither invitation nor specific employment status
> (after all, unemployed people probably have a lot more time to commit
> here ;) ). Reasonable requirements are:
>  -> Have reached a minimum degree of participation on the mailing
> lists for the relevant specs (for example, these lists for the case of
> a CSS collaborator).
>  -> WG members may object against a potential collaborator (for
> example, on the suspicion that it's a troll). Such objections should
> be voted by the WG, giving the Editor or the Chair the high vote in
> the event of ties. Specific details are up to the W3C.
>  -> Ability/Commitment to participate on online meetings regularly.
> Ability to participate on F2F meetings should not be a requirement for
> these positions: many people may be suitable to undertake the
> collaborator role but still be unable to travel across the globe.
> Monthly meetings seem a reasonable frequency to me, but the details
> are up to the W3C and may probably vary between different WGs.
> - The role of External Collaborators is, in essence, to take away the
> bulk of the Editor's and WG member's work, allowing them to focus on
> supervising Collaborators and taking technical decisions; instead of
> spending so much time on interacting with so many contributors on the
> mailing lists. Specifically, External Collaborators would (each
> Collaborator might focus on different tasks):
>  -> Translate informal feature requests from mailing list
> contributors into more formal draft update requests, by: 1) Gathering
> use-cases and requirements for the proposed feature; 2) Describing the
> feature with "spec-quality text"; and 3) Justifying that the feature,
> as described, addresses the use-cases and fulfills the requirements.
>  -> Develop, collect, and formalize test cases from feature
> requirements, mailing list feedback, real-world feature usage (let's
> be careful with code copyright), and any other source. Also test the
> tests themselves, and document them (describe clearly what they are
> supposed to check, and what an implementation has to do to pass the
> test).
>  -> Help warming down disputes on too heated debates. I don't
> remember anything too big on this list, but those of you who are also
> on the WHATWG's HTML5 mailing list will probably remember how the
> discussions about semantics/RDFa/microdata escalated into something
> close to open warfare. On that specific case, I admire how the editor
> politely handled the situation and calmly replied to even the most
> hostile posts. However, I don't think a spec editor should be left
> alone with such a task: it's handy to have a "reference authority" for
> these cases, but having to act as the teacher in the schoolyard
> prevents the editor focusing on the main editing tasks. A possible
> alternative could be to have some moderators on the lists; but
> mediating between conflicting sides seems a better approach than the
> warning and banning approach many discussion boards on the web take.
> - It seems that the ideal amount of collaborators for each working
> group would be something in the order of sqrt(community_size). So, for
> example, if a community has 900 members, the WG can directly interact
> with ~30 collaborators, and these would be interacting each with ~30
> contributors on average. In any case, each group, each person, and
> each community are different, so this is just a very rough guideline,
> not a hard rule.

This is beyond the scope of the CSSWG, as it involves a fundamental
change in w3c process.  However, there's nothing wrong with
contributing in exactly the manner you describe while being a
"Participant" in the group.  The CSSWG is an open group that does all
its business on a public mailing-list, so anyone can help out anyway
they want.  The only things they can't do are actually edit a spec, or
attend an official meeting (though sometimes observers are allowed).
There is an important reason for this - part of becoming a member is
agreeing to the w3c's patent policy, which is very important to ensure
that anything we spec is free of patent obligations known to any other
member.

Plus, the w3c is funded entirely through its member fees.  If it was
easier to forgo paying the member fee, it would have less money to
operate on.


> This approach shouldn't prevent Editors and other WG members from
> interacting directly with the wider community; but should prevent them
> to have to deal directly with each message sent by each member, which
> is an insane amount of work for so few people.

That's what we do right now, and it doesn't seem very insane at all.


> Specific details:
> On WHATWG's process, each feature of the spec advances independently
> through their equivalent to the "recommendation track". While this
> might not be too good to apply "as is" to specs produced by the W3C;
> it can be applied partially:
> - Up to the CR stage (included), let each feature advance
> independently through the track. Once a specific feature hits the "CR"
> state, it's already suitable for implementers to start working on it,
> regardless of how other features are doing. This means that
> implementation work can begin on the mature features while the
> immature ones are still unstable.
> - When all features within a spec have reached the CR status, the
> whole spec can be marked as a Candidate Recommendation, with the
> advantage that many of its features will probably be already
> implemented.
> - If most features within a spec reach CR status, but few others are
> holding the spec back, the WG will consider whether it's worth having
> the full spec waiting for them or let them fall back to the next
> iteration/version/level of the spec.
> - As soon as an iteration/version/level of a spec is on CR stage, the
> WG should be open to begin work on the next iteration. This doesn't
> mean that such work needs to begin immediately. For example, with CSS
> Selectors Level 3 already on PR stage, the CSS group should be open to
> proposals made for Selectors 4; but it's ok and reasonable to not
> commit too many resources to it while other CSS3 modules are still
> work in progress.

We don't rate individual features in terms of stability, but otherwise
you exactly described current process in the CSSWG.


> It's possible that some people choke at the idea that, for example,
> Selectors 4 might reach CR stage before some modules of CSS3 reach
> even Last Call, but that would just reflect the dynamic nature of the
> web and the communities around it: there is probably more need for
> advanced selector features than for elaborate mathematical notation
> (after all, any document using CSS will be using selectors, while only
> a few of them will be using math-related features).
> If the W3C process' output has to be sped up, a will to sped things up
> is needed. Let's keep an open mind and remember that the future is
> only "future" until it becomes "past".

The entire point of modularizing CSS *was* to allow things like
Selectors 4 reaching CR while other "level 3" specs are still in WD.
Nothing wrong with that.  There is no overall concept of "CSS 3" that
holds back development of future levels.  It's just that the WG as a
whole somewhat stagnated for a few years, and now that we're spinning
up again, we're just now running into places where we need to develop
a level 4 of things.  Backgrounds & Borders already has a level 4
Editors Draft, there are several features planned to drop into a
Selectors 4 draft as soon as someone gets around to writing it, and
now we have something that should probably go into Colors 4.

No real problem here, it's just the inertia of a group that is
spinning itself up into a higher activity level.

~TJ

Received on Wednesday, 7 April 2010 18:29:06 UTC