Introduction

Overview

As the Web evolves continuously, some groups are looking for ways for specifications to do so as well. So-called "evergreen recommendations" or "living standards" aim to:

track continuous development and maintenance of features
get review and patent commitments
report on implementation status

all on a more granular level, namely feature-by-feature rather than only at the entire specification set.

This proposal seeks to develop in greater detail what it would take for W3C to recommend such evergreen documents. In the analysis, we consider various aspects and values embodied in the current W3C Process and Patent Policy to assess how those can be met in an iterative mode. This process is inspired by work in W3C WGs, CGs, and WHATWG.

Note to readers: This wiki contains many levels of detail. A general overview can be found in the sections Overview-Licensing, with further details (and possible contradictions) elaborated further down. Consider also the final comparison table

Continuous Development

ER Specifications are developed on a continuous basis. Working Drafts published to /TR should represent WG consensus, but rather than a daily call for consensus, the WG may adopt a procedural consensus, as defined below, by which they agree in advance on the conditions under which a feature can be added.

We also seek continuous review, such that all material that has been in the specification for six months or more has been available for review:

- by the community – but particularly the working group, the Advisory Committee, and the Team – that the specification meets the charter requirements (for testing, implementation, and interoperability, for example);
- by the cross-functional groups for acceptability;
- by the liaison groups and the wider public for acceptability.
all material that has passed a snapshot exclusion opportunity carries a license to the unexcluded essential IPR from those who had the opportunity

Tooling and markup would support groups seeking and providing reviews to identify new and changed material.

Under the current Process and Patent Policy, royalty-free patent commitments attach when a document is published as a Recommendation, after exclusion periods at FPWD (First Public Working Draft) and CR (Candidate Recommendation). We propose that for continuous publication, there be periodic snapshots, after which patents not excluded would be licensed royalty-free.

Terminology

Evergreen Recommendation (ER): the product of a continuous publication process; tip-of-tree
ER Snapshot: a dated version taken from the ER, e.g. for IPR review purposes

Roles, Responsibilities, and Consensus in the Evergreen Model

As with any W3C Working Group, there are Chairs for the group, Editors for the documents of the group, and Participants in the group. However the roles and responsibilities may be somewhat different in these groups from those in groups producing Rec-track work. One of the important ways that the roles must differ is because of the role of consensus.

As opposed to a Working Draft on the Recommendations track, an Evergreen Recommendation must always represent consensus. That is because the ER document itself has status as something recommended by W3C; hence it must represent a consensus. But there is no need for the consensus to be achieved by a daily Call for Consensus; or anything that formal. That would slow down the effort considerably.

Instead, the means to achieving consensus can be decided by each group. For example, groups producing Evergreen Recommendations may operate on procedural consensus. The charter or chairs specify a work-mode for adding to the ER, and reach WG consensus on that mode. The editors have primary responsibility to implement that work-mode, with review by the WG and appeal to the chairs as a backstop against overstep.

An example of how that might work could be:

All merge/commits on the editor's draft document needs to get approved/supported by at least one reviewer or group participant
All substantive merge/commits on the editor's draft document needs to get approved/supported by at least one or more implementors, have a corresponding web platform test (WPT) pull requests (or lists a reason not to), and must allow a 10 day review period to the group participants

- all new feature merge/commits on the editor's draft document needs to get approved/supported by at least two or more implementors

This is just an example, but it illustrates that for the most part - within the rules set by the group - the Editors of the specification have the primary role to ensure that the specification represents the current consensus of the Working Group. This is done by informal means: regular conversations between the editor and participants; participants raising issues about the spec in github; editors addressing issues and pull requests; and editors tracking implementations to ensure that the ER is both reflective of implementation as well as sensitive to the issues raised by the community. The Editor achieves this consensus without issuing formal calls for consensus; instead the Editor is continually in contact with the group to ensure that the ER document represents a consensus.

As opposed to the REC track, the Chair does not have the responsibility to call for consensus or assess consensus as a result of a poll of participants. But the Chair has an important oversight role to ensure that the group's discussions proceed according to the procedural approach chartered for the group, are in accordance with CEPC, and is a resource for participants who disagree with the way that the editors are documenting the evolving consensus of the group. If a participant believes that the editor is not behaving fairly, the chair facilitates discussion between the participant and editor. If that does not solve the issue, the chair may also issue informative calls for consensus, or engage in other discussions to see whether consensus can be reached or whether the editor can adjust their position.

Despite this important facilitation role of the chair, they generally do not have the authority to overrule the sense of the editor of where consensus lies during the ER phase of a specification development as long as the editor is following the procedure of the group. However, in an extreme case, the chair can request that the Director look into the situation and possibly remove the editor.

We discussed in the Overview that we expect incremental community review of an ER. It is the responsibility of the chair to ensure that there is appropriate notification to review groups about the progress of the ER.

However, when the ER is ready to make the transition to the REC track, the chairs will have a more significant role assessing consensus in the usual way.

Reviews

The W3C has a value that all substantive changes are subject to these four kinds of review: "horizontal review," "wide review,", Director, and Advisory Committee review. For Continuous Publication, we mandate automated reports to the AC and cross-functional groups on a regular basis, reporting on substantive changes. This signals to cross-functional groups that they may perform their reviews. The ES process may still require further confirmation to assure that the reviews are completed.

External groups should be notified by liaison of the existence of the Continuous Publication, as early as is practical and useful, and agreement reached with them how they will review substantive changes. They may request to be added to the automated report, for example; they may elect to watch the repository manually; or ask to be notified manually by the WG e.g. in liaison or email. Such manual notification should be both archived and also occur no less frequently than every 180 days.

Imputed review There is a 180-day period before changes are considered reviewed. This period starts on the first report that details the change (even if it was later reverted and re-inserted). Note that anyone, including AC, cross-functional groups, public, and members of the WG, are free to comment on anything at any time, of course; the 180-day deadline merely sets a date before which changes ought to be considered by the working group, and after which they might apply more back-pressure.

Review tooling

This implies a tooling requirement: automated tools must inform the community when a change has been made, giving notice which changes are about to become accepted. A reviewer may also seek to know changes since their last review. To enable such automated reports, all changes must be made through Pull Requests (no direct commits). Pull Requests are considered substantive unless tagged as "Editorial" or "Minor technical". Issues are assumed non-substantive unless tagged explicitly as substantive (to avoid flooding the reports with issues that have not yet been categorized).

(Note that the tagging for issues is necessarily the opposite to Pull Requests, as we don't want to report untagged, newly filed, issues, that the WG has not yet considered, as automatically substantive.)

The automated report must detail:

new substantive changes since the prior report
substantive changes that will be declared past their 180 day review period in the next automated report (i.e. a kind of 'last call' for comments)
substantive changes that have just passed their 180 review period
all other changes (minor, editorial, etc.) performed via Pull Requests
suitable reporting on issues, noting particularly any tagged "substantive" or "cross-functional" (recently opened, recently closed, tagged substantive but still open, etc.)

(Note the the WG, cross-functional groups, external bodies, and AC are at liberty to request other tags, e.g. identifying issues or pull requests of particular concern to those communities; we already have a substantial set of tags.)

A meaningful manual change log entry must be made in Github for any substantive change. There must be a way to generate a diff for a specification based on dates.

For any issue filed against the document, the WG should consider whether an inline "issue" or “erratum” notice should be placed in the document.

For “review” issues filed by the AC, a cross-functional W3C group, or by an external “liaison” body, the filing group can request, at any time after filing the issue and until the issue is resolved, any or all of:

that there be an inline issue/erratum notice, and/or
that the feature be marked as “provisional”
that the feature be removed until consensus is reached.

The WG is not automatically obliged to grant any request, but note that such denial may escalate the disagreement.

If the WG and filer are unable to reach consensus, then the usual recourse to Formal Objections, Appeals, and Director rulings can be followed. As the continuous publication process does not entail formal Transitions, Director review can be triggered by the filer and WG deciding that they are at an impasse and one of them filing a Formal Objection. Formal Objections must be documented in the header of the document until the resolution is implemented.

Since features that are stable in the specification for 180 days are considered final (there is an implied "acceptance" decision), disagreements should be raised to the editor, and then to the chairs before that 180-day period expires. If an issue is raised to the editor and the chair does not feel that the editor has sufficiently addressed the issue, the chair may appeal to the Director; possibly removing the editor.

Similarly, if a participant has raised an issue and believes that neither is appropriately addressing their issue, they should Formally Object to the Director prior to a feature being around for 180 days. But they may only do that if they have first raised the issue with the editor and the chair and they have not gotten satisfaction.

Transitions between the Evergreen and Recommendation Tracks

The following initiations or transitions are envisaged:

A document may be initiated on either track ("this document will be developed as a Recommendation | Evergreen Recommendation")
A document previously on the Recommendation track may switch to the Evergreen track; typically this happens after Recommendation status, for maintenance, but may happen on any re-chartering;
A document on the Evergreen track may enter the Recommendation track by satisfying the requirements for a WG Working Draft or Candidate Recommendation, and entering as such. Generally, when a WG wants to take a document to the Recommendation track they would first take an ER Snapshot to cement patent commitments to date.
- Transition to the REC track does not necessarily mean that specification development as an ER stops because the work is entirely completed. For key parts of the web architecture, the spec is in constant evolution. However moving a snapshot to the REC level provides certain checking and validation for the work (e.g. complete cross-functional and AC review) which adds value in the technology development. There could still be an ER version that is further developed and developers wanting the most up to date version of the specification should use that.
Although a specification might remain as an ER for many years, there is value for any spec to transition to the REC track, because it is only at the REC track where full horizontal review and AC review is provide. While this value might not be appreciated by all developers that are primarily focused on current state of implementations, it is important for the broader community. The Charter for an ER must specify whether an ER is expected to transition to the Recommendation track - and if so - the expected point in time for transition to W3C Recommendation, even if that time is beyond the time-horizon of a particular charter. If the ER is never expected to transition, the charter should explain how full review is achieved or why it is not necessary for this specification.

Licensing

We intend to have Royalty-Free licensing as with all W3C specs, with licensing commitments made continuously through spec development, and exclusion opportunities prior to final commitment.

We ask the PSIG to look at spec development in the Evergreen model, the RF licensing requirements of W3C, and the spec review process within a member organization, with this general philosophy:

Based on the WHATWG process, perhaps with

an adjustment of intervals (we probably prefer a longer filing period, say 60 days).
a provision that WHATWG lacks, for an exclusion opportunity on the current Working Draft, on leaving the WG (to match the Patent Policy, and close a significant gap).

An exclusion filing must result in:

A notification to at least the WG general mailing list, the advisory committee, and PSIG, so that the community is immediately aware and can take appropriate steps.
The formation of a Patent Advisory Group (PAG).
The documentation, in the header of the specification, of the exclusion and the PAG, until the PAG completes its operation and its recommendations implemented.

Process Edits

There is a draft of what the relevant process chapters might look like, under development.

* More detail below *

Tooling Requirements

We have indicated above some of the required tooling for features. Since features achieve greater status by aging (in particular, we assume after 180 days there has been sufficient time for incremental horizontal review), there needs to be tooling so it is easy to determine when a feature was introduced and/or last changed.

Since features achieve greater status by acquiring implementation experience, testing, and demonstrating interoperability, there needs to be tooling so it is easy to determine that a feature has all of this experience.

Since a feature is more meaningful to implementors when there are implementation commitments, there must be tooling for that.

Since a feature is considered normative in an ER when it has 180 days of aging and implementation experience, tooling must make it easy to identify that status as well.

Tooling related to tagging issues in GH is as follows:

We need

to define the standard tags that the report tool will use to work on, for Issues and Pull Requests.
the report tool to distil Pull Requests by tag (editorial, minor technical, or assumed substantive) and date (first appearance, will hit 180 days in the next 30 days, has passed 180 days, all since merging)
the report tool to distill Issues by tag also

Ideally there is a commit hook that generates a "permanent link to this version" header.

Note that all documents in a Github pages repo can have a unique URL, and are immutable; these come free. Those wanting to reference a specific unchanging version can do that. You can refer to a specific revision in GitHub using htmlpreview or rawgit.com; for example the August 17th version of WebVTT is

<http://htmlpreview.github.io/?https://github.com/w3c/webvtt/blob/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html>

or rawgit.com

<https://rawgit.com/w3c/webvtt/2b24ae60e84e8cbac033c148db2715104e0b9368/index.html>

It should be easy to mark a document as under PAG review or under a Formal Objection, while exclusion or FO processing is in progress.

We might like better support for in-line errata, and provisional material, and the ability to see a document without those (and thus make a snapshot), but this is optional.

Tooling Design

The tooling is intended to leverage information coming from multiple sources: WPT (tests, results), caniuse.com, specification, github.com, etc.

For a given section, sub-section, paragraph, we may identify the following:

tests
test results
feature implementation information
feature implementation commitment information
180 days information
articles in MDN

For ES, the annotations will be providing as JSON objects, contained in one file per commit and per specification generated on the day of the ES snapshot, then loaded and render using a JS script. The annotations within a given snapshot are NOT expected to change/involve overtime. In order of preference, each annotation object will be identifiable with:

API information (eg AuthenticationExtensionsClientOutputs, AuthenticationExtensionsClientOutputs.rawId)
CSS property name (eg "background-size")
Markup elements and attributes (eg "use", "use@width")
section title (eg "Android Key Attestation Statement Format")
CSS Selector (eg "pre.idl")
fragment identifiers (eg #preventSilentAccessCredential)
section numbering

The same identifier may apply to more than one annotation object.

Bikeshed and ReSpec, the most currently used spec editing framework, will need proper support to identify annotation object identifiers as well as WPT, caniuse.com, and MDN identifiers. Test files can be identified by providing a list of files in WPT. Test results can be deduced from that list. A test file may contain more than one test and we will need to work with WPT folks to get a method to identify specific tests within a test file. caniuse.com already provide annotations to integrate a feature implementation information.

Last update information will be generated based on running diffs with the 180 days-ago version and generating resulting JSON annotation objects. We should be able to leverage the [tagging], on issues and pull requests. We'll need to explore if the result can be refined using commit history information (see payment-request commits).

A tool will generate the annotation file using information embedded within the specification. The specification may contain additional annotation objects to be merged as well. A tool should check the resulting annotations to determine if all annotation objects are still relevant.

The commit hook will be tasked to generate an ES snapshot and the annotations associated with it.

Referenceability

For all W3C specifications, it is important to know how they are normatively referenced by other specifications - both on the ER track as well as the REC track.

It is possible to normatively reference a W3C specification, evergreen or working draft, from a W3C Recommendation as long as the [consideration] are applied, in particular:

Stability of the referenced part(s)
Nature of the dependency
Status of implementations

Charter, Repository, Document, Testing, and Implementation Requirements

WG Charters may declare that a document is developed on the Recommendation Track, or on the Continuous Publication track. Changes between tracks, for any document, require a new approved charter unless the changes are already in the charter.

In order to enable 'harvesting' of the Github repository URLs of Continuous Publications, by both lawyers and the tools that inform reviewers, the Github repositories must be created before the charter is sent to formal AC review, and the URLs to those repositories must be in the charter, in a section clearly listing those documents on the Continuous Publication track.

Those Github repositories must be in the W3C space and also must document the publication URL (usually Github.io) of the readable document.

The readable document must list, in its header, the URL that refers to the latest viewable version, and also a permanent URL to the specific revision being viewed. It should also identify the Github repository where issues are filed and revisions made. As noted above, both unresolved (a) Patent Exclusions and (b) Formal Objections must be documented in the header of the specification.

The charter must identify the implementability, implementation, test suite, and test pass coverage requirements for a feature to be considered not provisional but final. Features that do not meet these requirements should be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.

Implementation expectations

Typically speaking an ER specification will consist of different features at different levels of implementation maturity due to the requirement to be "Evergreen", that is, very reflective of current implementation and thinking among implementors. Included in that are features:

For which there is sufficient implementation experience and testing that the Director would ordinarily feel that those features could be approved in a W3C Recommendation.
For which interoperability has not yet been demonstrated, but there are at least commitments from sufficient implementors that there is a strong likelihood that the features will ultimately be accepted as Recommendations.
(In rare cases) Draft features that the WG is working on that are significant chartered deliverables being developed in the WG which are expected to be implemented but which lack firm implementation commitments at this time.

While there could be good reasons to have features of various levels of maturity in a specification, it is important to clarify what part of the specification is actually being given support by W3C for developers to implement.

For all specifications for which W3C is conferring status, the rule is that the status is only being conferred on those features where there has been sufficient implementation experience and testing to demonstrate interoperability. This is true whether the features are in an ER, an ER snapshot, or a W3C Recommendation.

That does not mean that the other features need to be stripped from the document. They remain in the document but are considered as informative material for the spec, not normative, endorsed features for implementors.

This characterization of what parts of the spec are considered normative must appear in the status of the document.

Sample Charter Language

The Fruit Action Working Group (FAWG) will develop the following on the Recommendation Track:

Pineapple picking and handling,

and the following on the Continuous Publication Track,

Olive picking, pitting, curing and bottling; in the Github Repo (URL goes here)
- The ES spec for Olive picking will have an IPR snapshot every 12 months.
- While the Olive picking spec is on the Continuous Publication Track, it is intended that after 4.7 years, a snapshot will be taken to Recommendation.

For a feature to be considered final by the working group (on either track):

it must be testable by a test in the Agricultural Products Test (APT) suite at (URL goes here)
there must be at least 3 complete implementations
at least 2 of those implementations must pass the applicable APT tests
at least 1 of those implementations generates packed olives, and at least one uses packed olives, and they interoperate

Features that do not meet these requirements will be integrated first as provisional, and a second Pull Request made to change them to non-provisional, when the requirements are met.

Sample Document Header

Olive picking, pitting, curing and bottling.

W3C Evergreen Standard 15 March 55BCE

Latest version: (URL to the evergreen standard goes here)

Permanent link to this version: (URL for this exact version goes here)

Repository: (URL to the Github repository for issues etc.)

Editors: (Editors listed by name)

Current unresolved Patent Licensing Exclusions: none, or a URL to the exclusion plus a URL to the PAG information

Current unresolved Formal Objections: none, or a URL to the Formal Objection filing

Abstract: (as usual)

Status of this document:

This document is developed by the (link to Working Group). Comments and issues are welcomed and should be filed at the (URL to the issues page of the Github repository).

This document was produced by a group operating under the W3C Continuous Publication process and policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

The disclosure obligations of the Participants of this group are described in the Working Group charter.

Detailed explanation of the Continuous Track Patent policy

Looking for input from PSIG.

Summaries for various constituencies

Lawyers

(needs editing to match the snapshot model)

Lawyers will need to take roughly the following steps:

Review the charters of the working groups that your organization intends to participate in.
Collect, from the charters, the URLs of the Continuous Publication repositories and add them to your 'watch list'.
When you join a working group, review the most recent snapshot and file any applicable exclusions, within the deadline.
When snapshots are made, review it and file any applicable exclusions, within the deadline.
Watch other exclusion filings, of course; take any steps you think indicated, and consider joining the PAG.
Optionally, if you want early notification of changes, watch the monthly automated reports of Pull Requests, or get automated immediate notification by GitHub of Pull Requests, for repositories in your watch list.
When you leave a working group, do a final exclusion check on the working draft that was current as of the time you left the group.

Working Groups

Working groups need to do the following:

Create Github repositories for your documents on the Continuous Publication track before writing your charter.
Define clearly in your charter the documents on the Continuous Publication track; list the URIs of their repositories.
Define clearly in your charter what requirements a feature must meet to be considered acceptable (testing, implementation, interop, etc.).
Watch Pull Requests and make sure:
- that Pull Requests are correctly tagged (editorial, minor, or, by default, substantive);
- that if Pull Requests add to 'core draft' (ie. material that is not an erratum report, provisional, or editor's note) that the addition meets the WG requirements (testing, implementation, interop, etc.).
Watch issue filings and tag those also.

Editors

Editors need to make sure that material that is provisional, an erratum report, or an editor's note, is correctly tagged, and that tags are removed when the material becomes final. If a new feature is too complex to be inserted inline as provisional, manage separate "editor's drafts" that the WG can review until such time as they agree to merging. Check that the 'core draft' reads correctly as well as checking the entire document.

If there have been any technical changes since the last snapshot, make a new snapshot no later than 180 days after the last one.

Other Groups

Read the automated reports and review the changes as they happen. File an issue with at most 180 days if there is a problem. Raise a Formal Objection, ideally within 180 days, if impasse is reached so that Chairs can facilitate a discussion and (if necessary) the Director can get involved if needed to resolve disagreement.

Team

The team:

makes sure the process is followed, Charters are correctly drafted, etc.
makes sure that the Pull Requests (and issues) are tagged correctly, and that technical changes meet the charter requirements;
makes sure that snapshots are made if technical changes have occurred since the last snapshot, and 180 days are about to elapse;
ensures that the comments from outside the WG are given due and timely consideration by the WG (notably, within the six months tacit acceptance period);
when an exclusion is filed, the PAG is formed, notifications sent, and the document header updated (and removed when the PAG is completed);
when a Formal Objection is filed, notifications sent, and the document header updated (and removed when the Formal Objection is resolved).

Use Cases

Possible use cases include:

Accessibility API Mappings (see https://github.com/w3c/w3process/issues/79)
Vocabularies. Most vocabulary definitions have little IPR contention, and grow in a natural incremental fashion.
Registries. Similar reasons to vocabularies
Profiles of the Web Platform (e.g Web Media). Profiles of the Web Platform involve little spec development, but indicate which portions of the standards are most appropriate for industry segments.
Maintenance. Maintenance of specification by nature is intended to track evergreen incremental enhancements rather than bold new features; plus have less IPR contention.
Core infrastructure. Some specs provide core infrastructure for other specs; but may not need to reach a level of Recommendation per se. Web IDL might be an example.
Incremental guidance. Specification such as WebAppSec seem well suited for an incremental or evergreen approach.
All specifications. Some feel that an Evergreen approach is a best fit for all specs.

Documents and their status

What is W3C recommending in an ER? What should developers do with it? What can developers depend on, and what risks are there?

Status of several kinds of W3C documents

For each type of document W3C produces, it conveys "status" of the document based on the process used to generate the document.

Community Group Specifications. These documents have no particular W3C status, although the individual contributions come with a level of patent protection through the W3C CLA.

Community Group Final Specifications. These documents have no particular W3C Status, although the entire specification comes with enhanced patent protection through the FSA agreement that may be signed by participating organizations.

Working Group Working Draft. These documents have no particular W3C status, but they are guaranteed to be within the scope of a WG approved by the Director after review by the AC.

Working Group Candidate Recommendation. These documents, like Working Drafts are within an approved scope. Additionally, they:
- Have met the requirements of the WG, or explained why the requirements have changed.
- Have addressed issues raised
- Represent the consensus of the WG
- Have a plan to demonstrate implementation experience
- Have received wide review (including horizontal review)
- Have received Director's approval for this status

Working Group Recommendation. These documents have all of the status attributes of CR documents. They have the additional status of:
- Have demonstrated implementation experience
- Have W3C Royalty Free licensing commitments associated with the specification.
- Have received AC review of the spec
- Have ensured that all Formal Objections are resolved through Director review
- Have an Appeals process if the AC disagrees with the Director
- Represents a stable reference.
- Has been adopted

Proposed Evergreen Recommendations
- Are within the approved scope of a WG
- Represent the consensus of a WG (driven by the editor with oversight from the WG chair)
- Have demonstrated implementation experience
- Have received incremental wide review (including incremental horizontal review)
- All key horizontal issues have been resolved
- Have ER contribution Patent Commitments associated with the spec

Thus the ER has achieved much of what the community is looking for and hence W3C confers it with the status of ER which both informs the community of what they can rely on, and also establishes where there is incompleteness.

The most serious incompleteness is the incompleteness of patent commitments. Accordingly, it is expected that the WG will on a regular basis (e.g. every 12 months) create an ER Snapshot which gets the benefit of full patent commitments for the ER spec.

Proposed ER to REC, adds
- Full wide review (including horizontal review)
- Director approval
- Received an AC review of the spec
- Ensured that all Formal Objections are resolved through Director review
- The benefit of an Appeals process if the AC disagrees with the Director
- A stable reference.

Different Evergreen Models

There is a choice between a ‘snapshot' and sliding-window model, for both IPR review and functional review. What we have here is hybrid -- sliding-window for the technical reviewers, snapshot for the IPR.

This is like the WHATWG process which requires a periodic manual "review draft" ('snapshot') approximately every 6 months, and at that time all the legal reviewers have 45 days to respond. WhatWG doesn’t have liaisons, cross-functional groups, an Advisory Committee, or Director/team.

In the sliding-window model, we deem all the technical groups (external, cross-functional, Advisory Committee, and Director/team) to have tacitly accepted features 180 days after they first appear, unless they file an issue. This incremental tacit acceptance is sufficient for W3C to confer status on an ER that there is sufficient review to be reasonably confident that a feature is stable and can be implemented. But it is less than the status associated with a full W3C Recommendation which has had wider and more complete review.

If an issue has been raised, the editor has the lead role to address the issue and re-establish consensus. This is discussed in: Roles and Responsibilities

There is little functional difference between “We’ll keep you informed of the grocery list as it builds, and you must do your grocery shopping at least once a week” and “You must do your grocery shopping immediately when the editor issues the weekly shopping list” — it is the same amount of work, at the same frequency; but the former allows you to choose when, and indeed spread it out if you want to, while the latter says “jump now”. But there is a difference of work-mode.

Comparison of the Continuous and Traditional Recommendation Tracks

Concept	Continuous	Traditional
wide review	Incremental, by automatic notification and lack of objection. Not verified.	Incremental, by notification and lack of objection. Verified on Transitions.
horizontal review (i18n, a11y, security, privacy, perf, device independence, TAG, etc.)	Incremental, by automatic notification and lack of objection. Not verified.	Incremental, by notification and lack of objection. Verified on Transitions.
Advisory Committee review	Incremental, by automatic notification and lack of objection. Not verified.	Incremental, by notification and lack of objection. Verified on Transitions.
tests	Defined in charter, verified by WG and reviewers incrementally	Defined in charter, verified by WG and reviewers on transitions
issues addressed	Addressed incrementally. Not verified.	Addressed incrementally. Verified on transitions.
IP	Whole spec from all WG members given exclusion opportunity at a snapshot	Whole spec from all WG members at Rec
consensus	evaluated by the editor	verified by the chairs according to the conventions of the group
errata	In issues and possibly inline	In issues and possibly inline
maintenance	Ongoing	Episodic
use cases	In charter or requirements document (which may also be Continuous)	In charter or Wiki or somewhere
requirements	In charter or requirements document (which may also be Continuous)	In charter or Wiki or somewhere
implementation commitments	Requirements defined by charter	Requirements defined by charter
implementation experience	Requirements defined by charter	Requirements defined by charter
Director's approval	Incremental, tacit unless objections raised	By proxy on transitions
Appeal process	After Formal Objection	After Formal Objection
stable reference	By using specific revision references or periodic Rec snapshots	Normal
adoption	Requirements defined by charter	Requirements defined by charter
status duration	Indefinite	Indefinite