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: https://github.com/w3c/w3process/issues/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: https://github.com/w3c/webrtc-pc/pull/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 https://github.com/w3c/tpac2024-breakouts/issues/11#issuecomment-2199312419. 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.