Motivation: Problems

Developing and evolving a Specification is currently difficult:
- Complex specs spend years in CR without patent protection as details are refined prior to REC.
- Continuous development means tracking reality is a never-ending task. Declaring part of a spec as a REC by pulling out not-yet-normative features is obnoxious busywork to engineers who work on a continuous basis.
Maintaining a Specification is currently difficult:
- Bug fixes can appear at all times, and may need to be addressed urgently.
- Multiple transition requests and TR publications take extra time/resources, demotivating maintenance of RECs.
- Switching status of RECs to accept changes also misrepresents spec maturity.

Motivation: Evidence

Out-of-date specifications hinder interoperability and understanding, yet many W3C specifications are either unmaintained, or maintained in unofficial publications, because posting official updates through the current Process is too burdensome.
Work is shifting out of W3C Working Groups to Community Groups and WHATWG because of these maintenance problems.

Constraints: W3C Values

W3C values wide review, implementation experience, consensus, and royalty-free licensing as a means of developing well thought-out, implementable, and relevant specifications.
Key role of the Process is to ensure these values are deeply incorporated into W3C’s standardization process.
W3C Process needs to be a supportive framework that solicits excellence from both experienced standards experts as well as new participants and communities in a wide variety of industries; therefore needs both flexibility and formal structure.

Goals

Allow continuous development of specifications
Simplify maintenance of existing W3C Recommendations
Secure patent commitments as soon as possible
Reduce overhead
Continue the W3C commitment to Wide Review and consensus

Design Principles

Contents of a REC must fulfill the same requirements as currently.
Maintain single Process track for normative specifications.
Enable WGs to consistently maintain intended implementation target as the official publication on w3.org/TR
Wide review invites participation of the broader community, not just experts.
Patent protection for early implementations and on continuously-developed specs.
Improve on existing Process, don't rewrite from scratch.

Motivating Examples

ARIA: ARIA Mappings
SVG: Beyond SVG 2
WebAppSec: CSP
Web Performance: performance timeline, …
Web Platform: WebIDL
Dataset Exchange: Beyond DCat 1.1
Timed Text: TTML Profile registry
Distributed Tracing: Trace Context Protocol Registry
WebApps: Manifest, etc.
Service Workers: Beyond SW 1
CSS: 100 specifications and counting...

Process Improvements Package

Streamlining Candidate Recommendation updates
1. Allow easy CR "Drafts" between rigorous CR snapshots
2. Automate routine Director’s approvals
Streamlining Recommendation updates
1. Add amendment process for bug fixes
2. Allow adding features to designated Recommendations
~~Dedicated Registry Process~~ Rescheduled for 2021!
Updating the Patent Policy

Proposed Fix: Streamlining Routine CR Republication Approvals

Problem: Republishing WDs is automatic given WG approval, but republishing CR requires Director’s approval. Most republication requests, however, are routine and don’t need much scrutiny.

Proposal: Allow automatic Director’s approval for straightforward cases, e.g.

Documented WG decision to publish
All changes documented
Horizontal Review groups have approved or waived their review
Resolution of each issue was satisfactory to commenter(s)
No formal objections

Proposed Fix: Allow CR Drafts between CR Snapshots

Currently: Updating a CR requires external verification of work and triggers a patent exclusion period. Accommodating these reviews slows updates. (Even if we speed up Director’s approvals, legal teams want infrequent patent reviews.)

Problem: CR publications lag, often significantly, behind WG’s current-work, reducing value and authority of W3C’s official publications.

Goal: Address use case of Living Standards: always up-to-date, periodic patent commitment

Proposal: Allow CR draft publications between CR snapshot publications:

CR Snapshot publication requires wide review, Director's approval, triggers patent review
CR Draft publication can be published by the WG without approval, no patent review
- Significant changes since last snapshot must be tracked to facilitate review
- Spec header adds links to previous Patent Review publication as well as previous [generic] publication.

Proposed Fix: Modifying a Recommendation

Problem: Fixing errors in REC requires returning entire spec to CR, re-doing Process from there.

Confuses users (because the spec “loses” REC status).
Excessive process & publication work for WGs and Staff.
Results in poorly-maintained RECs.

Goal: Make it easy to propose, review, and incorporate individual changes without destabilizing the entire REC.

Proposal: Create an errata proposal + approval process:

Inline Errata - Allow WGs to republish annotated RECs, noting proposed changes.
Review of Proposed Changes - Combine transition-like checks for wide review, adequate implementation, plus AC and patent reviews on proposed REC with selected changes.
Updated REC - Reviewed changes can then be folded directly into an updated REC.

Proposed Fix: Allow Adding Features to a REC

Some communities need a specification to represent a stable feature set.
Problem: Some communities need a specification to represent continuous development.

Currently: REC specifications cannot accept new features; a new level of the technology must be specified starting with a new FPWD.

Proposal: Re-use REC maintenance process for incorporating proposed changes (above) to also allow incorporating proposed additions.

Note: Only allowed if stated in the specification prior to first publication as REC.

Proposed Fix: Patent Policy Improvements

Problem: Patents licenses are only granted after REC, but implementations needed before REC.
Goal: Secure patent commitments earlier, without depending on meeting REC requirements.

Currently: We secure promises to license at each exclusion opportunity, but only licenses at REC.

Proposal: Secure licensing, rather than just commitments to license:

on full specification, by all WG participants, at the end of each exclusion period from CR onwards
~~on each contribution, by the contributor, at the time of contribution~~ not addressed in current PSIG update

See separate presentation on the Patent Policy

Process Improvements Package Summary

Streamlining Candidate Recommendation updates
1. Allow easy CR "Drafts" between rigorous CR snapshots
2. Automate routine Director’s approvals
Streamlining Recommendation updates
1. Add amendment process for bug fixes
2. Allow adding features to designated Recommendations
Updating the Patent Policy

Impact on Working Groups

Allow easier maintenance paths for its Recommendations (changes and additions)
Allow keeping CR publications in sync with latest edits, without waiting on Director approval
Secure Patent Commitments earlier than REC:
Full specification commitments at the end of each exclusion period, starting at CR

Impact on Advisory Committee & Legal Teams

AC/Patent reviews would be more frequent but with finer granularity
- Formal patent / AC reviews rate-limited to approximately once per six months
Full specification commitments earlier than REC, at CR

Impact on Horizontal Review

HR groups are already under a heavy workload
- Increasing frequency of review is good, but context-switching is costly.
- Improving tooling for more granular feature review is essential to success
Proposed fix continues to require demonstration of review at transitions/updates
- Tied to CR Review Drafts and REC Call for Reviews (rate-limited already for legal).
- Patent commitments may stall if review is slow, or if WG has failed to coordinate with HR.

Impact on Implementers and Users

Early implementations get W3C RF commitments
Official specifications (on w3.org) reflect latest WG thinking.
Improved maintenance brings W3C Recommendations closer to reality.
Proposed changes to Recommendations get granular reviews.

Timeline

Informal AC Review: April/May

Review, study, discuss, and ask questions.
- Editors (Florian and fantasai) are available to discuss by email/IRC/voice call anytime.
Critique and send comments to W3C Process CG.

W3C Process CG prepares revised draft: June

Formal AC Ballot: June/July?

The sooner you send your comments, the earlier we can address them and move to a formal ballot for adoption.

Process 2020

Background