Clarify subgroups can have different process rules (e.g. WASI)

[codefromthecrypt]

I only today found that the proposal rules for WASI are different and arguably incompatible with the rules of WebAssembly.

Notably to advance to stage 4 is different in ways most notably adoption

• WebAssembly requires two or more "Web VMs" to implement
• WASI requires two "independent implementations" and two "cloud providers", as well Windows, Linux and MacOS support

I only noticed this in the recent kv spec, and I'm not really sure where the rest of the process is defined.

Since WASI is a subgroup, the above implies that subgroups can have different rules. Since WASI hasn't produced a web standard, it is I suppose also relevant to clarify subgroups may create their own non-web standards track standards.

There's a larger question of why WASI is a subgroup instead of independent, and why it is even in W3C, but please don't get distracted by this. The focus of my issue is to make the process here transparent:

I think it is reasonable to have process documentation clarify that subgroups are free to make their own process. I was shocked and I think I wouldn't have been if this were transparent vs a tacit understanding. I think this shouldn't be something left unsaid, in other words, as people make long term decisions based on processes.

[codefromthecrypt]

ps feel free to move this if you think it should be in the repo that defines proposal process. I raised it here because I'm not sure where things about subgroups should be.. that the proposal process different is a side-effect of a subgroup having a different standards culture. https://github.com/WebAssembly/meetings/blob/main/process/phases.md

[penzn]

Good question. I think the reason why this discrepancy exists is because WASI subgroup is not producing additions to Wasm standard, which is why it is OK for it to have different rules. Other examples of this are Component Model and C API. AFAIK W3C rules allow for production of artifacts outside of core spec under somewhat relaxed process, but I am not sure to what extent this applies to official subgroups.

[conrad-watt]

Yes, the Community Group can curate documents that are outside the scope of the W3C-published standard. The C API and tool conventions repos are other examples. I agree that we should clarify (probably in our subgroup document) that subgroups can have a process for developing these documents that is separate from the main Web standards track, although I think it should already be somewhat clear that the main CG process only applies to things that will end up being considered by the WG for W3C publication, given phase 5.

EDIT: it seems that WASI's subgroup charter explicitly calls out that their process takes inspiration from the main CG process but doesn't follow it directly. I'd still be fine with adding a note in the main subgroup document.

[codefromthecrypt]

I didn't realize Component Model was not standards track, so you headed off my next question @penzn, thanks.

I think in general folks should refrain from using "standard" jargon in these subgroups, and lean into words like "specification" especially when there is a process around them that is squinty similar to that which results in a standard with a capital S. In marketing it is very easy to mistake every specification done inside the wasm umbrella as a standard even if it is easier for people to understand things like libraries or ad-hoc advice aren't standards. Make sense?

[penzn]

@codefromthecrypt, actually, I have to walk that back. Even though Component Model introduces things outside the spec, it is a proposal. The difference from the other examples is that it tries to add another specification on top of core spec, that would be standardized. It would have to follow the same path to get to phase 5 as everything else. What was the question you had? 😃

[codefromthecrypt]

@penzn my question was if component model was aiming to be a web standard or not (REC), considering its main user WASI isn't aiming there. Since it seems it is I guess it may be meeting both requirements... e.g. the browser side and the cloud side!

Ideal case, is we could have a landscape doc where folks know what is going to be a REC and what never will. Sounds right now that basically WASI is a special case, and other things "proposal" are proposals to end up in a standard.

FWIW I don't think REC/standard does anything magical to make specifications better, but it is clarifying about process.

[sunfishcode]

The Wasm CG currently maintains three documents: the core spec, the JS API, and the Web API. The Wasm CG process has proposals, which can either add new documents, as the Component Model proposal would, or modify existing documents, as for example the Multiple Memories proposal would.

The Subgroups (SGs) are forums. SGs can be associated with zero (eg. Debugging), one (eg. Stack Switching), or even multiple (eg. SIMD) proposals at any given time. Proposals do not need to be associated with Subgroups; most are not. Subgroups' main characteristic is that they hold meetings.

WASI is a Subgroup. It currently has zero CG-level proposals. It does have the beginnings of its own process for evaluating and accepting API proposals, however it's not yet determined exactly what the advanced stages of the process will look like. "The specific process in Phases 4 and 5 will be determined when we have a proposal ready for them."

When an API proposal does advance to that point, we'll need to have CG-level conversations about what document(s) such an API proposal might make sense to be published in, and what the process should be. WASI could potentially even produce documents which could eventually become W3C RECs, through a few different paths:

• WASI is working on a very diverse set of API proposals. Some of these in their current form wouldn't make sense to implement in browsers, but others may someday make sense to implement in browsers. This would need a process, which hasn't been discussed anywhere yet, but it's conceivable.
• At the same time, the W3C is about more than just browsers. Consider the W3C standards for ActivityPub or IoT, which are both RECs. It's too early to say if something like that makes sense for WASI, but it's also too early to rule it out.

I agree that we don't have a lot of clarity. It's partly because Wasm is a new technology which has some major differences from many of the technologies it tends to get compared with, and we're all still figuring it out. Traditional boundaries like "language vs. library", "syscall vs. library call", "Web vs. non-Web", and more, are all facing new questions. There is no pre-existing category that WASI seems to fit into.

WASI requires two "independent implementations" and two "cloud providers", as well Windows, Linux and MacOS support

Those are the phase-4 requirements that wasi-kv has chosen. What WASI as a whole says is that each proposal choses its own phase-4 acceptance criteria, and the criteria gets approved by the WASI SG. At the same time, that same document says the process for phase 4 is not yet defined yet.

[conrad-watt]

The Wasm CG currently maintains three documents: the core spec, the JS API, and the Web API

Just to add, documents like the tool conventions repo are also maintained by the CG, and we've taken votes on things like the safe C API before. I agree that the final form of WASI doesn't have to be like one of these documents, but I think the high-level point is that it would be business as usual for the CG to host the development of WASI even if it were never to aim for W3C publication (edit: and AFAIU it currently isn't, notwithstanding @sunfishcode's point about the earliness of the whole effort right now).

I think the point of confusion in the OP is that the WASI subgroup is reusing the "phase" language for their own internal "API proposals", which are not CG-level proposals. I personally don't see a major issue with this since we have the canonical list of CG proposals here, but it might be worth a sentence of clarification somewhere.

[sunfishcode]

Closing, as the original question here appears answered. Documentation about subgroups and process lives here, so if anyone has any further questions or concerns, please raise them in the associated issue tracker.