Modularize the process

[ianbjacobs]

As part of a larger project of revisiting the W3C Process, simplifying it, and reducing the overall number of normative requirements, I would like to start by modularizing it. My hope (to be verified) is that it will improve usability and make it easier to experiment with process improvements (see also #1187 on experimentation). I propose work within the Process CG on an initial modularization that merely reorganizes the material (including changes approved since Process 2025) but otherwise does not change normative requirements. Once modularized, and with AB authorization to experiment, we would start to improve priority pieces (whatever module they are part of).

At a high level I propose these modules:

• Participation, which includes all policies, decisions and disputes, meetings.
• Document and group lifecycles
• Governance, which includes AC, AB, TAG, staff, technical agreements with other bodies, evolution of the Process, and experimentation.

After the initial modularization I hope to be able to work with the AB and Process CG on experiments as well as other simplifications to the Process. These discussions would also involve the W3C Systems Team (and potentially open source projects) to define, prioritize, and implement tools to make life easier for editors, group, AC Reps, and others.

I realize modularization will raise a number of topics that we'll discuss in the Process CG, including the number of documents, crosslinking, maintaining anchors, and so on.

[frivoal]

A technical obstacle to doing this is bikeshed current inability to produced modularized documents. This is in the process of being fixed, and I understand that the intended ETA is sometimes late this year, but it hasn't happened yet. cc: @tabatkins, in case you have something to add.

This is not strictly needed, in the sense that modularization could be done regardless of tooling, but the effort needed to get there varies significantly depending on whether we need to switch toolchain altogether, which I would rather not do.

[dontcallmedom]

If the modules are managed as separate documents (rather than a multipage document), I'm not sure there needs to be any specific support from bikeshed.

[alicmarko70-dev]

Ok Agree

[frivoal]

If the modules are managed as separate documents (rather than a multipage document), I'm not sure there needs to be any specific support from bikeshed.

That is true, but this would have downsides. Mainly, the various modules would have mutual normative cross references, making co-evolution more complicated. The proposed modularization is largely based on dividing by intended audience, which is not the same as trying to find functionally independent subset. If evolving a concept calls for making changes in several modules, we've made life more complicated, not less. This would not be a problem with a multi-page document.

Also, we probably want to keep undated links with an anchors (sections, definitions) working, which implies maintaining a giant table of redirects from the index document to the other modules. In the case of a single multi-page document made with bikeshed, bikeshed can help with that (at least in theory, I don't know how well that would work since the feature is still in the future). Manually maintained separate documents means that would be a manual endeavor, and not one I'd look forward to.

[ianbjacobs]

Here is a draft modularization.

[tidoust]

Leveraging Ian's draft modularization proposal, I prepared a user script to show how that modularization could look like in practice. The user script is available in a gist.

Installation steps

• If not already done, install a browser extension that lets you install user scripts. I use Greasemonkey for Firefox, but any other similar extension should work.
• Navigate to the user script gist.
• Click on the "Raw" button. Your extension should offer to install the user script. If it does not, I guess you'll have to copy and paste the script and install it manually.
• Navigate to the draft W3C Process Document (or refresh the page if it was already in one of your tabs).

Once installed, the user script runs when you navigate to the draft Process document. It adds a modularization menu before the table of contents that allows the user to choose a module view. When a module is selected, the sections it contains are shown and the rest gets hidden.

If a module contains section 6.1.1, then the 6 and 6.1 headings are rendered as well so that the outline continues to make sense. The modules are the ones that Ian drafted, replacing the "Wrapper" module with an "End matter" one, as the "Wrapper" module was more envisioned to be an introductory document that links to the other modules.

Here's a screenshot of the modularization menu:

Known current limitations:

• When a module is selected, various internal links will no longer work because they point at terms defined in sections that are now hidden.
• When a module contains, e.g., section 5.1 but not section 5, the title of section 5 is still displayed so that the structure continues to make sense. However the hanging paragraph after section 5 and before section 5.1 is no longer displayed.
• The script does not make any attempt at re-ordering material as suggested in Ian's proposal, not to confuse readers. This re-ordering may be useful or needed if the Process document effectively gets modularized.
• The user script is scoped to the draft Process document for now. The menu won't appear if you browse the published Process document.

Overall, this is just a proof of concept meant for exploring the modularization.

Some questions that arise are:

• Would providing views be useful and good enough?
• Should modules be different and/or contain different sections?

[frivoal]

Here is a draft modularization.

The one thing where I hesitate is "Chartered Groups". I think far more people need to know what the various kinds of groups are, and how to participate in them than need to know how to charter new ones. So 3.4.0 (i.e. the part of 3.4 that is before 3.4.1) and maybe 3.4.2 could be in Module II, and maybe we could separate the remainder of 3.4.* from 4.*, as I suspect the audience are decently distinct.

[ianbjacobs]

@frivoal, I have made your suggested changes to the draft modularization. Thanks!