This is an explainer for the proposed changes to the W3C Process for 2020. These changes have been adopted and are fully incorporated into the operative W3C Process as of 15 September 2020.

New Process Changes

Presentation

To help the AC better understand the motivation behind these changes as well as the nature of the proposed changes themselves, we gave a presentation at the May 2020 AC meeting:

Motivation

Proper spec development requires continuous availability of proposed changes to the community for review and adoption. The current W3C process hinders that because once a spec reaches CR—and especially once it reaches REC—it becomes very hard to change. This demotivates the community, inhibiting them from keeping specs up to date; and does not give developers an accurate view of the WG's thinking or of implementations.

At the same time, W3C values wide review, implementation experience, and royalty-free licensing as a means of developing well thought-out, implementable, and relevant specifications, and a key role of the Process is to ensure these are deeply incorporated into its standardization process.

Process 2020 introduces enhancements to the REC track to allow easier updating of RECs and CRs, to strengthen the patent policy, and to provide a Living Standards capability as a native capability of the W3C Recommendation Track, while maintaining the same review and quality requirements that it currently possesses.

Note: See Maintainable Standards Proposal and EverTeal for historical background. There is also the TPAC Slide Deck.

Design Principles

The following principles were used to design these changes to the Process:

Recommendations maintain the same level of Patent Policy protection and satisfy the same requirements (wide review, implementation experience, AC review, Director's review, etc) as currently.
One Process track for W3C normative specifications. (Track of a technical report is determined by type of report [spec, note], not preferred process, patent-policy, or other considerations.)
WG's intended implementation target is reflected in the official spec published on w3.org/TR (not hidden away somewhere unofficial or unnoticed by typical readers of the spec)
Wide review is wide, not just internal experts.
Patent protection applies once WG issues call for implementations, so that those implementations (which we require for the spec to qualify as REC) are protected.

Overview of Changes

Changes Are Additive

The upcoming changes to the W3C Process add new things to make everybody's life easier. If you were fine with the process previously and didn't need any particular improvement, you can keep doing everything as you always have, it's still valid. Lawyers, AC reps, and Horizontal Working Groups may need to adapt as the community takes advantage of the new facilities, but any individual Working Group can progress its specifications along the W3C Process exactly as before.

Improved Use Cases

If you did experience various pain points, read on, hopefully they're solved now. Here are some of the things that are improved:

Maintenance of Recommendations and Candidate Recommendations
Incorporation of new features into stable (CR-level, REC-level) specifications, opening the door for a W3C route for Living Standards
Earlier Patent Policy commitments

What's New

Substantive Changes to Recommendations

Substantive changes to Recommendations, e.g. in response to errata, can be annotated inline as Candidate Changes. Republication with these informative annotations is as simple as a WD update.
Candidate Changes which have received wide review and implementation experience can be folded inline by
1. issuing a Last Call for Review of Proposed Changes, which bundles patent review and AC review together
2. issuing an update request (similar to a PR transition request) to republish the Recommendation.

Feature Additions to Recommendations

Recommendations which are identified as expandable can accept feature additions, using the same process as substantive changes, above.

Streamlined Director's Approval

In the most straightforward and uncontroversial cases, the Director's Approval for issuing an updated CR Snapshot or updated Recommendation is automatic. See criteria.

CR Drafts vs. Snapshots

The current process for “Candidate Recommendation” publications, which involves a transition or update request for Director's Approval and triggers a patent review, is now called a “Candidate Recommendation Snapshot”. CR snapshots should be published every 6-24 months if there have been changes.
Additionally, between CR Snapshots, WGs are now allowed to publish “Candidate Recommendation Drafts”, which are supposed to be at the same level of quality as a CR, but can be published as easily as a WD (without Director's Approval). This allows the WG to continuously keep its official specification up to date with the latest WG thinking between CR snapshots. CR Drafts have the same Patent Policy implications as a Working Draft.
CRs (both kinds) can also be annotated as non-normative Candidate Changes or Candidate Additions, to facilitate wide review of proposals. The process for incorporating these changes into the normative text is just republication of the CR.

Improved Patent Policy

Patent licenses now take effect at CR, instead of at REC, protecting the earlier implementations (that are required to exist to get to REC!)

Process Document Edits

The Process being prepared for release in 2020 includes a singificant number of large changes, which can be broadly categorized into:

A convertion of the document from plain HTML to the bikeshed specification preprocessor (mostly just markup changes, some editorial changes)
Miscellaneous fixes, some editorial, some small, some medium
A reorganization of section 6, to disentangle definitions of maturities from transition between states (editorial)
Significant revisions and additions to the Recommendation Track

As some of these changes overlap, in order to facilitate review, the following snapshots of various stages of the evolution have been prepared, as well as diffs between these various stages.

Process 2020 drafts at various stages	Diffs from stage to stage
0. Process 2019
0. Process 2019	diff from 0. to 1.
1. … converted to bikeshed …	diff from 0. to 1.
1. … converted to bikeshed …	diff from 1. to 2.
2. …with miscellaneous fixes…	diff from 1. to 2.
2. …with miscellaneous fixes…	diff from 2. to 3.
3. …with section 6 refactoring…	diff from 2. to 3.
3. …with section 6 refactoring…	diff from 3. to 4.
4. …with REC track revision (latest)	diff from 3. to 4.

Overview of the New W3C Process

W3C has two Process tracks for Working Group publications:

Recommendation Track: For normative specifications. Subject to the W3C Patent Policy. Completed Recommendations have full W3C status, allowing them to be adopted by certain national bodies, etc.
Note Track: Non-normative reports. Can be created/updated anytime without restriction.

Improved Recommendation Track (EverTeal)

The Recommendation Track has three phases, corresponding to the following statuses:

Working Draft (Design Phase)

Intended primarily for design development; no specific expectations for quality, stability, or completeness.
Published by WG consensus; every draft after the first can be automated with Echidna.
Collects patent licensing promises from contributors and WG participants, but does not require licensing until CR or later.

Candidate Recommendation (Release/Testing Phase)

Issued when the specification is complete and thorough enough to meet its requirements, has been widely reviewed, and review feedback has been addressed.
Expected to be as well-written, detailed, self-consistent, and technically complete as a Recommendation, and acceptable as such if/when the implementation requirements are met.
Invokes all promised patent licenses (after the 60-day exclusion period) and issues a call for implementations.

Recommendation (Stable/Maintenance Phase)

Issued when a CR has proved its relevance and precision by demonstrating interoperable implementations, and passed AC review.
Expected to be quite stable, so changes in response to errata must be called out more explicitly.
“Extensible Recommendations” can also incorporate features already at REC level of quality and stability.

To facilitate review of changes, all phases allow informative annotation of candidate changes. For Recommendations, however, changes must be first annotated and formally reviewed prior to being incorporated, whereas WD and CR phases can incorporate changes directly into the next publication without prior annotation.

There also exists a Proposed Recommendation status: it is a transitional phase between Candidate Recommendation and Recommendation, and is fundamentally a special stable snapshot against which the AC review of the Candidate Recommendation and approval of its Recommendation happens.

CR Drafts vs Snapshots

Working Drafts and Candidate Recommendation Drafts can be updated by the WG at will. However for Candidate Recommendations, periodically WGs are expected to issue a Snapshot. The Snapshot is the legal basis for patent licenses and promises in the Patent Policy. Snapshots are also helpful to other reviewers because they provide higher-level steps though the development of the specification.

Publishing a new Candidate Recommendation Snapshot requires passing all of the current checks on Candidate Recommendations, and demonstrating this to the Team for approval to publish. This provides clear checkpoints for the Working Group to periodically review its work, and gives the Team an opportunity to correct misunderstandings in the process. (Candidate Recommendation Drafts ideally should also pass all of the current checks; but to ensure that the latest publication is fully up-to-date with the Working Group's latest thinking, it is not required to demonstrate this to the Team prior to publishing.)

Essentially, a Process 2020 Candidate Recommendation Snapshot is the same as a Process 2019 Candidate Recommendation; the Candidate Recommendation Draft is new and roughly corresponds to the way Editor's Drafts have been used by many WGs latestly, except that it is published on w3.org/TR as an official W3C publication and also receives patent protection equivalent to a Working Draft.

How to Use the Process to Maintain a Specification

W3C Process now allows maintainance within each of its three main phases: Working Draft, Candidate Recommendation, and Recommendation. The reason is, there's always errors to fix.

Updating Working Drafts

To make changes to a Working Draft:

Get a Working Group resolution to publish the changed specification as a Working Draft.
Publish using Echidna. (Or pester your Staff Contact if this fails for indecipherable reasons.)

Updating Candidate Recommendations

To make changes to a Candidate Recommendation:

Get a Working Group resolution to publish the changed specification as a Candidate Recommendation Draft.
Publish using Echidna.

Periodically (every 6-24 months), if there have been substantive changes since the previous Candidate Recommendation Snapshot, lock in patent commitments by publishing a new Candidate Recommendation Snapshot. This process is similar to transitioning from Working Draft to Candidate Recommendation, except that it can be more streamlined in the easy cases:

Prepare:
- Evidence of wide review, including horizontal review
- Evidence of addressing feedback
- List of substantive changes since the previous Snapshot
- Working Group resolution to issue a new Candidate Recommendation Snapshot
Request publication:
- If your update meets the requirements for streamlined updates, fill out the form and publish with Echidna. [ XXX This option has not yet been implemented. ]
- Otherwise, file an issue in the Transitions repository to request W3C approval.

Ways to think about this CR Snapshot + Update pairing:

Think of the Snapshot as the 2019 Candidate Recommendation -- extra processes compared to WD, triggers patent reviews. Think of the Draft as the Editor's Draft, except now it gets published on w3.org as the official draft.
Think of the Snapshot as the 2019 Candidate Recommendation. Think of the Draft as notes on what the WG plans to incorporate into its next Candidate Recommendation.
Think of the Snapshot as the 2019 Candidate Recommendation. Think of the Draft as Working Drafts the WG publishes while it revises in preparation for an improved Candidate Recommendation because they're easier to publish on a frequent basis (up to daily) than Candidate Recommendation (which can't be published more than weekly, and makes the lawyers mad if it's more than 2x/yearly).
Think of the Snapshot as similar to the WHATWG Snapshot, except with extra requirements attached in order to ensure W3C's values around wide review (particularly in light of its understaffed i18n and a11y groups). Think of the Draft as similar to the continuously-updated WHATWG spec, except with fewer requirements attached regarding implementation commitments.

Updating Recommendations

Updating a Recommendation with a change happens in two publications:

Annotate the Recommendation with the candidate change and republish it with Echidna. (It must be clear to everyone reading the document both what the current state of the text is, and exactly what it will be if the change is adopted. See README for markup conventions.)
Periodically (not more than twice a year, to avoid aggravating the lawyers and the AC), collect a set of candidate changes that have received wide review, are interoperably implemented, etc. and are therefore at the same level of quality and completeness as the rest of the Recommendation, and have your Staff Contact issue a Last Call for Review of Proposed Changes. This triggers the call for exclusions and kicks off the AC review period, among other things.
If no problems were found during the review, incorporate your changes into document, and issue an update request (similar to a CR Snapshot update request) to republish your Recommendation.

Under the 2019 Process, new features cannot be added to Recommendations, but the 2020 Process allows such additions to Recommendations if the Recommendation was originally issued and approved by the AC with that intention noted in the Status.

How to Maintain a “Living Standard”

CR Route

The easiest way to maintain a Living Standard at W3C would be to maintain it as a Candidate Recommendation indefinitely.

This depends on W3C adopting the 2020 Patent Policy which applies royalty-free licenses at the Candidate Recommendation phase.
Candidate Recommendations do not have objective implementation requirements or AC review, and therefore have a lower status than full Recommendations.

REC Route

A Recommendation can also be maintained as a Living Standard: in this case the specification has a higher status due to its higher requirements, but there is more overhead to maintain this status.

Changes cannot initially be directly incorporated into the document, but must be merely annotated into it, until after they have received wide review and interoperable implementations.
- This has the downside of being more work for the editors.
- This has the benefit of highlighting the changes for readers, reviewers, and implementers.
Adding features is allowed, but only if this intention was noted in the Status section during PR (and the AC thereby approved the REC's expandability). To avoid undermining expectations for users of a W3C Recommendation, an existing Recommendation cannot be made expandable after the fact.

Issuing Versioned Recommendations

For groups that want to create regularly-released Recommendations of their ever-expanding specification, which are versioned and abandoned rather than maintained, one possible process is the following:

After publishing the Recommendation, publish a new First Public Working Draft with a new shortname numbered N+1 or N+0.1.
Make changes, add features, solicit wide review, and transition into CR.
When interoperably implemented, issue the new Recommendation, superseding the old Recommendation.
Maintain a redirect /TR/foo/ which points to the latest Recommendation (or latest CR or latest WD, as the group prefers).

Note this method is possible under the 2019 and earlier Processes as well, they do not depend on the new Process changes. If this is a work mode your working group uses, and you need some aspect streamlined, please describe your use case and the problems you're running into to the Process CG.

Managing Horizontal Reviews

A key value of the W3C spec development process is wide review. This includes (though is not limited to!) getting review from the various Horizontal Review Groups: Internationalization, Accessibility, Privacy and Security, Technical Architecture, etc.

Wide review is expected to be incorporated continuously into a Working Group's development process, by publishing proposals and requesting feedback from relevant parties and the public. Whether wide review has happened and its feedback addressed is one of the things checked by the W3C Team when granting Director's approval to advance a spec.

See How to do Wide Review for more details.

Horizontal Review Checks for Automatic Update Approval

For CR Snapshot and Recommendation updates, in addition to the usual manual route of requesting Director's approval, which allows for human judgement, Process 2020 also allows the use of an automatic process if the spec update satisfies a stricter-than-required set of requirements that can be checked objectively. Using this process requires signoff from the various Horizontal Review Groups. This can look like:

At the simplest level, sending email to the HRG requesting signoff (preferably with an overview of changes), and getting back a reply that review was satisfactory or waived.
An HRG can, after having reviewed a draft once, waive any further need to review. For example, Accessibility would be likely to waive review requirements for css-syntax-3 since it doesn't really intersect their concerns. Internationalization might also waive review on css-syntax-3, but only if the changes do not impact encoding or @charset. The TAG would probably waive review generically of any changes that do not add new features.
An HRG can, after having reviewed a draft once, require being looped in explicitly. For example, internationalization might want to keep close tabs on updates to css-text-3.
An HRG can maintain a status tracker for either some or all specs, indicating which ones it believes are in good shape, which ones are pending review, and which ones have problems that they think need to be addressed before further advancement. As long as the status as of a particular date is retrievable for future archaeology, and the HRG has indicated it is suitable for such purposes, such a status tracker can be referenced as a representation of the HRG's signoff.
An HRG can create a self check list, which submits answers to an archived mailing list for future reference, and sorts review requests for a particular update into “review requirement waived” vs “please ask for explicit review”. In this case the waiver can be used as the HRG's signoff.

Making these “streamlined” updates truly streamlined will require some coordination and documentation, but should ultimately result in better oversight of W3C specs with less overhead for editors, less work for the HRGs, and more clarity for the AC and W3C overall.

Note: The current Director's approval route is still available, and its requirements remain unchanged.

Sample Resources

Internationalization self-check list and Best Practices document allows spec editors to become aware of, and address, common internationalization requirements on their own, even before requesting review from the i18nwg. This helps WGs incorporate these requirements into the design of their technology, and helps the i18nwg focus their effort into more subtle things that require more specific expertise rather than on addressing these more basic i18n requirements.

Changes Documentation

To facilitate review, particularly of our overstretched Horizontal Review Group colleagues, each Candidate Recommendation is required to document changes since the previous Candidate Recommendation Snapshot. To avoid overburdening editors, not all changes are required to be documented.

New features MUST be documented.
Substantive changes SHOULD be documented. (Their existence MUST be documented, so people know to diff.)
Editorial changes MAY be documented. (Their existence SHOULD be documented, so people know to diff.)

See W3C’s HTML diffing service

See Classes of Changes.

Integration with Patent Policy

The goal of W3C's Patent Policy is to ensure that its specifications are implementable royalty-free. To this end, it requires all participants in a Working Group to commit to licensing any patents they hold that are essential to implementing the specification, unless they are specifically excluded during a limited exclusion period after the initial publication of a specification requiring those patents.

W3C is currently discussing updating its patent policy in order to protect early implementations of a specification (which the Process requires to exist to prove interoperable implementation experience prior to issuing a Recommendation), as the current one only protects implementations of a Recommendation. The new Process is able to operate under both the current policy and a hypothetical new one tailored to the new Process (though it obviously cannot provide the benefits of such a new Patent Policy unless W3C adopts one).

Under the old Patent Policy:

Working Draft collects promises.
Candidate Recommendation Snapshots correspond to “Last Call Working Draft” publications, and lock in promises to license any essential patents once the specification reaches Recommendation.
The Patent Policy only requires the licenses to be available for Recommendations, however. Earlier drafts only collect promises of such licenses.

Under the new Patent Policy:

Working Draft collects promises.
Candidate Recommendation Snapshots invoke those promises (if they are still applicable) and also collect and invoke (after a 60-day exclusion period) any new ones pertaining to recent changes.
As in the current Patent Policy, licenses for essential claims of Recommendations are available as soon as it is published (due to publication after the expiration of the earlier CR or Last Call Review exclusion periods).

Note Track

This is the simplest track with the fewest requirements. There are two phases; the first one is optional:

Working Draft: A Working Draft intended to become a Note. Used when the WG feels the Note is still a work-in-progress and wants to represent it as such. (However, see https://github.com/w3c/w3process/issues/342)
Note: A Working Group Note. Published by WG consensus. Can be updated at will to represent the latest WG thinking.

Tooling Requirements

One of the design goals of the new Process was to be possible to implement with minimal tooling updates.

Minimal

Absolute minimum requirements to be able to deploy the new Process are:

Add spec templates for new spec statuses.
Update Specberus to accept the new spec templates.

Reasonable

Minimum requirements for the new Process to be reasonably practical:

Update Echidna to be allowed to publish (using mechanism similar to the one we already have for editorial updates to CRs) because we really don't want to pile up manual publications for these updates:
- Candidate Recommendation Drafts at will
- Recommendations with additional Proposed Change annotations at will

Additionally, to take advantage of the streamlined approval process, a fair amount of HRG coordination, documentation, and at least some basic tooling will be needed. (Where “fill out a form that posts your response to an archived mailing list” is sufficient basic tooling for this purpose, but someone has to set that up and create the necessary forms.)

Nice to Have

Nice to have (can be developed over time):

More sophisticated tracking of Horizontal Review statuses. No idea what that might look like yet.
Clever diffing tools to facilitate Proposed Change annotations.

FAQ (Frequently Asked Questions)

Do we need to distinguish fixed-scope RECs and expandable-scope RECs?

Process 2020 distinguishes between normal RECs, which can accept substantive changes but not new features, and expandable-scope RECs, which are exactly the same except they can also accept new features.

Expandable-scope RECs allow W3C to incorporate a Living Standards model as a possible way to develop specs at W3C.
Fixed-scope RECs allow a WG to clearly promise that the feature-set of a specification will be stable, and is particularly appropriate for specifications referenced by certain national standards bodies, by legal codes, by firmware or hardware requirements, or other use cases that require fixed scope but might want to still (ideally) allow error corrections.

As there appear to be use cases for both models, the current proposal allows both. To avoid changing expectations once a specification becomes W3C Recommendation, Process 2020 requires expandable-scope RECs to clearly define the scope of their potential expansions in the Status section and have that vetted by the AC during the PR review phase.

Note: Due to the high level of requirements on W3C Recommendations, there are a lot of checks on substantive changes to a Recommendation. These same checks are applied to both new features and corrections.

Do we need to allow expandable-scope RECs at all or is CR enough?

If W3C adopts a new Patent Policy that applies license obligations to CRs, then arguably a Living Standards model could be implemented as a perpetual CR.

Two reasons to allow expandable-scope RECs are:

W3C might not update its Patent Policy :(
Some groups might want the full status of a Recommendation, which carries W3C's full endorsement and indicates a higher level of implementation experience (and hopefully, therefore, quality and stability), but nonetheless also want to develop a specification as a Living Standard that is able to evolve not just by incorporating minor adjustments and error corrections, but also by adding new features.

Patent Policy Questions

Why do we need license obligations at CR?

There are two reasons to apply patent license obligations to Candidate Recommendations in addition to Recommendations:

Firstly, not only is CR the official “Call for Implementations”, the W3C Process requires implementations to exist (in order to prove adequate implementation experience) before the spec can qualify to become a Recommendation. If we're asking implementations to exist, we should make available any licenses that are needed to make an implementation.
Secondly, specifications exist in CR for many years, and if we are to use them to offer a Living Standards process, possibly indefinitely. In order for the specification to be able to fully function as a Web standard during this time, the RF licenses need to also exist.

What's the story for license obligations on immature / heavily changing specs?

With the proposal to apply license obligations earlier in the Process, there are some concerns with apply license obligations to specifications that may change significantly over time. But Working Drafts accumulate only promises, as they do now: license obligations only apply at CR, when a specification is expected to be more stable. And, remember, that the licensing obligations only pertain to claims essential to implementing the specification when implementing the specification, W3C RF licenses are not a blanket license to essential claims for all uses.

Do we need contribution licenses?

W3C Community Groups and the WHATWG include contribution-based licensing obligations in addition to occasional full-spec full-WG signoff. The obligation is incurred by a contributor for their own essential claims arising out of their contribution, and take effect after a brief waiting period.

Reasons to include a contribution-based license:

Parity with W3C Community Groups and the WHATWG IPR policies
Protection for early implementers of a specification (particularly during WD stage), at least from the contributor of the feature they are implementing.

Reasons not to include a contribution-based license:

It is a major change to the structure of the current Patent Policy.
The currently-active members of PSIG do not believe it is necessary to add given the strong protections of the current policy.
There isn't enough time to develop and get consensus on such significant changes to the Patent Policy for 2020, and it would complicate adoption of the more critical shift to protecting CRs under the current Patent Policy structure.

If contribution licenses are something that matters to you, please inform the Advisory Board so that your concerns can be taken into consideration in light of future projects.