Continuous Standards Development

Elika J Etemad
&Philippe Le Hégaret

Background

Where can the REC track be improved?

Maintaining and evolving a Specification is difficult:
1. Continuous development means tracking reality is a never-ending task. Declaring a spec as a REC by pulling out not-yet-normative features is burdensome.
2. Bug fixes can appear at all times and may need to be addressed urgently (security fixes).
3. Multiple transition requests and TR publications take extra time/resources.
Patent Commitments are only secured at REC status, after implementation.
Registries aren’t well handled and are all over the place (RECs, NOTEs, wikis, web pages).

WHATWG’s Living Standards and the W3C / WHATWG collaboration agreement give insight on how to do continuous standard development while fulfilling requirements of the W3C REC track.

Use Cases

Vocabularies, Mappings: Most have little IPR, and grow in a natural incremental fashion.
Registries, Profiles: Mostly no IPR commitments, incremental updates
Maintenance: Bug-fixing of stable specifications with minimal overhead
Continuous Enhancement: Incremental development one feature at a time
Rapid Development: Security improvements
Tracking: Coordinating update with other living standards, e.g. Fetch integration

Motivating Examples

Issue #79 raised the following specs:

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
WebRTC: registries
WebApps: Manifest, etc.
Service Workers: Beyond SW 1
CSS: 100 specifications and counting...

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 Intentions

The AB has resolved to address the continuous development on an accelerated basis and the W3C Process Community Group has explored several approaches.

Recommendation Track has problems, so let’s fix them!
Incremental improvements as a set of ideas that could be adopted individually or together.
Building on existing Process avoids undiscovered pitfalls of a brand new process track.
Avoid confusing community with a different, parallel track.

Proposal

Process Improvements Package

Updating the Patent Policy
Streamlining Candidate Recommendation updates
1. Automating routine Director’s approvals
2. Decoupling CR update publications from patent review drafts
Streamlining Recommendation updates
1. Inline Errata + Review of Proposed Changes process
2. Allow adding features to Extensible Recommendations
Dedicated Registry Process

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 each contribution, by the contributor, at the time of contribution
on full specification, by all WG participants, at the end of each exclusion period

Key Questions: Can we change patent policy? Do we need to experiment? Answer AC survey on Patent Policy!
How early should we apply full-specification licenses? CRs only, or WD updates well? Do we need contribution licensing, or only full-spec licensing?

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: Decoupling CR updates from 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 authoritativeness of W3C’s official publications.

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

Proposal: Decouple update publications from review publications:

CR Snapshot publication requires wide review, Director's approval, trigger patent review
CR Update Pubication can be published by the WG without approval, no patent review
- Changes since last Patent Review Draft 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 changes without destabilizing the 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 changes.
Updated REC - Reviewed changes can then be folded directly into an updated REC.

Proposed Fix: Allow Adding Features to an Extensible 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 into specifications chartered to be extensible.

Note: Current proposal requires distinguishing extensible RECs from feature-stable RECs.

Key Question: Do we want to allow a W3C Recommendation to evolve with new features?

Additional Fix: Registry Process

Problem: Registries need lightweight update process, possible maintenance outside a WG.

Currently: W3C only has NOTEs, which have no normative status, and RECs, which are hard to update.

Proposal: New type of technical report for W3C Registries:

Defines registry definition: type/scope/format of entries, process to add/modify/delete.
Registry publication: incorporated as HTML tables or CSV in /TR publication
Dated URL provides dated contents; undated URL provides latest contents. (Just like any table in a spec today.)
No IPR commitments on registry publications.
Updates to registry publication that conform to registry definition can be published instantly.

See separate AC presentation

Process Improvements Package Summary

Updating the Patent Policy
Streamlining Candidate Recommendation updates
1. Automating routine Director’s approvals
2. Decoupling CR update publications from patent review drafts
Streamlining Recommendation updates
1. Inline Errata + Review of Proposed Changes process
2. Allow adding features to Extensible Recommendations
Dedicated Registry Process

Impact

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
1. Contribution commitments on ongoing basis
2. Full specification commitments at the end of each exclusion period

Impact on Legal Teams & Advisory Committee

AC/Patent reviews would be more frequent but with finer granularity
- Formal patent / AC reviews rate-limited to approximately once per six months
Group Participants are making ongoing contribution commitments
Full specification commitments earlier than REC
- Open Question: At CR or at WD?

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.
Granular reviews of proposed changes to Recommendations.

Additional Alternate Track?

Motivations for Alternative Track Proposal

Process CG originally tried developing an alternative track proposal. Concerns motivating it were:

Is AC willing to change the Patent Policy for REC-track specifications?
Should there be a way to have official status without formal approval process?
Can we make Horizontal Review more continuous?

Reasons to adopt this Proposal:

If AC won’t change Patent Policy for REC track specifications, but will for an alternative track.
If WGs that want continuous development feel the proposal package is insufficient.

Proposed Addition: “Evergreen Recommendation” Track

Goal: Allow experimentation on alternate track instead of applying changes to the REC-track.

Proposal:

Allow a Working Group to continuously update its ongoing specification. Unless there is a formal objection, the Director will not get involved.
Features added within 180 days get reviewed at reviewer convenience.
Features that have adequate implementation experience and have been in for 180 days or more are recommended
Snapshots published every 2 years or less, to secure full-specification commitments.
If classical W3C Recommendation status is desired, transition to the REC track, then go through CR/PR/REC as usual
Separate track means no change to main W3C REC track Patent Policy, but requires adopting new patent policy at least for Evergreen.

Key Question: Would we benefit from an Alternative Experimental Track?

Impact of Evergreen Track

Working Groups:

Wide reviews are assumed to be continuous
Full specification commitments can be requested without Director approval
New alternative status outside of the Recommendation track
No transition requests to provide oversight

Horizontal Groups:

Horizontal Groups need to track specification changes within 180-day review windows
No checks for completing horizontal review; WG is responsible to do the right thing

Impact of Evergreen Track

Advisory Committee:

Full specification commitments earlier than REC
No AC Reviews unless transitioned to the W3C Recommendation track

Implementers and Users:

New alternative (confusing?) status outside of the Recommendation track
Early implementations get earlier patent commitments
“Evergreen Recommendations” get closer to reality

Next Steps

Questions to WGs

Do we address the needs of WebIDL, WebAppSec, ARIA Mappings?
Will it be easier to maintain CSP, SVG, CSS, etc?
Are Horizontal Groups able to keep pace with more frequent spec updates?
Are Editors willing to keep track of all substantive changes between CR review drafts?
Is it easier for registries?

Questions to the AC

Updating the Patent Policy
1. Can we update the Patent Policy? How would we apply it? ANSWER AC SURVEY
2. Do we want full-specification licenses on WD or just CR?
3. Do we want contribution commitments in addition to full-specification commitments?
Improving the Process: Which proposals should we adopt?
1. Streamlining Routine CR Update Approvals
2. Decoupling CR Updates from CR Review Drafts
3. Inline Errata Proposal + Approval Process for modifying RECs
4. Extensible RECs to allow adding new features
5. Registries Process
If we improve the REC Process, is an Alternate Track still necessary?