Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for That Old-Skool Smell

Hey Larry,

Digging further into the stated justifications for workshops, I found this. It seems to indicate that the goal is to help facilitate early spec work. The main workshops page is even more explicit:

W3C organizes Workshops to promote early involvement in the development of W3C activities from Members and the public. The goal of a workshop is usually either to convene experts and other interested parties for an exchange of ideas about a technology or policy, or to address the pressing concerns of W3C Members

I suppose that falls into line with both of our assessments but we seem to differ in our perspective on if or how the goals meet the formulation.

Perhaps I'm bringing too much context to this, but it doesn't seem to me that it is a productive use of anyone's time for these sorts of meetings to happen without something concrete to discuss: a scoped problem, a clear proposal, etc. It also seems evident that the stakeholders are a largely fixed cast: web developers of varying origin have interests in building better things, platform vendors need to prioritize work and ensure that they're paying attention to the right bits, and the W3C as an organization needs to ensure that it is relevant.

It doesn't seem as though these meetings are likely to be a success (as defined by "are the catalyst for useful design, implementation, and standards work") unless the W3C is facilitating them in such a way that they are bringing that cast together to discuss a shared problem that everyone understands some part of. Assuming that the W3C will know nothing about the problem area, won't have local knowledge of the issues, and is a context-free referee for a game it doesn't care about seems like the heart of the disconnect.

At a greater remove it becomes evident that the W3C must choose its facilitators well and help set the tone and environment to encourage productive outcomes. There's a lot to the functional goals that defines the form, and right now the goals appear confused, so the format of the meetings is similarly amorphous. A focus on results might create a different set of priorities and a different structure for the meetings.


by alex at
I always thought the main purpose of a workshop was mainly to introduce people to each other, and the 'position papers' were the ways in which workshop participants and others could discover who they really want to talk to, what stakes the stakeholders held, and to elucidate issues.

You seem to be wanting design meetings where the stakeholders and issues are already known, and you're just trying to be most productive. That's a different kind of "workshop" (more like an 'open working group meeting').

(Speaking as an AC rep ...)

Workshops' scope and expectations vary quite a bit (as they should) and it is certainly important to try to clarify that as much as possible in the announcement and to make sure the moderator(s) have the appropriate skills (which doesn't necessarily mean domain knowledge).

Anyhow, one of my colleagues had a similar response after attending a Workshop (basically "WTF, we didn't talke about any details at all!"). Consequently, I tell everyone interested in a workshop two things: 1) the probability of a deep technical dive during the workshop itself is low (although the workshop can lead to more detailed corridor/lunch discussions); 2) the "best" outcome is a relatively clear understanding of Who is actually committed to do What and some idea of When.

Hey Art:

Thanks for the thoughtful response. I'm curious to know, in your view, if W3C's current approach to Workshops is functional. E.g., is it producing a great quantity more value for the community than they necessarily consume in terms of direct and indirect costs?

What is the AC's expectation of how Workshops create whatever value they generate? Are they meant to be pre- or post-WG-formation activities? Both? How should they differ if so?


by alex at
This reminds me of something I call the "use my toys or you can't play with us" phenomenon that keeps designers out of the code-side of front-end development. When designers want to learn JavaScript, often the starting points suggested to them are not things designers are interested in (IRC) or understand (books written by and for programmers). The same with participating in the W3C: we're asked to sign up for and participate in a bloated mailing list which will be like piping a fire hose into our already swamped inboxes.

It's not that enticing if you can't access something on your own terms. This means the only people attracted to an feeding into these conversations are those who can appreciate or stomach the existing infrastructure, essentially cutting off or dismissing an entire segment of users and builders with very important feedback.

Do I have all the answers? No. I can only recognize this as a problem. But if I had to start somewhere, I'd start by reaching out to these people on their own terms: How do they communicate on their own passion projects? Can we bring the mountain to them in some way (like @CSSCommits)? Is there a more modern, transparent way to communicate?

I don't pretend to have more than the vaguest idea of how as a developer I'm meant to involve myself in the W3C's process, other than posting to WG mailing lists (after a suitably stiff drink and a deep breath). However, like most people I'm trying to unhelpfully solve the problem from a position of ignorance, and my solution is Edge conference (Obvious plug:

If the problem is that devs are typically too ignorant of context to be insightful in these conversations, then setting up a system that requires them to have a full understanding of context in order to contribute (or be 'known good') is simply elitist, exclusive, and rather self-defeating.

If the fear is that altering the process to be inclusive of unknown people will prompt a tidal wave of contributions from the ignorant AND incompetent, then perhaps a middle ground is to have a process that welcomes the (partially) ignorant, but selects for competence. That's what we're trying to do with Edge.

Hi Alex, I hope that what you're writing about relates only to a minority of our workshops, and that in addition to this post and the Twitter conversations, you will (if not done already) ensure to share your opinion either with your TAG staff contact or with the W3C Communications team (via publicly archived that Ian Jacobs monitors.) Best regards. Coralie
Re the value of workshops, that's a bit of a judgement call and I don't think it would be accurate for me to try to extrapolate my personal experience to cover "the so, what do the ~400 Members think about workshops" question. That said, in my experience, when the expectations and scope were clear, I think the workshops were valuable.

Re the costs, I don't think the overall costs of a workshop are that high and it could save resources in the long-run if the outcome is to not start related work (e.g. a new Working Group) that otherwise would have been started and dragged on, and eventually died.

Re, what could be done to make workshops more useful. That's a good question and something W3C staff should ask the Members. Perhaps it could be useful if workshops were a bit more "organic" (lower overhead to organize). For instance, members of a CG could host a virtual/distributed workshop e.g. to try to engage a larger community, determine if there is interest in doing X, etc.

Hi Alex,

Workshops offer an important opportunity for people to get together and share perspectives, but as you rightly note the requirement for a "position paper" doesn't look like it works well for a real segment of the people we should have around the table.

On the other hand, it is important for another segment. And in practice, there is a lot of flexibility in what is required.

One of the risks in just inviting "all the right people" is that you don't. Announcing a workshop long in advance, and looking for ways to get the right people there is some help in getting more of the right people. Admittedly, it might bring in people whose contribution ends up not being very relevant, but it is the purpose of a "program committee" to try and filter effectively, keeping the signal/noise ratio high but also maximising the signal in the first place.

Ad hoc meetings often get a good signal/noise ratio, but also tend to get a pretty restricted set of signals.

I strongly agree with Art and Larry - the success of a workshop depends a great deal on the people running it. I have been to W3C workshops that were successful, and that have not. But I think they are generally useful, and I expect to attend more of them.

by chaals at