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

There are some recurring key points that have been highlighted again
by Mikko's and Boris' e-mails. Maybe it's worth reviewing each of
them:

1) The W3C process is perceived by many people (me included) as being
painfully slow.
The key here is to figure out what are the core bottlenecks of the
process, and find ways to fix them.

2) The W3C process is not arbitrary: its stages are well thought of
and the process itself has been fixed to address some issues.
The most blatant example was CSS2: the W3C was too eager to get it
out, and as a result we had to wait for 10 years until the most used
UA (Microsoft's Internet Explorer) implemented at least most of it
(which finally happened with IE8, I'm not sure if their implementation
is fully compliant with the spec; but it's a well known fact that
sites that can forsake IE7 and earlier can get things done which many
less headaches).
When we speak about speeding up the process, let's keep that historic
lesson in mind to avoid making the same mistakes again (what's the
point of getting the specs faster into Rec stage if it takes longer to
get them into "usable in real-world pages" stage?)

3) "Are you volunteering to...?"
That kind of questions are, on the best case, an euphemism. If it
weren't because it came from Boris, I'd take the last one even as an
insult.
Last time I checked, there are two ways to be part of the W3C process:
- Be an employee of a W3C member company, and have that company commit
your work time to contribute on the W3C work.
- 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?

Looking back at 1), it seems that we have figured out one of the
bottlenecks on the W3C process: shortage of manpower, coupled with
obstacles to acquire more manpower.
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?
Maybe it's time to learn from HTML5's quite successful process, and
incorporate some ideas of it into W3C's.


Upon those arguments, I'm making here two orthogonal proposals, which
are related mostly by the fact that they both attempt to address the
causes of W3C slowness. This doesn't fit too well in the CSS-specific
list, but it's derived from a thread here; and I don't know where else
to post it; so here it goes and feel free to forward it to the
appropriate place.

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).
- Make more clear and simple the requirements for joining the W3C work.
- 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.
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.
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).
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.
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 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.


Proposal #2: Learning from the WHATWG process used for HTML5:
Summary/Goals:
The W3C process could take profit of some approaches taken by the
HTML5 folks; without having to change too much of its current process.
This should allow for similar benefits as those achieved on HTML5
work: faster implementation and clearer advancement through the
recommendation track.
Rationale:
This very thread poses a great example: a feature that would be very
cheap to specify and implement is stuck just because of how the W3C
process work. The technical costs are very low, but the administrative
ones are too high. This also hurts the ability of the community to get
nearer to a consensus, since each part may place higher importance on
either kind of costs. Hence some mechanism to reduce administrative
costs of adopting new features (in general, improving the World Wide
Web) could be highly useful.
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.

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

I'm strongly convinced that these two proposals, used together, can
provide a huge boost to the W3C process.

Regards,
Eduard Pascual

Received on Wednesday, 7 April 2010 17:56:51 UTC