Posts from Friday, September 15th, 2006

My first suggestion for improving the W3C is this:  every Working Group should have one member whose primary (and possibly sole) responsibility is outreach.

To make life a little easier, I’m going to refer to this position as a WGO (for Working Group Outreach).  As an aside, I’m not sure that “outreach” is exactly the right term for what I have in mind, but it’s a decent term that captures most of what I have in mind, so I’ll use it here.  If someone comes up with a better term, I’ll be grateful.

So here’s what I envision for a WGO.

1. The WGO keeps the public informed about the top issues on the Working Group’s agenda and immediate-future activities.  The easiest, most obvious way to do this is to post a summary of every WG FTF (face-to-face) meeting.  A summary would describe the topics the WG discussed, resolutions that were reached, which problems were not solved, and so forth.  This could be a bullet-point list, but a better summary would be something like a short article.

   Note that I do not say that the WGO should post the FTF minutes, which are often private.  The results of those discussions, though, should be public, even when no results occurred.  A summary can say that the WG discussed a topic at length and reached no resolution without saying why.  It can also say that a topic was discussed and a solution found, and then describe the solution.

   A really good WGO would produce an activity summary more often than every FTF.  I don’t know that I’d insist on a summary for every weekly teleconference, but sending out a summary once a month would be more than reasonable.  These summaries would be posted on the W3C site and to the relevant public mailing lists.  For the CSS WGO, this would always mean posting to www-style.  In cases where WG activity touched on features of XHTML or SVG, summary posts would be made to those public lists as well.

   The purpose here is to draw back some of the curtain surrounding Working Groups.  Too often, interested members of the public don’t know what the WG is up to, and that can be frustrating.  If there are several people agitating for a new feature and the WG stays silent on it, it’s impossible to tell if the WG is blowing the idea off or if it’s something they’ve considered at length but haven’t yet reached a decision.

   Public summaries also have the benefit of allowing some public discussion of work before the public-comment period on a proposed specification.  This would help distribute the WG’s feedback load.

2. The WGO brings the needs and concerns of the public to the Working Group, and communicates back the WG’s reactions.  This means part of the WGO’s job is to be involved in the wider community surrounding a given activity.  The CSS WGO, for example, would spend time reading web design mailing lists, forums, blogs, and so forth to find out what people in the field want and need (in CSS terms, anyway).  The WGO would present these to the WG as items to consider.  The topics so raised, and the WG’s responses to them, would go into the next summary.

   The goal here, of course, is to have someone on the Working Group who represents the “in the trenches” folks.  If there are other members of the WG who also represent those who work in the field, that’s awesome.  With the WGO position, though, there’s the assurance of at least one person who speaks for those who actually use the products of the Working Group, and who will use any future products.

3. The presence of a WGO in a Working Group should be a charter condition.  No group should be (re-)chartered without an identified WGO, and the extended lack of a WGO should be cause to question the continued charter of a group.

   Basically, I’m of the opinion that if a WG can’t find someone passionate enough about what they’re doing to be the WGO, then it’s time to ask whether or not they should continue at all.  Similarly, if there’s no real community for the WGO to represent, then it’s time to ask why the WG even exists.

4. The WGO should have no other major responsibilites within the Working Group.  This means the WGO cannot be the WG’s chair, and should not be a specification editor.  Their primary job should be the two-way representation I’ve described here.

   It’s too easy to get overloaded in a WG, especially if you’re the kind of enthusiast a good WGO should be.  There needs to be a defined limit to the position, so that outreach is always topmost on that person’s agenda within the WG, and it doesn’t get buried under other duties.

In summary, a good WGO would act as a liason between the Working Group and the community surrounding it.  A great WGO would do all that and also produce information that helps expand that community.  They could publish quick how-to’s, for example, concentrating on either current or near-future specifications.

If you could, please allow me to illustrate my points with a few things that a CSS WGO might do in the course of their duties.  I’ll call this CSS WGO “Bob” to make the example less clumsy.

Recently, Bob’s been seeing a lot of calls on blogs for an “ancestor” selector.  This would be something that lets you say, “style this element based on its descendants”, such as styling all links that contain an image without having to class them.  (This idea has come up many times in the past, by the way, but has yet to be added to CSS.)  So Bob brings the “ancestor selector” subject to the WG.  The WG says, “Yes, that’s a very good idea, but it runs aground on the following problems.”  Bob would then put all that into his next summary: “The WG is in favor of adding the ancestor selector, but the following problems prevent its inclusion…”  Bob could certainly also communicate the response directly, through mailing lists or blogs, instead of just putting the response in the summary.  The latter is necessary, of course, but doing both is better.

How is this better?  Because the community knows the WG has considered the idea, where the WG stands on the idea, and the reasons why it hasn’t been accepted.  Everyone knows where the sticking points lie, and can make suggestions to overcome them, instead of just guessing as to why the requested feature hasn’t been adopted.  As for the reasons, they could be anything from “that’s demonstrably impossible in an entropic universe” to “not enough implementors have committed to doing it”.  As long as we know what the roadblock is, we can act accordingly.

Furthermore, Bob might accompany a new version of the Advanced Layout module with a quick how-to article that describes how to do a certain common layout, one that’s very hard to do in current CSS, with the stuff in the new module.  This provides a quick, “wow cool!” introduction to the WG’s efforts, which can energize the community and also draw in new people.

I will readily grant that many WGs have what are effectively unofficial WGOs; in a lot of ways, you could argue that I’ve been a WGO for years, as have several other people, through books and articles and forum participation and blogging and so on.  That’s not enough.  There needs to be someone inside the Working Group who is focused on explaining to the world what the WG is doing and who is explaining to the WG what the world is doing, or at least trying to do.

So that’s the first of my three major suggestions for reforming the W3C: an outreach person for every Working Group.

• W3C Change: Outreach was published on Friday, September 15th, 2006.
• It was assigned to the W3C category.
• There have been eighteen replies.