Maintainable Standards

Introduction

The W3C REC track currently makes it very difficult to maintain Recommendations. One proposal is to replace the entirety of the Process with a different process modeled on the WHATWG. This satisfies the goal of continuous development and maintenance of features, but does not provide the same rigorous framework for wide review and consensus as the current Process, relying solely on well-behaved editors to "do the right thing" and assuming lack of engagement as approval by the rest of the community.

The goal of this proposal is instead to use the current Process as a framework, but to improve the points on which it is currently so unweildy as to prevent continuous maintenance.

Concrete wording for this proposal can be found at:

An overview of the proposed changes and their intentions and motivations can be found below. An overview slide deck from TPAC 2019 is also available.

Patent Protections

Currently the W3C Patent Policy guarantees Royalty-Free patent licensing for any Essential Claims related to implementing a Recommendation. It provides several opportunities for Working Group participants to exclude their claims during development, but does not provide any licensing until the document is completed as a Recommendation.

By contrast, the Community Group and WHATWG patent policies contribute licenses on contributions, providing protection from the moment the IP is contributed to the standard.

Proposal

Streamline IPR contributions from external contributors by providing a contributor license grant system (similar to the one used by participants in Community Groups or WHATWG), to make implementing W3C process section 6.2.6 Contributor License Grants more straightforward and, therefore, likely. [Currently in progress by the W3C Team!]
Adopt a CG-style contribution license in addition to the current Patent Policy protections.
Bring patent commitments in force at the end of each exclusion opportunity after the initial transition to CR, rather than only after the transition to REC.

These last two changes can be offered as options for a Working Group charter (similar to how the Evergreen Standard proposal intended itself to be invoked as an option through a WG charter), and possibly in the future, adopted by the AC for all Working Groups. There is currently an open poll to the AC about options for applying such a newly-developed patent policy. See also ongoing work on drafting a new Patent Policy.

References:

WHATWG IPR Policy's 5.2 Contribution Licensing Obligations and 5.6.1 Disclosures Regarding Contributions.
W3C Community Group IPR policy
W3C’s currently-active Patent Policy

Candidate Recommendation Maintenance

Updating a Candidate Recommendation takes weeks (in practice) due to the requirements for personal signoff followed by manual publication, which are at the mercy of multiple W3C Team members' schedules. The difficulty of getting these specs updated on /TR is a frequent source of outdated "official" specs. However, while the current very manual process is onerous, the checks it provides are valuable.

Proposal

Part A: Streamline CR updates

Automate the Director's approval stage for the clear-cut cases (and automate publishing with Echidna), leaving the involvement of the W3C Team for more complex or ambiguous cases (or WGs that particularly need more active guidance).

A simple way to do this would be to have a WBS form that records the checkoff of the various requirements of a "clear-cut" case of approval, e.g.:

No objections or rejected comments where the commenter seems displeased.
Existence of a detailed Changes section and/or Disposition of Comments
Horizontal review sign-off on changes from i18n/sec/TAG/a11y if needed [with sub-checklists for whether these are explicitly needed -- for updates with only small changes that have no i18n/sec/architectural/a11y implications, this shouldn't require explicit review by the unaffected groups]
No new features
Solicited appropriately wide review (more review for larger changes, less needed for minor tweaks)
No (new) patent disclosures
Each addressed comment has been replied to and the commenter given an opportunity to respond/reopen the issue. (We can allow the timeout on such responses to be after the current publication, so long as the WG response makes it clear that the commenter is allowed to respond/reopen the issue and the WG has a process for ensuring that this response is evaluated for further action.)

Consider adding some periodic W3C Staff check on whether issues are being ignored by the editors/WG rather than properly and consistently addressed.

Part B: Decouple regular updates vs review snapshots

Decouple CR publications from CR transitions by adopting the Evergreen model of continuous publications + snapshots. Specifically,

After the first CR publication (which is a Patent Review Draft and also invokes the traditional transition process), the Working Group can update the CR essentially at will.
Periodically, the WG issues a CR that is also a Patent Review Draft. Like the initial CR, this publication needs to go through the transition process [possibly streamlined per Part A, above], to ensure that the changes have received wide review, etc.

Substantive changes since the last PRD should be continuously documented.
Review Drafts should be issued every 6-12 months if there have been substantive changes, and must be issued at least every 24 months after such changes.

See EverTeal Proposal for background/rationale on this part.

Recommendation Maintenance

The 2005 W3C Process had a process for Modifying a W3C Recommendation, including substantive changes. They could be incorporated either by

Publishing them in a Proposed Edited Recommendation, which initiated a review period (without regressing the status of the spec as a “Recommendation” of the W3C). This would be followed by a re-transition to Recommendation indicating the acceptance of the changes by the Membership.
Requesting review of the proposed corrections, followed by republication of the spec with the proposed corrections inlined as an updated Recommendation.

This facility was removed in the Process 2014 in favor of pulling the specification back to Candidate Recommendation. While this is probably easier for the editor of the Process document, it creates a lot of unnecessary work for the WG and most especially the W3C Staff, has unclear implications for the patent commitments, takes way too long, and is definitely very confusing to the wider W3C community and the public.

Proposal

Simple Option: Restore the 2005 sections that allow Recommendations to accept substantial updates, with minor changes: to allow errata to be listed in an issues repository and proposed corrections to be annotated inline rather than necessarily listed separately on an "errata page", and to allow subsets of proposed corrections (those that are PR-ready) to be submitted for review. To clear up patent commitments, the review period would be made coincident with an exclusion period.

Review Snapshots Option: As above, but fold changes into the spec once they're PR-ready, submit for review using 6-month "review snapshots" of the Recommendation. Patent protection doesn't kick in until 60 days after the latest snapshot that has incorporated the relevant changes. Note: Requires changes to the Patent Policy to make certain contents of certain Recommendations subject to exclusion.

Continuous Option: Allow proposed corrections to be annotated inline, but mark them as "draft changes" until they satisfy CR entrance criteria. Transition those changes (via CR fast-path, or explicit approval) to "candidate change" which triggers a 7.5-month review/exclusion opportunity on the change. Fold them into the Recommendation once they satisfy CR exit criteria and the 7.5 month waiting period.

Extensible Standards

No W3C Process version allows the incorporation of new features into a Recommendation without a return to Working Draft. The reason for this is to ensure a truly “wide review” by the wider community, not just focused review by a handful of deeply involved participants and some designated W3C horizontal topic experts from i18n/a11y/security/TAG. However, some groups do want to maintain standards that continuously evolve and grow as a single document rather than a series of levels and modules. To satisfy these cases, the W3C REC track would need to allow the addition of new features (Class 4 changes.

Proposal

Allow the incorporation of Class 4 changes (new features) under similar provisions as Class 3 changes (clarifications and adjustments to conformance), while emphasizing that the requirements include

Signoff from horizontal review groups (which should be either explicit or through satisfaction of some comprehensive checklist that they provide for automatic waivers).
Clear demonstration of wide review, where the requisite wideness of the review is proportional to the largeness of the change.
For changes that are not yet interoperably implemented (and are therefore annotated provisionally until they are), consider also requiring two implementation commitments.

Wrt how to demonstrate wide review, this is left open-ended: one possibility is of course to publish as a W3C Working Draft and take the spec through the REC track. However, other methods are possible. For changes under this incremental process, the Director will need to actively evaluate on a case-by-case basis until workable best practices that genuinely satisfy the requirements are established. (In no case should development of new features in an unannounced pull request with review by a handful of implementers, company-internal people, and/or WG members but no solicitation of input or involvement by the wider community be acceptable.)

Recommendations allowing Class 4 changes should be required to label themselves as such (since sometimes organizations want standards that don't allow such changes, so specs that don't intend to allow them should be able to guarantee that). The choice of whether to allow Class 4 changes should be, by default, at the discretion of the WG and up for review by the AC as part of the normal spec review processes, but can also be enforced for by a WG Charter if the AC so desires.

Registries

There has been extensive discussion on the need for easily-updatable Registries at W3C. It has been concluded that this problem should be separately solved from the issue of maintaining standards, since their requirements are somewhat different.

Proposal

Registries are developed through the normal standards track, and are published on /TR just like other technical reports, other than the changes detailed below.
Registries define an extensible/updatable table of items. They can be standalone or inlined into another standard. A single REC-track document can contain multiple Registries (i.e. zero or more).
The document or section defining the registry must
- state that it defines a Registry per the W3C Process
- define the scope and purpose of the registry
- define the fields of its table of items
- define the method and criteria by which changes are proposed and incorporated
The rules, format, and scope of the registry are all subject to normal REC-track reviews, and changes to the registry other than adding/removing/updating entries in the registry (such as changes to its updating rules) go through the normal REC-track change process.
However, adding/removing/updating entries in the registry can be done through a lightweight process identical to how we handle editorial changes: by simply republishing the document with those changes, subject to WG approval (which can be blanket approval for changes meeting certain criteria).
Also, adding/removing/updating entries in the registry must trigger some kind of notification system. (Which could be done by e.g. adding per-spec RSS feeds to /TR infrastructure, which would be useful for other specs as well.)

See Proposed Process Edits for Registries

Benefits of this Proposal

Re-uses existing processes for development and review of specifications.
Re-uses existing publication machinery.
Addresses all archiving concerns wrt stability of URIs across time and provision of historical data.
Solves issues around finding (since the registry is hosted in a standardized location by W3C) and referencing (since there are both dated URLs and latest URLs)
Does not overly-constrain the presentation of registries, since the spec editors can decide how they are formatted in the HTML and also post data files in however many convenient formats they want together with the publication.

Note: The one thing /TR is not good at is doing interesting queries against a large registry of values, but the types of queries one might want to do will vary by the registry so that is better handled by external services (which could be informatively linked from the /TR report) than by creating some new standardized service.