W3C Process breakout

We only have an hour today, so let’s focus on our plans for TPAC.

We need to know the who and the what:

Who we’ll talk to in Kōbe,

and what questions we’ll ask them?

Let’s talk about what’s in the Process so we can figure out who to talk to.

When people talk about “the process”, they usually mean “how we work on specs and move them along the REC track.^*

Folks think it includes many things that it doesn’t, like:

• particular details of the work modes and decision policies of the groups they participate in,
• requirements of tools that they use in their groups,
• oft-emulated behavior of long-term participants,
• best practices defined in the Guide or elsewhere,
• etc.

The process is smaller than people think it is.

And yet it defines so much more than just how to make specs.

It’s the “kitchen sink” of W3C’s governing documents.

It defines

• W3C Members
• The W3C Team
• The Advisory Committee
• The Advisory Board
• The Technical Architecture Group

& their roles, powers, and responsibilities.

It defines WGs and IGs, their lifecycles, and how Member representatives and Invited Experts may participate in them.^*

It defines

• how meetings are held,
• how decisions get made,
• what we mean by consensus,
• Formal Objections and how to resolve them.

It also defines processes for

• how we communicate with each other and with the outside world,
• setting up liaisons with other organizations,
• etc., etc., etc.

To oversimplify, it defines

• the structure of W3C’s technical programme,
• and the process for producing and maturing specifications within that technical programme.

These are the what.

So let’s ask people at TPAC about both of these things.

The structural parts and the procedural parts.

The who depends on which part.

Let’s ask

• Anyone in or formerly in governance roles, especially AC reps, about the structural stuff,
• and WG participants, especially chairs, editors, and team contacts, about the spec maturation process.

Let’s try to keep the following in mind as we come up with our TPAC questions.

W3C is Member-led.

We should look for opportunities to strengthen our commitment to being Member-led.

Ambiguity in the process, its overall complexity, and tooling issues have all lead chairs and editors to overly lean on their Team contacts.

But Team contacts’ availability and capacity is arguably W3C’s least scalable resource.

If we want to continue to take on more work in more areas, we need to look for ways to improve our resilience by easing the burden Team contacts bear.

We should eagerly search for opportunities for simplification.

We should seriously consider splitting the document up.

It should be easy for a W3C participant, whatever their role, to understand the requirements of their role or task at hand, simply by reading the process themselves.

Things that go beyond the “floor” of process requirements (such as best practices and other recommendations) ought to live in supplementary material such as the Guide.

A generous application of hypertext can make it easy to find such supplementary material while reading the process document.

We should consider defining some things in the process. Some that come to mind:

• Incubation (Member-only link)
• TAG design review
• TPAC
• Community and Business Groups

Thank you.