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]