Process 2020

Florian Rivoal (frivoal)
&Elika J. Etemad (fantasai)

Background

Motivation: Problems

Motivation: Evidence

Constraints: W3C Values

Goals

Design Principles

Motivating Examples

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

Proposal

Process Improvements Package

  1. Streamlining Candidate Recommendation updates
    1. Allow easy CR "Drafts" between rigorous CR snapshots
    2. Automate routine Director’s approvals
  2. Streamlining Recommendation updates
    1. Add amendment process for bug fixes
    2. Allow adding features to designated Recommendations
  3. Dedicated Registry Process Rescheduled for 2021!
  4. 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.

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:

Proposed Fix: Modifying a Recommendation

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

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

Proposal: Create an errata proposal + approval process:

Proposed Fix: Allow Adding Features to a REC

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:

See separate presentation on the Patent Policy

Process Improvements Package Summary

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

Impact

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:
    Full specification commitments at the end of each exclusion period, starting at CR

Impact on Advisory Committee & Legal Teams

  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. Full specification commitments earlier than REC, at CR

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.

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