Skip to content

Add support for authorized process experiments #1187

Open

Description

@ianbjacobs

The Process Document includes provisions that govern its evolution but does not make it easy to experiment with temporary alternatives to operational process. In order to increase W3C's agility and ability to experiment, I propose that the Process Document include provisions that enable the AB to authorize process experiments.

I have discussed this with the AB and have drafted a proposal for an experimentation process for discussion within the Process CG.

Activity

  1. added
    Agenda+Recommends to the Chairs that this issue or pull request be discussed at the next meeting
    on Sep 8, 2026
  2. frivoal commented on Sep 25, 2026

    @frivoal
    Collaborator

    I wonder if we could start by experimenting with experimenting :)

    Even before adopting extensive process rules to make process-overriding experiments possible, it seems to be we can largely do experiments without the special provisions.

    Here's how it would work:

    • Design experiments as Process appendices. One per experiment. We can call them something like appendix Z.1, Z.2, Z.3, etc.

    • Have each experiment appendix start with an intro sentence roughly like this:

      This section is a process experiment: the rules defined here normatively override the normal provisions of the Process, but do so only temporarily. This experiment is valid for 1 year, counting from its initial publication as part of a formally adopted Process. At the end of this period, the provisions of this section become void, and the normal rules of the Process apply. This experiment is also limited in scope: its provisions only apply to the Bubblegum Working Group, only when the chair is wearing a Hawaiian shirt; in any other context, the normal rules of the Process apply.

      Then, follow with whatever experimental provisions we want to be part of the experiment.

    • Re-publish the then current Process as is, except for the addition of this new experimental Appendix. This involves an AC Review, which can be kept at its minimal allowed duration of 28 days.

    If all goes well, starting an experiment is only one week slower than the 3 weeks notice period envisioned in #1189. And arguably, we can even start faster than that approach, because this approach can be used right now, while experiments done based on #1189 need 3 weeks on top of adopting #1189 itself, which has not been done yet, and may itself take a while, given that it involves an AC Review (which could take a little while: given that these provisions are quite open-ended, some back and forth with the AC may be needed.)

    Of course, there is a risk that an experiment done this way would be formally objected to, and that could considerably slow the start of the experiment. But thanks to the time and scope limitations, and if the fact that its an experiment, the motivation for the experiment, etc, are well explained to the Membership, we can hope that the likelihood of formal objections will be quite low.

    As an extra benefit, since the experiments are published in the Process itself, they are readily discoverable.

    If we run a few experiments that way, we may also learn more about what the AC wishes to know about proposed/concluded experiments, and that could help refine the terms of #1189, to be adopted later after we get the hang of this.

  3. ianbjacobs commented on Sep 25, 2026

    @ianbjacobs
    ContributorAuthor

    Hi @frivoal,

    Thank you for the concrete proposal. I appreciate having two proposals to share with the AB, and I'd be happy to work with you to align them as much as possible (review/notification window, experiment time limitations, scope, etc.) so that the AB can focus on the main material difference: whether the AC can formally object to the start of an experiment (via the AC review of a proposed process document), or whether they can simply appeal it. The AB can then make a decision reflecting how much agility they feel they would need.

  4. frivoal commented on Sep 26, 2026

    @frivoal
    Collaborator

    My proposal here is not necessarily in opposition to the one in #1189. It can be preliminary to it.

    The main point is that we do not need to set up new rules in order to do experiments, we can do experiments with the powers we already have. New rules can bring additional flexibility or additional constraints, but we don't need new rules to start. If we have some experiments ready, we can roll them out right now.

    As such, I am not sure there's much that needs to be aligned between the two approaches, because my approach does not have any rules beyond what's in the Process already. It's merely an observation that that is sufficient to run experiments.

    In short, I would characterize it this way:

    • The Proposal for Process Experimentation #1189 approach seeks new powers for the AB to do experiments, and in exchange for making the experiments not subject to FOs, it seeks to offer various levels of guarantees and guardrails.
    • My suggestion observes that we existing powers, experiments can already be run. The guardrails are build it into the existing Process, in the form of an AC Review and potential FOs. In order to avoid FOs, the AB would be well advised to uphold similar practices as those required by Proposal for Process Experimentation #1189 (explaining what the experiment is for, identifying hypotheses tested, documenting outcomes…), but these would be socially enforced by the AC Review rather than procedurally enforced.

    Even if we do eventually want a specialized rule about how to run experiments, I suspect we're more likely to get the rule right, and to get broad support from the AC for doing it, if we've already run a few experiments under the existing Process, can demonstrate we know how to run these well, and can justify the extra powers being sought through the challenges observed in practice of running experiments under the old Process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Agenda+Recommends to the Chairs that this issue or pull request be discussed at the next meeting

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions