This is an FAQ for people who may not yet even be involved in the W3C at all — but also for W3C Working Group participants (and even Working Group Chairs) who may not be familiar with all intricacies of the W3C process.

If there’s a problem you want to solve for people using the web — then, here’s what the W3C can do for you:

• You can use W3C services to document a web problem that needs solving (and use cases/requirements)
• You can use W3C services to propose a new web feature that solves a problem (use cases/requirements)
• You can use W3C services to publish a spec for a new web feature
• You can get a w3.org URL for your spec, and autopublish updates to it at that URL
• You can get the strongest-possible Royalty-Free Licensing Commitments for your spec
• You can get your spec formally endorsed by the W3C
• You can make a “living standard” from your spec

If there’s a problem you want to solve for people using the web, here’s how you can document it:

1. Open the Problem template form in the issue tracker of the W3C Strategy team’s GitHub repo.
2. Fill out that form, succinctly describing the problem you want to solve, along with some use cases (example).
3. Submit that form. That will create a new issue in the W3C Strategy issue tracker.
4. Share the link to your issue (on social media and in other places), and encourage others to comment.

The presence of that issue in the W3C Strategy issue tracker will cause it to shortly thereafter get included in the W3C Strategy Funnel, and may even eventually lead to a W3C Working Group being formed to tackle the problem.

In parallel with (or even prior to) that, you can create a WICG proposal or a new CG, and work with others to:

• refine the problem description together
• create a “Use Cases and Requirements” Draft CG Report, and add a link to that on the CG Reports page

If there’s a problem you want to solve for people using the web and you have a proposal for a new web feature which will solve that problem — here’s how you can propose it:

1. Open the Exploration template form in the issue tracker of the W3C Strategy team’s GitHub repo.
2. Fill out that form, succinctly describing the new web feature you’d like to propose.
3. Submit that form. That will create a new issue in the W3C Strategy issue tracker.
4. Share the link to your issue (on social media and in other places), and encourage others to comment.

The presence of that issue in the W3C Strategy issue tracker will cause it to shortly thereafter get included in the W3C Strategy Funnel, and may even eventually lead to a W3C Working Group being formed to work on it.

In parallel with (or even prior to) that, you can create a WICG proposal or a new CG, and work with others to develop a detailed Explainer for your feature proposal, and add a link to that on the CG Reports page.

If you have a solution in mind for a problem you want to solve for people using the web, you can create a spec that defines a new standard web feature to solve that problem for people — and then, the steps you can take for publishing your spec using W3C services depend on what you want to get:

1. If you want to get W3C spec hosting in the quickest/most-lightweight way, first create a a new CG.
2. If you want to get WICG spec hosting, first create a WICG proposal.
3. If you want to get a https//wicg.github.io URL, follow the Evaluation step in the WICG proposal process.
4. If you want to get a https://w3c-cg.github.io/ URL, request a GitHub repo and publish a Draft CG Report.
5. If you want to get a https://www.w3.org/community/reports/ URL, publish a Final CG Report.
6. If you want to get a https://www.w3.org/TR/ URL, create a Working Group and publish a FPWD.
7. If you want to get Royalty-Free Licensing Commitments, publish Snapshots.
8. If you want to get a formal endorsement from the W3C and its Members, publish a Recommendation.

You can publish specs in two different areas of the w3.org site: https://www.w3.org/community/reports/ and https://www.w3.org/TR/.

https://www.w3.org/community/reports/ URLs are for Community Group Final Reports. So to get a https://www.w3.org/community/reports/ URL for your spec, you need to follow these steps:

1. First get a Community Group created for your spec.
2. Publish a Final Community Group Report.

https://www.w3.org/TR/ URLs are for Working Group specs. So to get a https://www.w3.org/TR/ URL for a spec, you need to follow these steps:

1. First get a Working Group created for your spec.
2. Publish a First Publish Working Draft (FPWD).

You can use autopublishing to update Working Group specs at https://www.w3.org/TR/ URLs. And while there’s currently no similar mechanism for updating CG Reports at https://www.w3.org/community/reports/ URLs, Draft CG Reports at https://w3c-cg.github.io/ URLs are auto-updatable using GitHub Pages.

You can secure Royalty-Free Licensing Commitments for a Working Group spec by following these steps:

1. If you don’t already have a Working Group, then first get a Working Group created created for your spec.

2. Publish a FPWD into the w3.org/TR spec-publication space — to trigger the first Exclusion Opportunity.

3. Continue to autopublish updated Working Drafts into the w3.org/TR spec-publication space and to communicate closely with implementors and others to get the details right.

4. When your group believes a spec is ready to be fully implemented — and ready to be thoroughly tested (by having a suite of tests to test against) — then, follow the process to get the Working Draft warning label dropped from a spec, and to get the CR label added, and publish the first Snapshot for it.

   60 days after you publish that first Snapshot, you’ll have secured Royalty-Free Licensing Commitments from all participants in your Working Group for all normative features defined in that Snapshot.

For information on getting commitments for a Community Group Report, see the CG Patent Policy section.

You can make your Working Group spec a “living standard” by first securing RF Licensing Commitments; then:

1. Continue working with implementors and other contributors, and on tests — and, as you iteratively refine the spec contents — autopublish the updated contents as “CR Drafts” into the w3.org/TR publication space.
2. At some regular cadence (say, once every 6 months) and if any substantive spec changes were made during that time period, republish a new Snapshot so that a new Exclusion Opportunity will be triggered.
3. As you receive bug/issue reports and pull requests for your spec over time, continue to perpetually maintain it by repeating steps 1 and 2 above over time.

For information on Community Group “living standards”, see the CG “living standards” section.

You can get your spec formally endorsed by the W3C — that is, get it labeled as a W3C Recommendation — by first securing RF Licensing Commitments for your spec; then:

1. Assess whether the spec has multiple implementations (or is otherwise deemed sufficiently implemented).
2. When your group can show that the spec has multiple implementations (or is otherwise deemed sufficiently implemented), do an Advisory Committee review to get formal endorsement from the W3C and its Members.

Even if you’re not a Working Group participant (and even if your employer’s not a W3C Member), you can do a lot:

• You can get a W3C account
• You can get a “W3C member” logo in your GitHub profile
• You can get and make Royalty-Free Licensing Commitments
• You can document web problems that need solving (and use cases/requirements)
• You can propose new features that solve web problems
• You can create WICG incubation proposals
• You can publish specs for new web features
• You can get a w3.org URL for your spec
• You can get a WICG URL for your spec
• You can review specs
• You can raise issues against existing specs
• You can contribute PRs against existing specs
• You can access W3C mailing lists
• You can freely join W3C Community Groups
• You can create W3C Community Groups

Yes. Here’s how:

1. Go to https://www.w3.org/account/request/ to create your W3C account.
2. Go to https://www.w3.org/users/myprofile/connectedaccounts/ to connect your GitHub and W3C accounts.

The W3C logo will then show in the Organizations part of your GitHub profile — indicating you’re a member of the W3C GitHub org (even if you’re not part of any Working Group, and even if your company’s not a W3C Member).

Yes. For Working Group specs, the W3C’s automated contribution-management mechanism allows you (in some but not all cases) to make RF Licensing Commitments for any substantive change you contribute by way of a pull request — even if you’re not a participant in the Working Group, and even if your company isn’t a W3C Member.

For information on getting commitments (for non-Working-Group specs), see the CG Patent Policy section.

Yes. If there’s a web-user problem you want to solve, you can document it (along with use cases/requirements).

Yes. If there’s a problem you want to solve for web users, you can propose a new web feature to solve it.

Yes. You can publish a spec even if you’re not part of any Working Group, and even if you’re not a W3C Member.

Yes. Even if you’re not part of any Working Group, and even if you’re not a W3C Member, you can get a w3.org/community/reports URL for your spec — though you’ll first need to have a W3C Community Group.

To instead get a w3.org/TR URL for your spec, you’ll first need get a Working Group created for your spec.

Yes. You can get a wicg.github.io URL for your spec by first starting the steps for creating a WICG proposal, and then following the Evaluation step to get a repo set up for your spec.

Yes. The W3C strongly encourages and facilitates wide review — and seeks to provide the widest-possible opportunities for review from the widest-possible set of reviewers. Here’s how you can take part:

1. Find a W3C Working Group spec that you can review and comment on — by taking any of the following steps:

   • Go to the W3C News page or to public-review-announce archive and browse through the latest “Call for Wide Review” and “First Public Working Draft” announcements.
   • Subscribe to the mailing list to which all “Call for Wide Review” and “First Public Working Draft” announcements are posted — so you’ll get e-mail notifications whenever new announcements are made.

2. Review the actual spec, and raise issues or pull requests or post comments.

   Every “Call for Wide Review” and “First Public Working Draft” announcement has a link to an actual Working Group spec — and every Working Group spec has a link to the group’s W3C GitHub repo and issue tracker and/or a mailing list for comments. So, you can do any of the following:

   • Raise issues in the group issue tracker — for questions/comments, or for spec problems that need fixing.
   • Create a pull request with an actual spec patch — to propose changes you want merged into a spec.
   • E-mail the group’s mailing list — if you have questions/comments or find spec problems that need fixing.

Yes. Working Groups have W3C GitHub repos with issue trackers where you can raise issues with questions or comments on a spec — or when you find a spec problem that need fixing.

Yes. Working Groups have W3C GitHub repos to which you can submit patches you want merged into specs.

For substantive patches, an automated mechanism enables you (in some but not all cases) to make RF Licensing Commitments — even if you’re not part of any Working Group, and even if your company isn’t a W3C Member.

Yes. See the W3C mailing-list archives. All Working Groups do their work in public; they have mailing lists with public archives that you can read, and you are welcome both to subscribe to Working Group mailing lists, and also to post messages to the lists (with questions or comments, or to report spec problems that need fixing, etc.)

Yes. You can join any of the current 140+ Community Groups organized around specific technologies/topics:

1. Browse the sortable list of all 140+ W3C Community Groups (CGs) that currently exist.
2. Find a CG you’d like to join, and then on the homepage of that CG, press the Join this group button.

Yes. You can create a new W3C Community Group (CG) relatively easily.

Yes. If you create a new CG, you can make a request to get a https://github.com/w3c-cg GitHub repo for your CG.

W3C Community Groups (CGs) are open, self-organized groups that by design are unregulated by the W3C — for people to get together in and use without restrictions for any purposes they choose, including to develop specs.

Unlike Working Groups — which to join generally require your employer to be a W3C Member organization — CGs are open to all. You can freely join any CG you want to — and you can even create a new CG if you want to.

The WICG is a particularly special W3C Community Group specifically for incubating new web-platform features.

You can browse the list of 120+ active incubations, and you can even create a proposal for a new incubation.

See How do I propose a group? in the W3C Community Groups FAQ for a how-to on getting a new CG created.

You can potentially get licensing commitments for your Community Group spec in two different ways:

1. All participants who join your Community Group sign the W3C Community Contributor License Agreement (CLA) to indicate that they agree to royalty-free licensing for any contributions they themselves make to the spec (for example, through any pull requests that they themselves make which are merged into the spec).

2. When you publish a Final CG Report, a “commitments” page for that Final CG Report is created and announced to the CG. And on that “commitments” page is a button that CG participants or anyone can voluntarily push to sign the W3C Community Final Specification Agreement (FSA) — to indicate that they agree to RF licensing for the entire contents of that particular Final CG Report.

You can put the label “Draft Community Group Report” on any version of your CG spec you want — and publish that at any URL you want. You also have the option to publish it at a https://w3c-cg.github.io/ URL (using GitHub Pages) — after you’ve requested a w3c-cg GitHub repo for your CG.

You can automatically format the publish-ready spec in the expected “Draft CG Report” style by using support built into both the Bikeshed and ReSpec spec-processing/formatting tools.

You can also — if you’re a CG Chair — add a link for the published report to the Community Groups Reports page.

You can, at any time you want, get your CG spec published at a https://www.w3.org/community/reports/ URL with the “Final Community Group Report” label. You just need to open a pull request to add your formatted spec output to the https://github.com/w3c/cg-reports repo.

You can automatically format the publish-ready spec in the expected “Final CG Report” style by using support built into both the Bikeshed and ReSpec spec-processing/formatting tools.

You can also — if you’re a CG Chair — add a link for the published report to the Community Groups Reports page.

You can get a Working Group created when you have a spec that you want to publish at a w3.org/TR URL, and if you want to get Royalty-Free Licensing Commitments for the spec — with the bonus that you’ll also have an option to get formal W3C endorsement for your spec, if you want that.

It’s entirely possible to maintain a spec in just a Community Group or the WICG — or even with just a GitHub repo alone — without ever needing to have a Working Group for it. But here are the things you can’t do in a Community Group or in the WICG or with just a GitHub repo alone, and that you instead do need to have a Working Group for:

• You can get a w3.org/TR URL for your spec, and autopublish updates to it at that URL
• You can get the strongest-possible Royalty-Free Licensing Commitments for your spec
• You can get your spec formally endorsed by the W3C

You can get a new W3C Working Group created by following these steps:

1. Develop a spec for a new standard web feature.
2. Write a draft Working Group charter for a new W3C Working Group to work on your spec:
   1. Fork and clone the https://github.com/w3c/charter-drafts repo, and then within your local clone:
   2. Create a new foo-wg-charter.html (or whatever name) file by copying the W3C charter template.
   3. Fill out the parts of that template in your foo-wg-charter.html file.
   4. Save your foo-wg-charter.html file and use git add to add it to your clone.
   5. Push the foo-wg-charter.html file change to your fork.
   6. Open a PR to merge your foo-wg-charter.html file into the https://github.com/w3c/charter-drafts repo.
3. File a formal request that the W3C consider launching a new W3C Working Group based on your draft charter:
   1. Open the Charter development and review form in the issue tracker of the W3C Strategy team repo.
   2. Fill out that form, with a link to your draft-charter pull request from step #2 above.
   3. Submit that form.

That will create a new issue in the W3C Strategy issue tracker, where you can have a discussion about your draft charter with people from the W3C Strategy team and others.

From there on — if your request for a new W3C Working Group ends up being accepted — the logistics for the actual creation of the new Working Group will be handled by the W3C staff.

Anywhere you see Editor’s Draft, substitute Canonical Version, Up-to-Date Version, or Non-Obsolete Version.

A so-called “editor’s draft” of a spec is actually the canonical source version of the spec: The version including the latest changes made to the source for the spec in its source-control (GitHub) repo. That makes it the one you should use if you want to be sure you’re reading the most-up-to-date spec text — not already-obsolete spec text.

The way to know whether what you’re reading is actually the canonical version is: It’ll usually be explicitly subtitled with the literal label Editor’s Draft. But also: It’s the version you find outside the w3.org/TR publication space.

“Working Draft” is a label for indicating the status of a spec. There are two flavors: the “normal” Working Draft label, and the “FPWD” or “First Public Working Draft” label.

“Working Draft” is what a spec gets labeled with while a group is still “working” on getting it to the point that they believe it’s ready to be fully implemented — and ready to be thoroughly tested (by having a suite of tests to test against) — and before it’s ready to secure Royalty-Free Licensing Commitments.

So, you can think of any Working Draft as being stamped with a giant “Use only with caution” warning, signaling that the spec very likely still has some significant deficiencies — but that it certainly does have one very important deficiency, which is: RF Licensing Commitments for the features in the spec have not yet been secured.

The first time a spec is published at a w3.org/TR URL, First Public Working Draft (FPWD) is the label it gets.

The W3C widely announces every single FPWD — including, often, by posting a news item both directly on the https://www.w3.org/ homepage and on the W3C News page. Along with the general “Here’s something new!” value of each such an FWPD announcement, it also has another very important purpose, which is: To give a heads-up to everyone that the FPWD publication triggers a 150-day Exclusion Opportunity for the spec.

Anywhere you see or hear the term Patent Review Draft, you can in practice substitute Snapshot. Patent Review Drafts — Snapshots — are the stage at which Royalty-Free Licensing Commitments are actually are secured.

Exclusion Opportunities are limited-time chances to exclude specific Essential Claims from any RF Commitments.

There are two spec labels (publishing “stages”) which trigger an Exclusion Opportunity: FPWD and CR.

The term “disclosure requirement” refers to the obligation the W3C Patent Policy places on all W3C Members to disclose any knowledge of a patent believed to contain any Essential Claim with respect to a particular spec.

The disclosure obligation is explicitly triggered any time a new version of a spec is published in the w3.org/TR spec-publication space — but also, to quote verbatim from the relevant part of the W3C Patent Policy document:

The disclosure obligation is an ongoing obligation that begins with the Call for Participation… In any case, disclosure as soon as practically possible is required.

Everywhere you see Candidate Recommendation, substitute Working Group Specification — in this sense:

1. The spec is just a WG-owned/endorsed spec — not a W3C-owned/endorsed one (that’s what a REC is).
2. The spec meets criteria for dropping the Working Draft warning label — criteria such as:
   1. Consensus has been achieved within the group for dropping the Working Draft warning label.
   2. Wide review has been conducted thoroughly.
   3. Implementation interest has been clearly expressed by at least two implementors.
   4. WPT tests (or equivalent) are already written for all features in the spec.
   5. Implementation bugs have been filed in the project bug/issue trackers of all target implementations.
   6. An MDN issue has been filed, describing the docs that would need to be written for the spec.
3. The spec has either secured RF Licensing Commitments or is at most 60 days away from securing them.

That’s because initiating the process for dropping the Working Draft warning label is what you can/should do with a spec when your group believes it’s ready to be fully implemented — and ready to be thoroughly tested, with tests ready — and you want to secure Royalty-Free Licensing Commitments for the spec.

And if you already have multiple implementations (and a test suite) for a spec still labeled Working Draft, you probably should have already started the steps for securing Royalty-Free Licensing Commitments.

CR Snapshots are static date-stamped versions of the state of a spec — of all features normatively defined in a spec — at a particular point in time, intended solely for patent review toward a goal of securing RF Commitments.

So, everywhere you see Candidate Recommendation Snapshot, substitute Patent Review Snapshot.

The first type of CR your group publishes — after removing the Working Draft label — must be a Snapshot.

60 days after publishing that first Snapshot, you secure RF Commitments for all normative features it defines.

After publishing that first Snapshot, you can then start autopublishing CR Drafts.

And after that, you typically publish new patent-review Snapshots at some regular cadence — for example, once every 6 months — if any substantive spec changes were made to the spec during the intervening time period.

60 days after publishing a particular Snapshot, you secure RF Commitments for all normative features it defines.

When your group believes a spec is fully ready to be implemented — and ready for thorough testing — then, follow the steps for securing Royalty-Free Licensing Commitments, and publish the first Snapshot for it.

Then, at some regular cadence (say, once every 6 months) and if any substantive changes were made during that period, republish a new Snapshot — solely in order to secure RF Licensing Commitments on those changes.

As you work with implementors and contributors and on tests — and, as you iteratively refine the spec contents — (re)publish the updated contents as “Candidate Recommendation” (“CR”) “Drafts” into the w3.org/TR space.

If you create a spec for a new feature for the web, plan on continuing to maintain that spec for the rest of your life (no joke) and/or plan to hand it over to others who will agree to continuing to maintain it after you move on.

Ensuring interoperability among multiple implementations of a spec is, in practice, an ongoing process the never really ends — and that requires iteratively making refinements to the spec over time. Sometimes outright bugs are found in existing spec text, sometimes ambiguities in need of clarification, and sometimes just simple typos.

But all of those cases require you to do continuing maintenance of the spec. And the way you do that is by having a place where others can report spec issues they find, and can submit spec patches. That typically means using a GitHub repo or something similar — with an issue tracker and a mechanism for users to submit patches.

It’s like maintaining an open-source software application or library: Even after you release a “stable” version — and even in the case where you may never end up adding any features to it, or never making any API changes — you still continue to make updates to it, as users find bugs, contribute patches with code refinements, and so on.

You can set up “autopublishing” for your specs (using W3C “Echidna”), so that up each time you merge commits to the source for your spec, your spec updates will be automatically published into the w3.org/TR space.

You can set it up using the spec-prod GitHub Action, or Bikeshed’s built-in support, or any other available tools.

In plain terms, RF Licensing Commitments provide for your spec to be freely implemented by anyone — so no one will ever need to pay royalties to anyone else in order to ship/sell products that have the features from your spec.

In legal terms: A Royalty-Free Licensing Commitment is a binding legal commitment to license under the W3C Royalty-Free License any Essential Claims that haven’t been excluded during an Exclusion Opportunity for a spec.

Among standards-development organizations (SDOs), the W3C has essentially the strongest-possible RF policy — and publishing a Working Group spec at the W3C ensures it’ll secure the strongest-possible RF Commitments.

There are major differences between commitments available for Working Group specs vs Community Group ones:

1. Working Groups (WG): When a participant joins, they agree to RF licensing for the entire contents of all specs published by the Working Group as Snapshots (aka Patent Review Drafts).

   Community Groups (CG): When a participant joins, they agree to RF licensing for only any spec parts which they themselves might contribute — but not for any other parts of the spec contributed by anyone else.

   For any Final CG Report you publish, you can ask the CG participants to sign a Final Specification Agreement (FSA), to agree to RF licensing for the contents of just that particular Final CG Report. But signing that FSA is entirely voluntarily and not automatic in the way that getting RF agreements for Working Group specs is.

2. Working Groups: The entire W3C Membership has disclosure requirements that obligate them to disclose any knowledge of a patent believed to contain any Essential Claim with respect to any Working Group spec.

   Community Groups: CG participants have no disclosure requirements — and both the CG CLA and CG FSA have clauses literally titled No Disclosure Obligation which explicitly state that.

You can maintain so-called “living standards” at the W3C.

Yes. For any Working Group spec that’s receiving RF Licensing Commitments, your group can continue to perpetually autopublish and maintain that spec as a so-called “living standard” — without any requirement to necessarily ever get formal endorsement of the spec from the W3C and its Members.

In other words, these are “unendorsed by the W3C and its Members but perpetually maintained by the working group” specs which intentionally never “transition”/“advance” further in the W3C spec-labeling (maturity) process.

So the literal term “perpetually maintained working-group spec” would be a more accurate label for such specs.

The reason you’d want your spec labeled “CR” — rather than keeping it labeled “Working Draft” forever — is this:

To state that same fact in few more words:

• “CR” Snapshots are Patent Review Drafts, while specs labeled as Working Draft are not.
• “CR” Snapshots secure RF Commitments; publishing with the Working Draft label does not.
• While publishing with the FPWD label does trigger an Exclusion Opportunity, that does not trigger RF Commitments. RF Commitments can in practice only be secured after publishing a “CR” Snapshot.

Yes, it’s also possible to maintain a “living standard” in a Community Group (CG) — but only as a Draft CG Report, rather than as a Final CG Report. So, using a CG to maintain a “living standard” would mean losing two big things:

• Your CG-maintained “living standard” wouldn’t have a w3.org URL — because while Final CG Reports have w3.org URLs, Draft CG Reports do not have w3.org URLs.
• Your CG-maintained “living standard” would lack adequate RF Commitments — because securing even the most barely adequate ones requires a Final CG Report (and real ones require Working Group Snapshots).

Everywhere you see the term Recommendation or W3C Recommendation on its own (rather than in Candidate Recommendation), substitute W3C Standard — in the sense of being a spec that:

1. Has multiple existing interoperable implementations.
2. Has received the endorsement of the W3C and its Members.

That’s because getting a spec labeled as a Recommendation is what you can do with it if your group can show it has multiple implementations (or may otherwise be deemed sufficiently implemented), and you want the spec to go through full W3C Advisory Committee review to receive formal endorsement from the W3C and its Members.

However, even if your group can demonstrate a particular spec has been sufficiently implemented, you are not required to go through the process for getting it labeled as a W3C Recommendation.

If your group decides you don’t want to have the spec formally endorsed by the W3C and its Members, you can instead choose to continue to maintain it: by keeping it labeled with “CR” and perpetually keeping it up to date.

Anywhere you see or hear the term Recommendation Track, substitute the term Standards Track. So, for example, you can read the beginning of the The W3C Recommendation Track section in the Process doc as:

The Standards Track

Working Groups create specifications and guidelines to complete the scope of work envisioned by a Working Group's charter. These W3C Publications undergo cycles of revision and review…

And you can read the beginning of the Types of Technical Reports section as:

Types of Publications

This chapter describes the formal requirements for publishing and maintaining a W3C Standard…

Standards

Working Groups develop W3C Publications on the W3C Standards Track in order to produce normative specifications or guidelines as standards for the Web. The Standards Track process incorporates…

At the W3C, the term “wide review” is used in a number of senses — one of them being the principle of seeking out the widest-possible opportunities for review from the widest-possible set of reviewers. But it also specifically means the opportunity that the W3C provides you to get expert review of your specs in four core areas:

• Accessibility
• Security
• Privacy
• Internationalization

And along with those, there’s a fifth area that provides you the opportunity for detailed technical review from the W3C TAG, which functions to help ensure technical soundness/consistency of specs across all Working Groups.

Achieving group consensus for all decisions is a key goal around which much of the W3C process is designed. And the key role of group chairs — and of the W3C staff contacts who support them — is to adjudicate any disagreements among group participants, and reach resolutions for those.

Ideally, disagreements in your group get resolved to the satisfaction of every individual participant involved — but in cases where that’s not possible, your task is to at least achieve an acceptable level of consensus for formally deciding as a group on an appropriate resolution for the disagreement.

Anywhere you see or hear the term Technical Report or TR, substitute the term W3C Publication. So, for example, you can read the beginning of the W3C Technical Reports section in the Process doc as:

W3C Publications

The W3C Publication development process is the set of steps and requirements followed by W3C Working Groups to standardize Web technology. The W3C Publication development process…

And you can read the heading of the Types of Technical Reports section as:

Types of Publications

“TR space” means https://www.w3.org/TR — it’s the area of the w3.org site under which the W3C publishes specs. So any time you see or hear TR space, substitute W3C specs space or W3C publications space.

In other words, imagine that the https://www.w3.org/TR URL is instead actually the following URL:

In fact, if you want, you can actually already use that URL instead. Try it. Currently it (sorta) redirects to https://www.w3.org/TR — but maybe someday, things will be the other way around instead!

Normative requirements are any requirements that match the following definition from the W3C Patent Policy:

The normative portions of the Specification shall be deemed to include only architectural and interoperability requirements. Optional features in the RFC 2119 sense are considered normative unless they are specifically identified as informative. Implementation examples or any other material that merely illustrate the requirements of the Specification are informative, rather than normative.

That is, normative requirements are essentially any spec statements made using the RFC 2119 keywords “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional”.

A substantive change to a spec is any deletion or addition or modification to normative requirements in the spec that might invalidate anyone’s previous review or implementation of those normative requirements.

Substantive changes include any of the following classes of changes:

• changes that “make conforming data, processors, or other conforming agents become non-conforming”
• changes that “make non-conforming data, processors, or other agents become conforming”
• changes that “clear up an ambiguity or under-specified part of the spec in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming”
• changes that “add new functionality, such as new elements, new APIs, new rules, etc.”

Substantive changes may expose a spec to new Essential Claims — so, after any substantive changes are made to a spec, it should be (re)published as a Snapshot so that a new Exclusion Opportunity will be triggered.