Enhancing the W3C REC Update Process for Greater Efficiency and Engagement

[marcoscaceres]

The updatable REC process at the W3C has historically been a source of significant frustration due to its complexity and the excessive manual work required from editors. This issue aims to address these concerns by proposing a series of alternatives that could potentially streamline or replace the current process.

Here are the challenges and a variety of proposed solutions for discussion at TPAC 2024:

Core Challenges

1. Complex Manual Markup: The requirement for detailed manual markup (e.g., <ins>, <del>, specific classes) is not only time-consuming but also prone to errors, frustrating many editors.
2. Detailed Change Tracking: Extensive documentation and linking for each change add unnecessary overhead, often leading to mistakes and confusion.
3. Inflexible Class System: The rigid classification system complicates the editing process and increases the potential for errors.

Proposed Alternatives

• Enhanced Automated Tooling: Develop tools that automatically generate the necessary markup from simpler inputs, reducing the manual burden on editors.
• Streamline the Existing Process: Simplify the current markup requirements to lower the entry barrier and reduce the time spent on updates.
• Educational Support: Increase training and support for editors to improve efficiency and understanding of the process.

Additional Strategic Alternatives

• Discontinue the Updatable REC Process: While this process has proven to be effective from an Intellectual Property Rights (IPR) perspective, ensuring compliance and protection across contributions, it is clear that it is not fit for purpose from an editorial standpoint. The excessive manual labor and complexity required have made it impractical for editors, who often face significant difficulties in navigating and implementing the required markup and procedural demands. This has led to a process that, despite its theoretical benefits, ends up being overly burdensome in practice. We need to consider phasing it out in favor of a system that better aligns with the working realities of editors while still maintaining the necessary IPR protections.
• Discourage Use of the Current Process: Officially recommend that the current updatable REC process be used only when absolutely necessary, due to its complexity and the high overhead involved.
• Introduce a 'Living Recommendation' Model: Adopt a model similar to the WHATWG living standards, which allows for more dynamic and less formal updates. This approach would involve continuous updates without the need for detailed version tracking and complex markup, addressing many of the current frustrations.

As documented in w3c/w3process#589,
these issues have long plagued the community, leading to widespread
dissatisfaction and calls for change. This discussion aims to transform the REC update process into a more practical and user-friendly system, enhancing the efficiency and satisfaction of all stakeholders involved in maintaining W3C standards.

[marcoscaceres]

This is also indicative that maybe this whole thing should be scrapped for the sake of simplification of the Process: #590

The updatable-rec process doesn’t seem to be serving anyone adequately and is highly confusing.

[dontcallmedom]

in terms of tooling support, I've set up an approach for the WebRTC Working Group that reduces a number of the costs in managing amendments: w3c/webrtc-pc#2713

It's far from perfect but I think has served us reasonably well and has indeed generated interest in applying some of its underlying principles pre-Rec (!).

With all that said, I agree that the current Rec update process needs rethinking; the fact that 3 years later it hasn't been fully used even once is an unmistakable signal.

[sideshowbarker]

…maybe this whole thing should be scrapped for the sake of simplification of the Process: #590

The updatable-rec process doesn’t seem to be serving anyone adequately and is highly confusing.

See my comments at w3c/tpac2024-breakouts#11 (comment). The “updatable REC” process has some fatal limitations:

• No autopublishing. Per https://www.w3.org/policies/process/drafts/#revising-rec, there’s no way at all for a Working Group to directly autopublish/re-publish in-place a REC; instead, the Working Group must request the Team to publish updated versions — even just for typos or other extremely minor editorial fixes.
• No substantive changes without full AC review. Per https://www.w3.org/policies/process/drafts/#change-review, WGs can’t get RF Commitments for any substantive changes to normative requirements without going (back) through full AC review.

“Candidate Recommendations”, in contrast, can be directly autopublished/re-published by Working Groups themselves —with no need to make a request to the Team, and with no AC review needed. Specifically, for “Candidate Recommendations”:

• Working Groups can — without AC review — directly autopublish to the spec version in TR space any changes they want, including substantive changes to normative requirements
• Working Groups can — if/when they have a set of substantive changes they want to get RF Licensing Commitments for — just publish a Snapshot. And even publishing Snapshots doesn’t require them to get AC Review either.

Given those differences, it seems very unlikely in practice most Working Groups would ever use the “updatable REC” option.

[frivoal]

I agree that the updatable REC process has issues, but I think we will have a better chance of addressing them if the criticism is accurate, and I think #866 (comment) misses the mark.

The “updatable REC” process has some fatal limitations:
No autopublishing. […] even just for typos or other extremely minor editorial fixes.

I don't believe that's the case. It is certainly true of the existing tooling, but I believe Echidna could be made to support updating a REC with class 1 and 2 (including the addition / update of candidate amendments) automatically, without any change to the Process. The Process does not call update requests or Team verification for changes 1 and 2 to a REC. It is true that the phrasing used by the process is "may request republication", and that this "request" word could be seen as an indication that the Team's permission is needed. That is not my interpretation (if that was the case, we'd have invoked the "update request"). There's no judgement to be made by the Team here, so I see no reason this request couldn't be automated.

The “updatable REC” process has some fatal limitations:
[…]
No substantive changes without full AC review.

With or without the updatable REC process, getting substantive changes into a REC without AC Review, directly or indirectly, has never been possible. The definition of REC reads: «A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has received the endorsement of W3C and its Members.» That claim cannot reasonably be made without having consulted the AC. Changing that would not just be changing the details of how you publish a REC, it would be changing what a REC is.

I think this point is actually essential to the task we have at hand: it would be easy to make the Process of publishing or updating a Recommendation simpler if we are willing to let go of some parts of what makes a REC a REC. Much of the complexity of the current process arises from trying to inject some amount of flexibility while preserving the defining characteristics of a REC.

If we let go of endorsement by the whole consortium, or of implementation experience, or of wide review, or of WG consensus, or of addressing issues, or of patent coverage… then everything can become much simpler, but we need to be honest with ourslves about what we let go of in exchange. I think we can do better than the current process without compromise on the definition of a REC, but finding this right balance will not be easy. Alternatively, proposals that want to relax some of the defining characteristics of a REC can be made, but those should be explicit about being proposal to change what RECs are, not claim to be mere simplifications to the way we publish one.

“Candidate Recommendations”, in contrast, can be directly autopublished/re-published by Working Groups themselves —with no need to make a request to the Team

That is not true of Candidate Recommendation Snapshots (which are what unqualified CR were before the introduction of the CR Drafts), which do involve an update request and team verification (see https://www.w3.org/policies/process/drafts/#publishing-crrs). It is true of Candidate Recommendation Drafts, but do note that these are not Patent Review Drafts, and do not carry the same patent commitments as Candidate Recommendation Snapshots. From the Patent Policy's point of view, CRD have the same standing as REC+Candidate Amendments.

Working Groups can […] just publish a Snapshot.

They cannot "just" publish. Publication of a CR Snapshot an Update Request, including Team verification.

And even publishing Snapshots doesn’t require them to get AC Review either.

That's true, but it's not that different from the updatable REC path. Publishing a Proposed Amendment does trigger an AC Review afterwards, but it is not conditioned on getting approval by an AC Review. Success in the AC Review is one part of what enables the next stage (folding in the amendment informatively), just like success on the AC review based on a CR (which we call a PR) is necessary for getting your changes to REC. But again, that happens after publication of the Proposed Amendment, not before.

With the notable exception of the editorial burden of maintaining the purple boxes, getting Patent coverage through updatable REC is not more onerous on the WG than doing so via CR. In fact, from a requirements standpoint, it is actually easier to get to that point (though I do agree that this is confusing): in the updatable REC path, checking for wide review happens after AC Review and Call for Exclusion: not when you publish the Proposed Amendment, but when you call for it being folded in normatively through an update request. Yes, this is confusing and different from how we do things via a CR, since for CRs you need to have wide review before entering CR, but strictly speaking, that does mean there are marginally fewer criteria to fulfill to get to patent coverage via updatable REC than via CR.

That said, Publishing Proposed Amendments does create a little more work on the AC than republishing a CR, since an AC Review is triggered as well every time, not just when you're ready to update the REC, but Patent Coverage is not conditioned on it.