Limitations of W3C Recommendations in 2019

• Any substantive change or addition to a Recommendation required to go back to CR or FPWD respectively (“A single line change can send the entire document back to CR”)
• For long-running specifications (CSS Text Decoration Module Level 3, WebRTC 1.0, etc), early implementations are not guaranteed to be Royalty-Free for years, until it reaches REC. (“WebRTC is getting adopted but it’s not yet Royalty-Free”)
• For technologies deep in the Open Web Platform stack, algorithms need constant updates for maintenance and security purposes and REC versioning is confusing to implementers who needs to stay as close as possible to the latest updates (“there can be only ONE spec”)
• Some Groups maintain built-in consensus/testing on editor’s drafts, but fulfilling all the requirements of the REC-track to update /TR can take months, thus creating a significant lag/confusion (“Don’t look at the document on w3.org, use w3c.github.io instead”)

37 Working Groups with standard stories

• Some standard stories must be fixed in time before they can be adopted (WCAG 2.1)
• Some standard stories need to be up-to-date at all times and previous/yesterday draft must not be adopted (Service Workers, SVG, etc.)
• Some standard stories are somewhere in between, for example:
  • Referencing and/or implementing the previous version may make sense in some cases (ARIA 1.1 mapping, WCAG 2.0, Pointer Events 2, TTML 1, etc.)
  • The latest drafts have no tests or implementation commitment anyway
  • Previous versions are automatically obsoleted or superseded once a new REC is produced anyway

It’s all about trade-offs with what we value most

• Maintaining Group consensus
• Ensuring that Wide and Horizontal Reviews are happening
• Resolving Formal Objections in a timely fashion
• Asking the AC and the Director to validate
• Securing Royalty-Free on a regular basis
• Getting implementation commitments and/or experience
• Keeping our Standards up-to-date on w3.org

Process 2020 Recommendation track

• Enable Working Group to map their standard stories to an enhanced REC-track: from living standards to well-established standards
• Secure Royalty-Free early to protect early implementers/adopters
• Subtle balancing between keeping our current values and embracing new values
  • Changes were additive: Previous REC-track work-mode is still an option

2020: Patent Policy and Process

• Secure Royalty-Free as early as possible (with Call for Exclusions)
• Enforce checks on wide and horizontal reviews
• Enable Living Standards without preventing today’s workflows
• Don’t force a specification to go back to CR/FPWD if you can update the REC directly
• Be agile

REC-track 2020

To be a Recommendation, or not to be?

Living Standards, aka CR forever:

FPWD, WD*, (CRS, CRD*)+

Stable normative reference (versioning):

FPWD, WD*, (CRS, CRD*)+, PR, REC

Living Recommendations, aka REC forever:

FPWD, (WD*, CR)+, PR, REC+

Note: it’s possible to adopt a mixed approach

On Versioning

• Version Management in W3C Technical Reports
• We outdated automatically past publications of a given version
• You may obsolete/supersede old versions in newer versions
• Our API now knows about versioning (eg Pointer Events). Make sure the data is correct.

Check the board of your working group

On Updating a Recommendation

• Markup changes: change in place
• Editorial changes: publish a new dated version of the Recommendation
• Substantive changes:
  1. Publish a new dated version of the Recommendation with candidate and/or proposed changes
  2. Incorporate proposed changes after review (with Director's approval)

Publish and Maintain your W3C specifications

W3C has a Process and toolings that allows Groups to easily maintain their specifications published in /TR.

You can:

• Publish using Echidna. Ask if you need help setting up automatic publication.
• Find out what your options are using the step finder (eg webrtc or JSON-LD):
  • Make corrections and adjustments to existing features in Recommendations unconditionally
  • Update your Candidate Recommendation if the Working Group insteads to include the materials in a subsequent Snapshot

Reviews

• Check out Horizontal review and approaches to security review
• The Web is for All and we should preserve the social value of the Web
• Maintain your specification and make sure the World knows about it
• Horizontal Areas: Internationalization, Privacy, Security, Web Accessibility, Web Architecture
• All Working Drafts ought to be reviewed: How to do Wide Review
• Community Groups may also request reviews!

Wide review: when?

• The earlier, the better. The perfect is the ennemy of the good enough.
• Community Groups may also request reviews!
• If you made substantive changes since last review, request again
• If you didn't have a review in the past 2 years, request again

Wide review: How?

1. Horizontal Groups are providing self-review questionaires. Use them!
2. Indicate that your document is ready for wide review in the status of your document
3. Reach out to the Groups listed in your charter, W3C and external groups
4. Reach out to the horizontal groups, per How to get Horizontal review

The W3C Director makes sure the Group offered a reasonable opportunity to review.

Tracking horizontal issues

w3.org/PM/horizontal/

• Leverage GitHub labels across 285 repositories (see full list):
  • -tracker to have an issue in an horizontal radar
  • -needs-resolution to indicate the horizontal group wants the issue resolved
• 482 comments are being tracked by our tools (out of 12,784 open issues)

Facilitating Transitions

github.com/w3c/transitions/issues

• Transition requests are tracked on GitHub
• Provide a single form to submit transition requests
• Automatic transitions are part of Process 2020
• Reduce the administrative and Director overhead
• If no formal objections nor *-needs-resolution, Group gets approved to publish a new Candidate Recommendation Snapshot

More information

• Guide
• Links and tools to manage our Working Groups
• When in doubt, ask your team contact or plh@w3.org