Comments for That Old-Skool Smell
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').
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?
Regards
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?
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.
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.
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.
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:
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.
Regards