Chartering at W3C

[frivoal]

Session description

Reviewing and possibly improving chartering of Working Groups and Interest Groups is an AB priority for this year.

The goal of this session is to review the landscape, and have people share what they like and dislike about how it currently works, and share their experience.

We don't expect to resolve on anything in particular during this session, but it can be a good time to surface and socialize potential improvements.

Session goal

Get feedback on the W3C chartering Process, to be used as input for the AB

Additional session chairs (Optional)

@fantasai, @plehegar

IRC channel (Optional)

#w3process

Who can attend

Anyone may attend (Default)

Session duration

60 minutes (Default)

Other sessions where we should avoid scheduling conflicts (Optional)

#29, #3, #9

Estimated number of in-person attendees

Fewer than 20 people

Instructions for meeting planners (Optional)

No response

Agenda, minutes, slides, etc. (Optional)

• Minutes
• Calendar

[ianbjacobs]

Agenda details (removed from details above for formatting reasons)

• Intro (5 Minutes)
• Open discussion

[plehegar]

fyi, a few of us put together some slides that can be used as background reading for this session.

[plehegar]

Another resource on how things are done today: How to Create a Working Group or Interest Group.

[csarven]

While it is acknowledged that Team appoints WG chairs, I'd like to offer an initial set of questions for Self-Review Questionnaire for Chair Candidates for your consideration in response to "How are chairs chosen?" (slide 13).

[michaelchampion]

I can't be at this breakout session, but here are some thoughts on questions that charter templates and processes should pose and viable charters should persuasively answer. They treat Charters as an INVESTMENT of W3C's resources and credibility. Chartering is akin to a business decision about how to use those resources effectively.
....

• What real world problem does it address Focus on a concrete problem real users have with the current web. Be wary of abstractions. As I recall, it's somewhat rare for proposed charters to have a clear problem statement, and rarer still to have problem statements about real web users. Focusing charters on a problem to be solved and a story for how the WG will solve it would be the simplest way to improve chartering.

• Who will "buy" the proposed WG's solution? We've learned that web builders won't adopt a technology just because it's a "W3C Standard". But that is an implicit assumption in many charter discussions. Make sure the stakeholders needed to make the WG's output a success are engaged.

• Be extremely wary of "solutions looking for problems". That's been endemic in the high-tech industry for decades, and W3C hasn't been immune. For example, XML was a potential solution to all sorts of problems (and managed to get accepted as a good solution for a few). But W3C over-invested in it for a few years, promoting it in areas for which it wasn't suited.

• What is the unique value proposition of THIS Charter's proposed solution? For example, the proposed Solid charter is addressing a problem that has lots of incumbent solutions. Investing in yet another alternative to Twitter or Facebook would be expensive and probably doomed, unless there was some valuable, unique, and plausible techno-business model. W3C needs to make similar considerations.

• Track actual success -- do the WG's solutions REALLY solve the problems? It's fine to invest in long-shots if the investment is small and the potential payoff is huge; it's not OK to keep doubling down because you's already invested so much (sunk cost fallacy). So RE-charter decisions should be a rigorous as charter decisions. Or more so, since after 3 years or so a WG should have created concrete evidence that have developed something that improves the web experience for some set of real users.