W3C home > Mailing lists > Public > www-style@w3.org > January 2012

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

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Tue, 17 Jan 2012 02:57:17 +0000
To: Matthew Wilcox <elvendil@gmail.com>, Bjoern Hoehrmann <derhoermi@gmx.net>
CC: "www-style@w3.org Style" <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178290340155C@TK5EX14MBXC296.redmond.corp.microsoft.com>

[Matthew Wilcox:]

> Hey, thanks for the feedback :) I've got some responses inline too...
>>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.

>Fair point, though I had rather assumed interest was self-selecting :) I doubt people are going to join the list if they're not already >interested in it. Though there might be more interest in it if what the list does was clearer to the outside world.

Joining the list doesn't mean much more than 'this address gets a copy of www-style's traffic'. Contributions are really the currency of 'interest'. There is also the interest of implementors; if no one is interested in implementing your idea any time soon then the WG will not allocate much of its limited time to it. I would even say that today, new help with existing specs is more appealing than starting yet another batch of new modules.
>>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

>Yep, but that's not a problem for the WG, that's a problem for browser vendors.

See above. The WG (and this is true of WGs in general) prioritizes work on specs that can move along the standard track and become implemented standards (that it hasn't always done so does not disprove that it should prioritize them). The goal is not to just to 'ship specs' for the sake of it. Almost anyone can do that, really. Specs and their test suites are a means to achieving interoperability.
>>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 

>Not in such dramatic maner no, but more practically - yeah you kind of do actually. In fact I'd say that most of the useful information 
>I find about new CSS features is wrtten on and by browser vendors. Mozilla, Opera, and Webkik all have blogs that are extremely good at 
>communicating this stuff and soliciting feedback from the wider author community. I've seen a number of people on Twitter talking ?
>directly to browser vendor representatives about this stuff. I could point to @brucelawson as one prime example of this, he's always
>fielding questions about that stuff, and talking about Opera's work, getting feedback etc.

>>whatever the new black currently is,

>I do find the flippancy of this a little off-putting. To be very clear: CSS's shoddy layout systems have been complained about, loudly, >for many years.

Complaints are good. Proposals are better. Taking the time to write them, submit them, 'sell' them and keep going at it and it won't be long before you find yourself an Invited Expert and editor. (Ask Tab, for instance). Beyond the basic ability and desire to design something and standardize it, finding professional designers who want and *can* commit the kind of time this takes is simply not easy. You're pretty much adding a real part-time job to your schedule.

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

>Yep, that's an issue but one outside of the www-list concerns. It effects us, but we can't effect it.
>>Most of these questions are not good questions as the general answers
>>should be very obvious.

>Agreed - they should be! They're not though. They're obvious to you because you are familiar with all of those topics. Please, try and 
>clear your mind of what you already know, and approach the list from the perspective of an enthusiastic newcomer. How do you find out 
>that stuff? And I am being absolutely serious. You find your way to the www-list archive. How do you discover what the www-style 
>archive page is and what www-style does? How do you find out how to join? 

Actually, why don't you tell us? How did you land here?

> Once you do join, how do you find out the etiquette of the list? 
By reading and watching how the locals do it. While I've worked on open projects with some helpful FAQ on how this works, nothing can replace perusing the archive and reading the incoming traffic every day.

A public FAQ would be great but it also never hurts when joining a new community to not be in an urgent hurry to just do something and take the time to watch what's going on. You'll be much wiser and effective for doing so. 

> How do you find out that you're supposed to quote full threads in all replies? That you're supposed to structure the subject line in 
> some way? How do I find out how to set up my mail client? What special headers are sent with mail that I might find useful? How do I 
> get my client to expose them? How do I find out who is editing what specs? How do I discover how the W3c functions and the specific 
> part the list has to play? How do I discover how specs are edited? How do I discover the process in the lifespan of a request? That it 
> goes "bring up a point in the list > resolve the point > ... what now ..."? 

There are some good questions here and many are somewhat generic w3c questions; some are a bit puzzling: the spec's masthead lists its editors, for instance ? 

> It's these points I'm talking about. General "stuff" that's taken for granted here but that isn't general knowledge outside of the group.

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

>So this needs to be explained to people who are looking to help :)

>My whole point is to get the myriad of resources surrounding the www-style list in a better state to be of help people who are only >here because they want to help us.

Much appreciated.
Received on Tuesday, 17 January 2012 02:57:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:09 UTC