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

[Jon Rimmer:]
> 
> 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!

Note that technically, WG chairs appoint editors. In practice they consult
the group so it's usually a collective decision.

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

Well, it has happened and it can happen. But a lot of the historical 
mismatch was also the result of not taking implementors' priorities into
account. Never mind that once upon a time implementors did not prioritize
standardization either (Netscape vs. Microsoft). I don't think we can
really compare the world as it was 10-12 years ago with today in this 
respect.


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

Agree. What is also happening is that with CSS2.1 winding down there 
is a lot more available time to discuss new things - and that's great - but 
the number of editors who can specify it has not grown anywhere near as fast 
as the volume of new proposals, never mind all the 'experimental' stuff
Webkit has been throwing around.

As far as specs and implementations being out of lockstep, that's unavoidable.
Though it has gone too far in some cases e.g. Animations.

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

The appearance is that you're right but I haven't yet figured out whether
Webkit is actually implementing the draft marked obsolete [1] or adding properties
with the same name aligned with subsequent discussions for which there is no
spec i.e. experimental proprietary properties derived from earlier work. 



[1] http://dev.w3.org/csswg/css-line-grid/
> 
> >
> > 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.

You're right, my bad. I should have looked at this more carefully. While 
specifying line grids is something we've discussed, implementation here
does seem way ahead of the spec process. Though, again, it could be pure
experimentation that only looks like implementation of a draft based on
a few identical property and value names.

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

It totally does. As much as I really, really like our individual Apple 
members, the general vibe around Apple and Webkit is not constructive 
in this area. It's not bad, it's just that no real conversation is happening 
(at least not publicly or that I'm involved in). I was one of the folks who 
argued internally to pull out our implementation of -webkit-text-size-adjust 
from an IE Mobile Beta after Apple contacted me on the matter nearly two
years ago now. In return, I asked that the property be submitted as it was 
in wide use and the responsible thing to do. Nothing happened that I know of 
and the number of webkit-only features has grown in the meantime.

Given the general frustration with prefixes, this may well come down to other 
vendors specifying and/or implementing -webkit features.
 
> 
> [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 19:03:07 UTC