diff --git a/main.jsx b/main.jsx index 52707dd..45acb9d 100755 --- a/main.jsx +++ b/main.jsx @@ -14,18 +14,19 @@ function Home() {

- WinterCG is a W3C community group that aims to achieve some level of API - interoperability across server-side JavaScript runtimes, especially for - APIs that are common with the web. This is done by working on a{" "} + WinterTC (TC55) is an Ecma International Technical Committee that aims + to achieve some level of API interoperability across server-side + JavaScript runtimes, especially for APIs that are common with the web. + This is done by specifying a{" "} “minimum common API” {" "} - of web APIs that such runtimes should support, as well as by + shared with the web that such runtimes should support, as well as by collaborating with web standards groups (WHATWG, W3C...) for new web - APIs and changes to current web APIs. We also work on proposals to add + APIs and changes to current web APIs. We also publish standards to add new interoperable server-side APIs.{" "}

- The WinterCG is currently working on various efforts to improve + WinterTC is currently working on various standards to improve interoperability across server-side runtimes:

@@ -96,20 +97,34 @@ function Faq() {
- -

What is the WinterCG?

+
+
+

What is WinterTC?

- The Web-interoperable Runtimes Community Group (WinterCG) is a - community of people who are interested in interoperability across - server-side (Deno / Node.js) or edge JavaScript runtimes (Cloudflare - Workers / Deno Deploy), especially for Web Platform APIs. + The Technical Committee on Web-interoperable Server Runtimes + (WinterTC) is a community of people who are interested in + interoperability across server-side (Deno / Node.js) or edge + JavaScript runtimes (Cloudflare Workers / Deno Deploy), especially + for Web Platform APIs.

- The WinterCG is organized as a W3C Community Group. This gives the - group access to the W3C's vast infrastructure and its IPR policy - work. This is the same type of community that the WICG is organized - in. + WinterTC is organized as{" "} + + Ecma International + 's Technical Committee number 55 (TC55). This gives the group + access to Ecma's vast infrastructure and its IPR policy work, as + well as the ability to publish standards. This is the same type of + committee as{" "} + + TC39 + , which standardizes the JavaScript language.

@@ -119,23 +134,23 @@ function Faq() {

- The ultimate goal of the group is to promote runtimes supporting a - comprehensive unified API surface that JavaScript developers can - rely on, regardless of whether their code will be used in browsers, - servers, or edge runtimes. + The ultimate goal of this committee is to promote runtimes + supporting a comprehensive unified API surface that JavaScript + developers can rely on, regardless of whether their code will be + used in browsers, servers, or edge runtimes.

- It is another goal of WinterCG that runtimes with needs for + It is another goal of WinterTC that runtimes with needs for capabilities beyond web platform APIs, in particular server-side and edge runtimes, still have unified surfaces.

- The members of the group want to provide a space to better + The members of the committee want to provide a space to better coordinate between server-side implementors, as well as with browser vendors, on how to best achieve this interoperability.

- It is not explicitly a goal of WinterCG to promote such a unified + It is not explicitly a goal of WinterTC to promote such a unified API surface for other JavaScript environments, such as embedded applications. However, the results of our work could be useful to such environments nonetheless. @@ -151,9 +166,9 @@ function Faq() {

- We want to provide guidance and documentation on how server side - runtimes can best implement Web Platform APIs and to what extent - they could deviate from browsers. + We want to specify and document how server side runtimes can best + implement Web Platform APIs and to what extent they could deviate + from browsers.

We want to provide feedback to spec authors of Web Platform APIs @@ -162,8 +177,8 @@ function Faq() { specifications.

- We want to develop and incubate new APIs that, although they might - be too powerful for the Web Platform or not fit within its security + We want to develop and specify new APIs that, although they might be + too powerful for the Web Platform or not fit within its security model, would still be a great fit for server-side runtimes and would be part of a comprehensive unified API surface for such runtimes.

@@ -208,10 +223,10 @@ function Faq() { specifications. If we think a new web platform API is needed, or if we think an existing spec needs changes, the goal is always for that change or addition to be developed in an existing venue (such as - WHATWG or W3C). WinterCG will publish requirements on what those + WHATWG or W3C). WinterTC will publish requirements on what those changes could be, and it will be up to that existing standards body to make these changes, possibly through members who are part of both - WinterCG and that standards body. + WinterTC and that standards body.

We do not want to create new server-side APIs that overlap with @@ -230,28 +245,72 @@ function Faq() {

- Does the WinterCG operate by consensus? + Is this the same as “WinterCG”?

- The group strives for rough consensus among contributors for changes - to work products. Instead of formal consensus, the editors for a - given work product make the judgement on whether a change is ready - for inclusion and has enough support from the group. The group - itself has a strict consensus policy outlined in the charter, which - is overseen by the group chairs. + We initially started our work of working on this cross-runtime + interoperability in May 2022 by creating the Web-interoperable + Runtimes Community Group (nicknamed WinterCG) under the W3C. We + chose to organize it as a W3C Community Group because it was open + for anyone to participate, without needing to be a W3C member. +

+

+ W3C Community Groups are set up to help people organize together, + but they can't publish standards. And as WinterCG matured, and our + goal expanded over time to include defining non-web APIs, it became + clear that we needed to form some working group or technical + committee, which can publish standards. Therefore, in December 2024 + we formed WinterTC (formally, TC55) as an Ecma International + Technical Committee. When WinterTC is fully set up, all WinterCG + work will move there, and then WinterCG will close. +

+

+ You can still be involved in WinterTC, but in order to become a + member of it, you need ... +

+

+ By their very nature, Ecma TCs are not as open as W3C CGs, requiring + participants to either belong to an Ecma member or be an invited + expert. However, keep the spirit of openness, we plan to invite + anyone who does not belong to an Ecma member as an invited expert, + so that anyone is free to participate.

+ { + // TODO: Uncomment and rewrite when we've figured out TC55's process. + // + //
+ //
+ // + //

+ // Does WinterTC operate by consensus? + //

+ //
+ //

+ // The group strives for rough consensus among contributors for changes + // to work products. Instead of formal consensus, the editors for a + // given work product make the judgement on whether a change is ready + // for inclusion and has enough support from the group. The group + // itself has a strict consensus policy outlined in the charter, which + // is overseen by the group chairs. + //

+ //
+ }
- -

Who controls the WinterCG?

+
+
+

Who controls WinterTC?

- The WinterCG is controlled by the community of people who are + WinterTC is controlled by the community of people who are working in it. The chair(s) of the group help moderate discussion and help guide the group towards consensus on proposed changes.

@@ -260,28 +319,51 @@ function Faq() { the following organizations:

    -
  • Azion
  • Bloomberg
  • Cloudflare
  • Deno
  • -
  • Fastly
  • Igalia
  • -
  • Netlify
  • Node.js
  • -
  • Shopify
  • -
  • Vercel
  • -
  • Suborbital
+
+
+ +

+ How can I participate? +

+

- The group is open to anyone who also shares the interest in using - Web Platform APIs outside of the browser. You can join{" "} + The work of WinterTC happens openly{" "} + + on Github + + , and most of the discussion and conversation around it happens in{" "} + our Matrix room + + . You're welcome to participate in both of them. +

+

+ Only members of WinterTC can participate in WinterTC meetings, + though. In order to be a member of WinterTC, you need to be a + representative of an Ecma member, or an Ecma invited expert. + However, if you don't fulfill those requirements and still want to + become a member, you can ask to become an invited expert{" "} + here - . You do not need to be a W3C member to participate. Community - group participation is free of charge. + .

@@ -291,20 +373,20 @@ function Faq() { } const DESCRIPTION = - "The Web-interoperable Runtimes Community Group aims to provide a space for JS runtimes to collaborate on API interoperability."; + "WinterTC is an Ecma International Technical Committee aiming to provide a space for JS runtimes to collaborate on API interoperability."; function Layout(props) { return ( <> - WinterCG + WinterTC - + @@ -321,11 +403,13 @@ function Header() { return (
- wintercg logo + wintertc logo -

WinterCG

-

Web-interoperable Runtimes Community Group

+

WinterTC

+

+ Technical Committee on Web-interoperable Server Runtimes +

); @@ -346,7 +430,7 @@ const LINKS = [ }, { name: "Charter", - href: "https://github.com/wintercg/admin/blob/main/charter.md", + href: "https://ecma-international.org/technical-committees/tc55", }, ]; @@ -357,11 +441,10 @@ function Links(props) {
  • {link.name} @@ -456,7 +539,7 @@ function Logos() { return (

    - The WinterCG includes participants from: + The work of WinterTC (and its predecessor WinterCG) has included participation from:

    {PARTNER_LOGOS.map(({ src, href, name, restrict }) => ( @@ -493,13 +576,7 @@ function Footer() {

    - Copyright © WinterCG. This work is licensed under the{" "} - - W3C Software and Document License - . + Copyright © Ecma International.

    ); diff --git a/static/cover.png b/static/cover.png index 125533e..2751348 100644 Binary files a/static/cover.png and b/static/cover.png differ