Process 2020

Presenter: Florian Rivoal (frivoal) & Elika J. Etemad (fantasai)
Duration: 24 min

All talks

Slides & video

Keyboard shortcuts in the video player
  • Play/pause: space
  • Increase volume: up arrow
  • Decrease volume: down arrow
  • Seek forward: right arrow
  • Seek backward: left arrow
  • Captions on/off: C
  • Fullscreen on/off: F
  • Mute/unmute: M
  • Seek percent: 0-9
    1st
Slide 1 of 22

Process 2020

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

Hi! This is fantasai. Florian and I are going to talk today a bit about the W3C Process proposal for 2020.

Background

For those of you who don't know, the Process is the governing document for the standardization activites at W3C. The proposed update for 2020 represents some of the biggest changes to the Process in many years. The purpose of this presentation is to help you, the AC, understand the motivation behind these changes as well as the nature of the proposed changes themselves. The Process 2020 proposal is currently under informal review in the AC, so please study the materials and send us your questions and comments for consideration. We will be putting the revised Process forward for formal ratification by the AC after this comment period ends on May 31st.

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.

Specifications go through initial periods of development and evolution, and as they stabilize, gradually transition to maintenance. W3C’s Process currently has deficiencies in both phases.

For the development aspect, one major problem is that the current Process cannot easily represent the continuous model under which many software engineering teams now operate. Forking the specification into snapshot Recommendations that represent an arbitrary set of features passing implementation requirements at a given point in time is busy-work to such engineers, and the proliferation of copies increases the risk that the rest of the material gets out-of-sync with bugfixes.

Compounding this, for the maintenance aspect, every change to a Recommendation requires a lot of Process machinery that affects the status of the entire specification. Folding a single bugfix into a Recommendation requires three changes in maturity level and corresponding manual publications and communication efforts for the W3C staff; and by changing the status of the entire spec, it creates confusion about the maturity of the specification to its users.

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.

It is evident that the current W3C Process is not working as well as it ought to. We can see this in the number of out-of-date and unmaintained specifications, and in the way that work is shifting out of W3C Working Groups to other forums. Some projects have shifted out of W3C entirely, others are not formally adopted in a Working Group until implementations have already shipped, too late for significant feedback to be taken into account. And in many groups where work is still happening at W3C, the official specifications we publish on W3C’s own website are years out-of-date, with the active versions published elsewhere. This creates confusion regarding which publication implementers and reviewers should reference, and results in interoperability problems.

Clearly, we need to fix the Process. But in so doing, we want to also make sure we don't lose the qualities that make it valuable in the first place.

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.

W3C’s goal is to develop well thought-out, implementable, and relevant specifications. We value wide review, implementation experience, consensus, and royalty-free licensing as the means to that end. The role of the Process, ultimately, is to ensure that these values are deeply incorporated into W3C’s standards development practice; it exists for no other reason than to provide a repeatable framework for this.

It’s also important to note that the W3C community is very diverse. The Process needs to accommodate a wide variety of companies and industries, and to solicit excellence from both experienced standards experts in well-established Working Groups, as well as new participants and communities freshly started. To be a consistent, supportive framework, the Process needs both flexibility, and also formal structure. We can’t continue to demand that Working Groups conform to a process that does not suit their operational reality. But we also can’t just eliminiate all formalism in favor of informal cultural expectations and expect that to work.

As Tim Berners-Lee likes to say, the Process is a tool. If it's not useful, it needs to be adjusted. So in 2020, we are going to adjust the Process.

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

Our goals in adjusting this tool are:

  • to allow continuous development of specifications so that they can evolve in sync with their respective implementations
  • to simplify maintenance of existing and future W3C Recomendations
  • to secure patent commitments to protect the pioneering implementations who fulfill our requirements for implementation experience (as well as those that come after)
  • to reduce unnecessary bureaucratic overhead
  • to 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.

To implement these goals, we adopted the following design principles:

  1. First, the normative content of a W3C Recommendation must continue to fulfil the same requirements as currently. We are not proposing to reduce the value proposition of a Recommendation. It must still satisfy the existing requirements for wide review, AC review, implementation experience, and Director’s approval.
  2. Second, we resolved to make improvements to W3C's existing Recommendation Track for normative specifications, not to create a parallel track fulfilling the same purpose but under different process requirements and procedures.
  3. Third, we want to enable Working Groups to consistently maintain their intended implementation target as their officially published specification on w3.org, such that off-site Editor's Drafts are no longer needed in a public-facing role. If we do not enable this in practical terms, we have failed as a standards organization: our purpose is to publish relevant standards, if what we publish on our own website is not relevant, what are we even doing?
  4. Fourth, we want to make sure that “wide review” as required in the Process invites the participation of the broader community, not just internal experts. Many people refer to review by horizontal working groups such as Internationalization and the TAG as “wide review”; but this is only part of wide review. Wide review also includes the broader public; that is why W3C has always published it's work in progress for free on the Web. If relevant review materials are only ever available in the depths of a GitHub repository, they are effectively hidden, and will not receive a truly wide review. Therefore Process 2020 attempts to ensure that new material can be published for wide review, not just after “wide review”.
  5. Fifth, we want to bring patent protection to early implementations and for continuously-developed specifications. Many W3C specs describe complex technology in extreme detail, and the refinement of these details takes place in the Candidate Recommendation phase, during which we invite implementations to help us figure them out and to prove the quality of the spec. We want these implementations to have the same protections as the later implementations that come after a specification has been ratified as a Recommendation.
  6. Lastly, we intend to improve on the existing Process, not to rewrite one from scratch. The W3C Process has served us well in many ways for over a quarter century; we don't want to lose the positive aspects of the existing Process we have in order to fix its deficiencies. Reforming the Process rather than replacing it reduces the risk of regressions, and also makes the transition to the new Process much easier. Every change we propose here is additive and independent: Process 2020 reduces the friction in many procedures and makes some new things possible, but existing ways of working will remain valid.

I hope this helps you understand why the Process and the Patent Policy need to change, and why we are proposing the specific changes that we are. And now I will hand off to my indefatigable co-editor, Florian Rivoal, to explain the changes in this package of reforms.

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

Hi, I'm Florian.

Now that we know why we'd doing this update, let's look at what it is that we're doing.

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

In order to address the problems fantasai just described, we're proposing a package of several improvements to the REC track. There is no strong coupling between them, so in theory we could choose to adopt only some parts of the proposal if we found something we didn't like about the rest. That said, the draft of Process 2020 that is currently available for review includes the whole set, as that is what we recommend adopting.

Before going into details about each part of the package, I want to note that there's one thing we had talked about previously which is not included: registries. In addition to improving how we work with specifications, the AB and Process CG also wanted to offer an official way of creating and maintaining registries. A combination of more disagreements than expected and limited participation means that this isn't ready yet. We very much hope to deliver this next year, so if this is of interest to you, I invite you to reach out to your favorite AB member, or to voice your opinion directly in the Process CG.

Now, onto what is in Process 2020.

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

When a Working Group wants to publish an update to an existing Working Draft, it can do so as long as members of the Working Group agree to. To transition a specification to Candidate Recommendation, it is heavier: since there are a number of criteria that need to be fulfilled in order to be allowed to claim the CR maturity, there is an approval step, where the W3C Director or his delegates manually evaluate the specification to decide whether it is ready or not. This is a useful exercise in quality control: going through it—or preparing for it—routinely helps catching things that might have been overlooked. It's also useful as a way of teaching the less experienced groups what the expectations are. So this is good, and we're not changing that.

However, if a Working Group has already published a CR, and wants to update it, today the same level of scrutiny with the same manual verifications apply. But while some updates are significant enough to merit this, many are quite minor and uncontroversial, and in those cases, this Director's approval is unnecessarily heavy, and gets in the way of frequent publications.

This brings us to the first improvement of Process 2020: in simple non-controversial cases, the Working Group does not need to ask the for the Director's Approval before publishing an update to a CR. How do we define "simple and non-controversial"?: There must be a recorded group decision. All changes must be documented. Horizontal Review Groups must have either approved the document, or stated that they did not need to review it, for instance because when they did review an earlier CR, they determined it was out of scope for them. For example, maybe if a specification involves no human readable text, no symbolic visuals, no date, etc, the i18n group could declare that there's nothing there for them to review, and that they don't need to be asked about it again. Another criterion is that all changes that have been made must have been with the agreement of the person who raised the issue, otherwise it cannot be claimed to be a non-controversial update. And for the same reason, there must be no Formal Objection.

If all this is satisfied and documented, so that people can check after the fact, then the Working Group can go directly from preparation to publication, without involving the Director. And if not, or if you want to, you can still do it old fashioned way.

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.
[Slide 12]

Even with that improvement though, updating a CR remains heavy. Whether you involve the Director or not, there's still work in documenting that the specification satisfies the criteria, and it's not only the Director who needs to be involved. Publishing a proper CR also triggers a patent exclusion opportunity, requesting the members' legal team to review the document. While it is justified, it means Working Groups cannot be continuously re-publishing a CR for every tweak that they make. But if they cannot, what they do instead is publish the Editor's Draft elsewhere, and ask everybody to work off that instead, which is bad for the reasons fantasai mentioned.

Here is the second improvement that Process 2020 brings: between formal CR publications, Working Groups will now be allowed to republish, as frequently as they want, the latest version of their work on w3.org/TR, as a CR Draft. This requires no approval, and does not trigger a patent exclusion opportunity, making it as lightweight as publishing an Editor's Draft or a Working Draft. The flip side is that the Patent Policy remains tied to the less frequent and more formal CRs, now identified as CR snapshots, so these still need to be published periodically.

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.

But that's only about the Candidate Recommendation stage. Eventually, as the specification and implementations mature, specifications become Recommendations. There too, maintaining an up-to-date official specification has been a problem. To make any normative change to a Recommendation, it must be taken back to CR, then to PR, then to REC again, with all the work that this entails.

Such Recommendations with fixes-in-Progress no longer appear as Recommendations on the W3C website, as they are now CRs, making it appear to the rest of the world that they are of a lesser quality, even though the opposite is true: maintaining a Recommendation makes it better, not worse.

Also, most Recommendations are large enough that there is usually more than a single issue to address. But if only some of the fixes have enough implementation experience to fulfill the Recommendation criteria, the specification may be stuck in CR again for a long time. The group could decide to maintain multiple copies, one with the latest work, one with only the fixes that are mature enough to be eligible to REC, but that's a lot of busy-work.

What generally happens is that groups find that it's just too much of a hassle, and while they do keep an up-to-date Editor's Draft somewhere, the official Recommendation stays unchanged and becomes irrelevant at best, and often even distracting or confusing. Also, work that is only in the Editor's Draft is not covered by the Patent Policy.

So the third improvement brought by Process 2020 enables Working Groups to maintain Recommendations in place.

As it is already allowed to republish a Recommendation without Director approval and without going through earlier maturities in order to make editorial or non-normative changes, this can be used to maintain any proposed change directly in the Recommendation, as informative notes indicating how the group intends to change the Recommendation when the proposed change can satisfy the Recommendation criteria. A Recommendation, with these informative proposed changes, can be republished as often as necessary, without prior approval, eliminating the need for the latest work to live elsewhere.

When some of these proposed changes become mature enough, Process 2020 offers a way to make them normative and be folded in the main text of the Recommendation. An AC review and patent review is called on the specification as it would be modified were these changes folded in, the checks that are expected during a transition, such as checking for wide review or adequate implementation, are done, and if they all go well, the Recommendation can be republished, with these previously "proposed" changes now formally folded into the normative text.

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.

Some groups, when they get to Recommendation and want to develop new features, create a new specification for that, and only maintain the previous Recommendation for bug fixes. Some other group find that separation constraining, and prefer to incrementally add features to a single specification, without creating separate version, or levels, or edition. Some groups even want to do a bit of both, using one strategy or the other for different documents.

Until now, when a specification reached Recommendation, adding more features not allowed. So the only two possibilities were either to create new specifications, or not never go to Recommendation and stay in CR forever.

The fourth improvement of Process 2020 is to allow the "proposed changes" process that was described in the previous slide to be used for new features as well as for bug fixes: annotate the proposed addition in place, in an informative section or note, update them in place as often as necessary to get them right, get review, get implementation experience, pass AC and legal review, fulfill all the transition criteria, and fold them in normatively.

There's one important note though: this will not be allowed in all Recommendations. Until now, Recommendations could not gain new features. Occasionally, this is considered useful, maybe a standard maintained by some other body normatively requires an implementation of a particular W3C Recommendation as part of their technology. Or maybe someone has a legal or contractual requirement to conform to a W3C specification. In such cases, unexpected additions of features to an existing Recommendation can be very unwelcome.

Because of this, feature additions to a Recommendation will only be permitted if the specification, prior to its first publication as a Recommendation, contained a statement saying that it expects to accept such feature additions.

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

The final improvement is not actually really a change of the Process, but a change of the Patent Policy to go along with this proposed improved Process.

Today, at each Candidate Recommendation, member companies are asked if they have patents they wish to exclude, and if they don't, they will promise to grant a license. But the actual licenses are only granted when the specification is issued as a Recommendation, which could be many years later, or sometimes never. And it's worth noting that we cannot get to Recommendation without having implementations first.

The essence of the to the Patent Policy change is that instead of waiting until Recommendation, the licenses would be issued at the CR stage, immediately at the end of the exclusion opportunity.

One note in passing: we had previously mentioned another possible improvement to the Patent Policy regarding licenses on contributions, but we did not end up pursuing it after all.

Getting into exactly how this updated Patent Policy works is the topic of a dedicated presentation, so I encourage those of you who care about the details of the Patent Policy to watch it as well.

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
So that's it for Recommendation Track improvements in Process 2020. Updates to CRs without the asking for the Director's approval in simple cases, publishing CR Drafts in place between the formal CR snapshots, a enabling bug-fixing of RECs in place, a way to add new features to Recommendations that want it, and patent protection starting from CR rather than from REC.

Impact

In practice, what does it mean for you? That depends on your role.

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

Members of Working Groups will find maintenance of Recommendations easier. They will be able to maintain the latest version of their specification on w3.org/TR without being blocked by Director approvals and without going back and forth between CR and REC, and they'll get patent protection sooner.

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

AC representatives and legal teams should expect reviews to be smaller, and more frequent, but no more frequent than every 6 month per specification.

Patent Licensing on the full specification will now start at CR, rather than at REC.

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.

Horizontal Review Groups are already under a heavy work load. The overall amount of work that will need reviewing does not fundamentally change, as that is mainly tied to how active working groups are. Also unchanged is the preference for Working Groups to solicit review early and to stay in close cooperation with the Horizontal Review Groups. On the other hand, as is the case for AC reps and legal teams, formal requests for singing off a specification as satisfactory to the Horizontal Review group as a result of the review should increase in frequency, here too with a maximum of once every 6 months.

While no particular new tooling is necessary for Process 2020, we expect that improved tooling will be important to support the productivity of Horizontal Reviews, and consequently of the whole Recommendation track to which they are essential.

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.

For the world at large, it means the W3C royalty-free patent licensing will kick in earlier and cover early implementations. It means the official version of the specification on the W3C website will be the up-to-date version reflecting the latest thinking of the working group, and that specifications will be better maintained. Finally, as proposed corrections and additions can be found inline in the Recommendations, reviewing each such change, in context, will become easier.

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.

I hope this shed light on what's coming. Now it's your turn.

Please review the draft of Process 2020 that has been circulated, discuss it within your companies or with other W3C members, and ask questions. Both editors of the Process Document, myself and fantasai, are happy to answer any question you may have, including scheduling calls with you or your team. En français si vous voulez. 日本語でも結構です。

There will also be a Q&A session in the virtual AC meeting.

If you think anything needs to be clarified or fixed in the proposed Process, please send you comments to the Process Community Group, before the end of May. The sooner you do, the better we can address your comments, before moving onto the official ballot to adopt Process 2020.

Thank you!

All talks