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

On Fri, Apr 9, 2010 at 3:32 AM, Alberto Lepe <dev@alepe.com> wrote:
> As a newcomer, I found all these comments really useful to understand
> how W3C works in general.
That means that my idea of gathering this stuff in a FAQ might indeed
be useful ^^.

> I was amazed when I first read that in 2005
> the #rrggbbaa feature was suggested and was not added because it was
> "out of time". I think this prove in some way that sometimes the
> process slows down some proposals.
This is a cost that the W3C process pays to prevent other issues, like
the CSS2 fiasco (a.k.a. the IE-takes-over-a-decade-to-support-it
issue). Having suffered from the issue on my own web-authoring work, I
consider this a reasonable cost to pay. Having the W3C "recommend"
(ie: specify on a Recommendation document) a feature earlier is not as
important as being able to use it earlier (which requires major
browsers to support it or to have reliable and flexible fallback
mechanisms).

> Could it be possible to divide module stages into chapter stages? This
> is,  that each chapter (inside each module) could have its own
> recommendation level?
This is a midpoint between the current Modularization approach, and
the independent feature stages I suggested.
Yet still, modularization itself is a midpoint between the old
monolithic approach and more fine-grained suggestions. I'm quite
convinced the WG put serious thought and work on Modularization before
CSS3 was split into its current modules, so it seems obvious that this
approach represents the level of break-down the group considered most
optimal, keeping in mind a wide range of factors.

> In that way new proposals could be easily added
> in "WD" status (if would be a complete new chapter) or pull back only
> the chapter in which will be introduced. If one chapter is somehow
> related to other, then both chapters should be pulled back. The
> maturity of a module could be evaluated in terms of its chapter's
> maturity. If editors are too busy, then contributors could work in
> independent chapters and then submit it to the editor for approval.
How much does that differ from the current process in practice? Let's
look at the closest example: CSS Colors Level 3 and the #rrggbbaa
feature: the module being at LC stage means that all chapters on it
are, at least, on LC maturity stage. Adding a new WD-maturity chapter
for the new feature would cause the global maturity of the module to
pull back to WD. That's exactly the same as pulling the module back
from LC to add the feature.

> I think it could be really helpful if many of the proposal could
> follow a similar (but not the same) path as in Ubuntu brainstorm.
> Maybe as Eduard proposed, let some "contributors" to pull some ideas
> from the mailing list and let people to vote and comment in the W3C
> brainstorm site (please don't think the name is a rip-off ^.^).
That's going to be a key entry in the FAQ. The fact is that this
doesn't require any changes to the W3C process ;-) (a side fact is
that such fact is not widely known). If you think you are capable of
doing so, nothing prevents you from turning an abstract discussion on
the lists into a formal feature request broken in use-cases,
requirements, specific spec-text update proposals, and rationales for
each part. And I bet editors and other WG members will see it, and
take profit of it instead of re-reading the whole thread to do exactly
that. If you post that "formalization" back to the thread upon which
it was based, people on that thread will be able to challenge it (for
example, a use-case or a subtle requirement went unnoticed), and group
members will see any replies. The mailing list is a great resource,
currently used at only a fraction of its true potential.
This quite remembers me how the CRDF draft evolved on the WHATWG
mailing lists [1]: it didn't require the WHATWG to do any extra work,
as it was reviewed and updated by the interested individuals. Although
the HTML5 Editor was kind enough to drop by and leave some feedback,
the value of his posts were purely technical in nature, due to the
quality of the feedback, and had nothing to do with bureaucratic
approval or supervision. The key point here is that this kind of
development can perfectly happen for CSS features onthe CSS lists: at
the end it will be up to the Editor of the corresponding module and to
the CSS WG to decide whether the feature gets into CSS or not; but a
great deal of the work can be done by individual initiatives on the
list. Members can then focus on the final "centralization" work, as
well as on those areas were their expertise most shines (after all,
CSS WG members are, by definition, far more involved and experienced
with CSS than the average contributor).

> My feeling is that some comments can easily get lost in the mailing list
> if there are no follow-ups.
That's more than just a feeling: it's a fact. And you can see an
empirical proof of that fact on [2] (there are probably other cases,
but that's the first one I could pull out).

> One advantage could be that editors and WG
> members could just focus in those ideas with higher approval levels.
IMO, they are already doing that.. as often as the activity on the
list yields a notion of such approval levels. On a side note, I'm not
sure what do you exactly mean with "approval levels": who is supposed
to "approve" the ideas?

> Sorry if my English is not very good.
IMO, it's been good enough to clearly state your opinions and ideas
(actually, I've just reviewed your post and your English seems rather
good ;-) )
Anyway, let me take this statement (or, more exactly, the fact that
this kind of statements are so often added to posts to this list) to
highlight the mentions I did about communication issues and people
with non-native English making the effort to post here: I'm strongly
convinced that communication issues have more than once hurt proposals
and feedback that would otherwise be technically sound and valuable.
There is an issue here about the W3C process' internationalization
(not about i20n efforts by the W3C, but i20n of the process itself);
but that's an issue that we aren't likely to get fixed on a near-mid
future, we can only hope to reduce its impact. I'll try to find some
room for it on the FAQ draft I'm writting.

Regards,
Eduard Pascual

[1] It formally began on
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019733.html,
but the whole thing had been brewing up since
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-August/015996.html.
Emphasis on the process, rather than on the specific stuff being done.
[2] http://lists.w3.org/Archives/Public/www-style/2008Nov/0453.html
Compare the contents of the proposal (a simple way to solve a serious
issue) against the form (I have lost the count of issues on it).

Received on Friday, 9 April 2010 11:00:47 UTC