Re: Fast-track new people to areas www-style need the most help with

On 18 January 2012 16:42, Sylvain Galineau <sylvaing@microsoft.com> wrote:
>
> It's approved by WG members; usually someone volunteers either implicitly -
> e.g. they submitted the spec - or explicitly because they want to take
> over an abandoned module or agree to co-edit with the current owner. There
> is no other special step you need to take once that has been resolved; source
> control access is for all the modules. Once the WG agrees to you working on
> something, you can edit it.
>
> This can be decided on a weekly telcon or face-to-face.

Cool, thanks for the info!

>
> I don't quite follow. Two points were made, as I recall: first, that editors are
> the scarcest resources i.e. feature requests > implementor bandwidth > editing
> capacity. The membership of this group is growing far faster than the number
> of active editors. Fwiw I think that's a good problem to have as it's a normal
> consequence of success; I'd rather deal with that than the reverse!

That was in response to Bjoern's post, where he seemed to be saying
implementer bandwidth was lower than editor capacity, citing
historical examples of HTML features that never received
implementation, at least that was my interpretation? I just wanted to
point out what seemed like a good counter example.

My own impression is that the relationship between editorial
implementation resource isn't as simple as there being more of one or
the other. There's often surpluses or deficits or different areas, and
this leads to specs or implementations getting ahead of each other.
Specs getting too far ahead isn't particularly harmful, just a bit of
a waste of time, but implementation outrunning specification is far
more dangerous.

> Second, we would rather *prioritize* editor resources to features that have a decent
> chance of being implemented in a reasonable amount of time. Do you have any reason
> to assume this specific work was not started as a result of this process? If we do
> prioritize specs based on the level of interest of implementors, shouldn't implementation
> happen earlier rather than later? Is there any reason to think that sometimes work will
> happen from a very early draft? We had an implementation of Grids before there was a first
> public working draft, for instance.

I think there's a distinction between specification and
standardisation. I think that any implementation of an author
accessible feature should be announced to this list and
contemporaneously specified. Not as a published working draft, but as
an editor's draft in CVS or a similarly precise document somewhere
else. The actual formal standardisation can follow later, when the
feature is stable, but the specification should happen immediately;
it's just too easy for it to fall behind or be forgotten about if it's
left until later.

In the case of line-grid, it isn't that an early draft is being
implemented, it's that a draft explicitly marked as "obsolete" and
"not being actively maintained" [1] is being implemented. Or is it? Is
it instead based on Fantasai's counter proposal in the mailing
list[2], with Dave Hyatt's modifications[3]? The early implementation
isn't a problem, but the lack of clarity is.

>
> What makes you think there is no concern about it? Our last face-to-face began
> with a 90mn discussion of this exact topic based on the long backlog of issues
> filed in this mailing list against css3-animations and css3-transitions. The
> result of which was to assign new co-editors to the spec. This issue relates
> to the first point above (editing bottleneck).
>

I wasn't aware of that discussion, but I guess I was just surprised
that nobody had mentioned the line-grid implementation prior to my
posting about it. There are enough people in this list who work on
Webkit that it can't have escaped their attention. And initialy there
wasn't much response when I did raise it.

> Also note that the larger complaint about Webkit features is not as much
> about the ones that are specified lagging editing muscle - though that's painful as
> fixing it is going to take an editing toll on other members - as much as the ones
> that were never submitted spreading all over the place (e.g. -webkit-text-size-adjust
> on mobile). This area - widely used but 100% proprietary properties - is where other
> vendors are seriously considering jumping the prefix fence.

Agreed, this all sucks as well.

[1] http://dev.w3.org/csswg/css-line-grid/
[2] http://lists.w3.org/Archives/Public/www-style/2011Jul/0237.html
[3] http://lists.w3.org/Archives/Public/www-style/2011Oct/0745.html

Jon

Received on Wednesday, 18 January 2012 18:19:23 UTC