Chartering checklist

[littledan]

To charter WinterCG to the point where it can produce standards such as minimum-common-api, we need to do the following:

• create a chartering checklist 🙂
• continue doing work as normal within W3C WinterCG while we consider this chartering, even if it takes a while.
• Scope: Are we happy with the limitation of TC55 to the minimum common API?
  • Several web standards people told us that they are uncomfortable with us forking specs, as it makes it harder to identify the source of truth. I think the simplest way to go forward would be to resolve to work in terms of PRs against upstream specs, working to introduce them in the right venues and trying (in principle) to land them (even if we know that some upstreams may not be interested). Is this the path we should take, or do people have other ideas for the way through?
    • Yes, the plan is to not fork specs, and instead work upstream. We may maintain within the wintercg GitHub org a branch to make PRs from, but this would not be developed under the TC39 IP policy, but rather per the procedures of the upstream spec..
  • Consider where to standardize runtime keys (currently excluded from TC55 scope). Idea: incubate in the CG, standardize in the LF package.json effort, WinterCG continues to make suggestions to the package.json folks.
  • Consider where to standardize custom WinterCG APIs, e.g., CLI and socket. Idea: These are just at the incubation stage, so are good to keep in the CG and not yet in the TC. When they become more mature, we can either found a separate TC or TG to standardize them, or expand the scope of TC55 at that time (making a TG within TC55 could require amending the TC55 scope, which can be approved by an Ecma GA). Note that some web standards people are uncomfortable with sockets in particular, as the web might eventually get a socket API (for privileged apps).
    • We want socket and CLI to be in scope. We will not claim that it will never be on the web platform, but we explain that we're designing it in a way that maybe could work for the web if permission/security stuff can be worked out, but also it's fine if they decide to go with something else.
  • If we will not have an Ecma CG in the near term, and if we want to take development out of W3C WinterCG, consider the possibility of all developmenting happening in TC55, TC39-style. This means broadening the scope from the beginning to include these topics like runtime keys and server-only APIs which extend beyond the minimum common API. Consider what this broader scope should be.
    • This is the tentative plan.
• Documentation
  • The website is inactive, and it’s the first place that the Ecma members went to try to understand our TC55 proposal. Make sure it is up to date and represents our current work. For example, list the various already-successful and ongoing efforts that have occurred (e.g., Response.json, runtime keys, AsyncContext).
  • State that WinterCG-compliance is not yet a thing, but that we’re trying to make it a thing with the minimum common API, but it also isn’t done yet. (This is an especially widely held misconception.)
  • update the website and all docs to standardize on “minimum common API”, not “common minimum API”, to avoid confusion (which apparently did occur)
  • document both WinterCG’s and TC55’s scope on the website, and the relationship between them, in a PR that we can put out for review in conjunction with future chartering. In particular, the CG has a broader scope than the TC.
    • There will be just one scope.
  • explain how we work with other standards, including the forking vs working upstream approach (see “scope” above, I prefer working upstream, initially in terms of PRs that we maintain but aren't yet landed)
• IPR and standards policy matters
  • (to @SaminaHusain) Ecma to share feedback from membership about TC55 with those working on chartering. (The membership gave their feedback to Samina, and not to me, with the understanding that it would be forwarded on, which it hasn't been yet. We should minimize how many times we ask people to repeat themselves.)
    • Samina had already sent @littledan Mozilla's feedback, and apparently no one else gave written feedback.
  • (to @gesa) determine whether the previously proposed mixed-venue model may still be possible, with W3C WinterCG working with Ecma TC55, due to a possible memorandum of understanding between the organizations enabling IPR licensing.
    • OK if this task is dropped, as we don't plan to take advantage of it.
  • Others in the group should give input to Aki on whether this path is desirable for us, at this point, or whether the possible MoU should be thought of as a possibility for other efforts.
    • We're not interested in the mixed model because it is too complicated and has already generated a lot of negative feedback.
  • (to @gesa) Look into whether Ecma can have some kind of CG, maybe based around the process that Jochen worked on in the past.
    • Not for a while; we shouldn't depend on this in the near term. This remains an area for further-out interest. We're proposing an all-TC model, with a broader scope.
  • If we go with an Ecma TC, propose invited expert procedures for the chairs to implement together with Ecma staff. While Ecma formally considers all IEs on a case by case basis, there is operationally a certain way that people are proposed to Ecma as IEs, and this is the procedure that we’d need to ensure allows sufficient inclusion and safeguards.
    • Probably something like what TC39 currently has, plus a Google form that gets sent to us when someone wants to request IE status, would be enough. @lucacasonato to discuss this with @SaminaHusain.
  • Clarify what W3C policy is on CGs, in particular whether standards can be developed there. Ideally come to some kind of consensus which includes @cwilso and @tantek, and which is consistent with how the WebAssembly CG works. This will help us understand which of WinterCG’s work we need to move out of the CG, and which can stay (whether in the event of doing everything in W3C, or with a hybrid MoU model)
    • @cwilso clarified below that we cannot develop standards in CGs.
  • Figure out which work of the current CG needs to be relicensed to Ecma, and which work should not be relicensed and submitted upstream right now instead.
• Venue: consider carefully whether to host this effort within the W3C or Ecma, and make a final decision
  • Explain the reasoning clearly somewhere, and distribute this explanation widely, including with all chartering attempts. Initial document for standardization #75
  • Survey the current active WinterCG participants, and figure out whether they are members of the W3C or Ecma, or whether they would join if we worked formally within that venue. Assemble a list of proposed invited experts, and discuss that with the standards body management to understand whether this is practical.
  • Investigate whether there are any actual participants who find that they would be enabled to participate based on the choice of one or the other venue. Note that web standards folks have argued that collaboration with other web specs would be easier from the W3C side.
  • I (Daniel Ehrenberg) am neutral on the question of which venue we go with, and prefer that others make the call. In my experience, though, organizational boundaries have not been an issue for web specs and TC39, as long as technical matters and issues between individuals can be worked through.
  • In past discussions, several WinterCG members (not me) expressed a preference for Ecma, due to an emerging critical mass of Ecma members who engage in WinterCG, and being happy with Ecma’s inclusion, as seen in TC39.
  • Plan: Write up documents on all of this and present it to WinterCG for final conclusion 2024-09-19
• Internal communication
  • solidify who is the subgroup of WinterCG that wants to work on chartering, and get their emails
    • @CanadaHonk already added people who expressed interest to the recurring chartering meeting
  • create a meeting (recurring?) to follow up on chartering among the people most interested
    • @CanadaHonk created an every-two-weeks chartering meeting
  • create a communication channel (Matrix? Frequent enough emails or GitHub threads?) to stay in touch, hopefully allowing us to minimize the need for meetings
    • We will just use the main WinterCG Matrix channel and issues here

Timeline: Unfortunately, it’d be best if we had much of this ready relatively soon, in the next couple weeks. Some upcoming events:

• W3C TPAC starts September 23rd, and we want to be able to discuss WinterCG’s plans there. This is a big conference with a lot of people who we want to collaborate with.
• The next Ecma ExeCom meeting is October 22nd, and the agenda needs to be set by October 1st, including supporting documents. It would be ideal if we could submit any proposal by then, so that Ecma can have sufficient time to discuss it.

I will not not be available this month to perform these tasks, but I will be available to do reviews. Let's post references to all relevant content/actions here, so it's easy for everyone to keep track of.

[Edit: Updated based on the meeting #74]

[cwilso]

Happy to advise. I do want to say, with respect to "Clarify what W3C policy is on CGs, in particular whether standards can be developed there" the answer is clearly "no" - community groups cannot create or maintain REC-track documents. That is the realm of Working Groups (which have a much higher requirement for consensus and process), and it absolutely should not be implied that any CG can "create a standard". That would set a bad precedent at W3C.

Although it is possible to use a CG to incubate work that feeds into a W3C WG (we do this in a number of places, like WebAssemblyCG -> WAWG, or ImmersiveWebCG->IWWG), the transition from incubation in a CG to consensus-spec-development should also really ensure it has a frictionless IPR management path. That works inside W3C from CG->WG (due to section 9 of the CG CLA), but doesn't work to go outside W3C today (it would need an FSA signed for each migration from CG).

In short: moving this work to ECMA now would require a bit of work to ensure the IPR commitments are managed, but that's not the end of the world; however, I would STRONGLY recommend that WinterCG not be considered "where the standard is developed" in the future; that should either be a WG or elsewhere (like ECMA) that is designed for that work.

[andreubotella]

This thread hasn't been updated in some time, but progress has been happening in the Matrix room, as well as in chartering meetings and conversations with various folks at ECMA. This is the current status:

• We are hosting this effort in Ecma, as TC55. Once this TC is formed, WinterCG will be dissolved.
  • Since @CanadaHonk cannot be a co-chair of this TC because they are an ECMA invited expert and not part of a member company, I (@andreubotella) will be co-chairing along with @lucacasonato.
  • We got negative feedback when presenting the proposal in the October ExeCom, which we have now addressed. We will be submitting it to be approved on the Ecma General Assembly on December 11th-12th.
• TC55 will be standardizing the minimum common API, as well as server-side-only APIs that don't overlap with the web platform, which currently consist of the Sockets and CLI APIs.
  • The Runtime Keys proposal will be moved to the OpenJS Foundation, perhaps as part of their package.json research.
• TC55 will not develop new web specifications, or changes to existing web specifications. It will also not fork or monkeypatch them, or even have development forks. Instead, it will collect and publish requirements on the needs of server-side runtimes from those standards. It is expected that members of TC55 that are also members of the relevant standards body will make those changes.
  • The Fetch specification fork will be archived, and the work will continue as contributions to the upstream WHATWG spec.
  • The Web Crypto Streams proposal will be moved to WICG, where it will continue to be incubated. Eventually it is expected to be moved into the Web Applications Security Working Group, where the Web Crypto API spec is now published.
• I made a PR to update the WinterCG website to reflect this new scope: Update website to reflect the new scope www#46