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

* Matthew Wilcox wrote:
>I wrote a post about my first week's experience on the list [1], and Tab
>Atkins Jr replied, clarifying what I think is a fairly obvious problem
>we have: A lack of sufficiently skilled people capable of editing the
>actual specs.

You missed the point about "interest". There are a number of people who
have edited CSS specifications in the past but are now doing something
else for various reasons, say they work on things more important, and if
you add editing resources to the CSS Working Group, that might well re-
sult in current editors moving on to work on other things, so you might
ultimately fail to close the gap that you see.

You can also consider this from another angle: you can't arbitrarily in-
crease output of the CSS Working Group without also increasing resources
spent on actually implementing the specifications while expecting good
results. Consider for instance that HTML had a "video element" since the
late 1990s in the form of http://www.w3.org/TR/NOTE-HTMLplusTIME and
declarative vector graphics in the form of http://www.w3.org/TR/NOTE-VML
both of which were implemented in Internet Explorer, but it took a whole
decade for other browser vendors to catch up. That is a demand problem.

You don't exactly see authors or users protesting outside the offices of
the various browser vendors demanding better advanced layout features or
gradients or whatever the new black currently is, much less do you see
anyone demanding browser vendors allocate more resources to the CSS WG,
and it's rare to see any kind of structured effort to identify what they
should prioritize. Also demand problems. And that browser development is
largely financed through subsidies is another demand problem, in that it
is often unclear where satisfying demand would pay off in some form; the
author-facing feature development you do see is usually comes from in-
ternal needs ("we want more people to use our webmail more, but people
often need their mail when offline, so give us offline access features")
and from not wanting to fall behind ("when people make cool stuff using
$feature and that feature does not work in our browser, people switch").
That demand is already being satisfied to the degree investors care.

>Let's assume I want to be able to help out at that level - how do I find out:
>
>* What do I need to know?
>* What skills must I have?
>* Who do I talk to about this?
>* What is the process the group go through, from start to finish?
>* How do I learn the things I must in order to edit a spec and work with the group well?
>* Where are edits made (seriously, where do you edit a spec? How?).

Most of these questions are not good questions as the general answers
should be very obvious. Discussions on this list are in english, so you
need to be able to formulate your thoughts in english and understand the
thoughts of others when formulated in english. It's a collaborative ef-
fort, so you need to be able to work with others towards some vaguely
common goal. That includes understanding that others are able to fill in
for you if you have trouble with something. Over at the IETF they have
the RFC Editor who is good with orthography and grammar and spotting
possibly confusing formulations and will take care of these things even
though the RFC Editor is unlikely to understand the technical details of
a specification in full, and is not involved in turning a decision like
"the foo must authenticate with bar using baz" into specification text.

Editing a very mature specification like CSS 2.1 is more a matter of the
Working Group deciding that "OLD TEXT" is to be replaced by "NEW TEXT",
and the editor is mostly supposed to commit that change to the revision
control system, adapting cross-references and section numbers as needed,
perhaps noticing that "teh" was meant to be "the". Ideally they would
notice problems with the edit ("when I apply this edit, the description
of the example in section so and so contradicts the new text"). With a
less mature specification the expectation might be that the editor will
write large parts of the specification's text, facilitate discussions
with reviewers, and many other things. Some times an editor is supposed
to safeguard a specification from bad influence, other times they might
be supposed to quickly give way to new ideas even if they disagree with
them.

For a specification for "international layout" you are probably better
off with an editor who is familiar with non-western typography, and for
a syntax specification you probably want someone familar with formal
languages. For a "Mobile Profile" specification you would want someone
connected with the "mobile industry", for new structural selectors you
want someone familiar with graph algorithms and Landau symbols; you do
not necessarily need them to be, but there is a frictional loss when
they are not and have to involve others.

It would be much easier to answer what helps in being a good author of
technical specifications or a good reviewer. People who end up being an
editor tend to be that, and they typically do not end up "editors" be-
cause they have certain editor-specific skills. But your question was
about how to find out how to, and that is a primary purpose of the list
here, you can observe what people do, what they say, how they behave,
you can read through the output of the Working Group, how people turn
decisions into specification text, how they deal with setbacks, you can
learn of all the ideas people have with respect to improving CSS, what
the problems with those ideas are, which mistakes people make when they
try to "specify" something, if you simply follow the list, understand
mistakes and how to avoid them while still productive, that should be
quite sufficient to merely be a good editor or fill some related role.

So, in conclusion, there are no people who prepare to become an editor
of Cascading Style Sheets specifications, nor is there any common way
that isn't rather complex how people end up in that position. Trying to
understand this under the assumption there are and there is, is unlike-
ly to produce satisfactory answers.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Monday, 16 January 2012 02:25:33 UTC