Continuous Standards Development

Process 2020 Proposals - TPAC 2019

Background

2

Where can the REC track be improved?

1. 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.
2. Patent Commitments are only secured at REC status, after implementation.
3. 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.

​

3

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

4

Motivating Examples

Issue #79 raised the following specs:

1. ARIA: ARIA Mappings
2. SVG: Beyond SVG 2
3. WebAppSec: CSP
4. Web Performance: performance timeline, …
5. Web Platform: WebIDL
6. Dataset Exchange: Beyond DCat 1.1
7. Timed Text: TTML Profile registry
8. Distributed Tracing: Trace Context Protocol Registry
9. WebRTC: registries
10. WebApps: Manifest, etc.
11. Service Workers: Beyond SW 1
12. CSS: 100 specifications and counting...

5

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

​

​

6

Design Intentions

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

• Creating an experimental new Process for spec development (Alternative Track)
• Can radically change the Process in all aspects
• Avoids altering the REC track
• Improving the W3C Recommendation Track Process directly
• 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

�Note: Fixing the W3C Recommendation track while experimenting with a simple continuous process are not in opposition

7

Proposal for Improving the Recommendation track

8

Process Improvements Package

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

9

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?

10

Proposed Fix: Streamlining Routine CR Republication Approvals

Problem: Updating 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

11

Proposed Fix: Decoupling CR update from CR snapshot

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, triggers patent review
• CR Update Publication can be published by the WG without approval, no patent review
• Changes since last Patent Review Draft can be tracked to facilitate review
• Spec header adds links to previous Review snapshot as well as previous [any] publication.

12

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.

​

13

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?

14

Additional Fix: Dedicated Registry Process

Problem: Registries need lightweight update process, possible maintenance outside a WG.�Currently: W3C only has NOTEs (have no normative status) and RECs (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 publications that conform to registry definition can be published instantly.

See separate AC presentation at https://www.w3.org/2019/Talks/TPAC/ac-registries/

15

Process Improvements Package Summary

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

�

16

Impact

17

Impact on Working Groups

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

​

18

Impact on Legal Teams & Advisory Committee

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

​

19

Impact on Horizontal Review

1. 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
2. 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.

20

Impact on Implementers and Users

1. Early implementations get W3C RF commitments
2. Official specifications (on w3.org) reflect latest WG thinking.
3. Improved maintenance brings W3C Recommendations closer to reality.
4. Granular reviews of proposed changes to Recommendations.

21

Additional Alternate Track?

22

Motivations for Alternative Track Proposal

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

• Is AC willing to change the W3C Recommendation track, including its W3C Patent Policy?
• Should there be a way to have official status without formal approval process?
• Can we make Horizontal Review more continuous?

Reasons to adopt the “Evergreen Recommendation” alternate track:

• If AC won’t change Patent Policy for REC track, but will for an alternative track.
• If WGs that want Living Standards/continuous development find proposed fixes to REC track insufficient for their needs.

23

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?

24

Impact of Evergreen Track

Working Groups:

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

Horizontal Groups:

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

​

​

25

Impact of Evergreen Track

Advisory Committee:

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

Implementers and Users:

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

26

Next Steps

27

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?

28

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 REC Process: Which proposals should we adopt?
• Streamlining Routine CR Update Approvals
• Decoupling CR Updates from CR Review Drafts
• Inline Errata Proposal + Approval Process for modifying RECs
• Extensible RECs to allow adding new features
• If we improve the REC Process, is an Alternate Track still necessary?

29