w3process-ISSUE-156 (Errata vs REC track process): Do we need separate Errata and REC Track Processes? [Process Document]

w3process-ISSUE-156 (Errata vs REC track process): Do we need separate Errata and REC Track Processes? [Process Document]

http://www.w3.org/community/w3process/track/issues/156

Raised by: Steve Zilles
On product: Process Document

This issue is concerned with the current distinction between Errata and New Features. It arose in the discussion of Issue-141 [0].

[0] http://lists.w3.org/Archives/Public/public-w3process/2015Jan/0048.html

There are, currently, two key distinctions in the Process that distinguish the way a Working Group handles changes that are classed as Errata versus those classed as New Features. 

The first distinction is that changes that correct Errata can be made Normative by making a CR for an Edited Recommendation, which triggers a call for exclusions on any new content and an AC review, but New Features must follow the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft. 

The second distinction is that New Features may require a charter revision (and approval by the AC.)

If no new features are planned, then the Errata Management Process is simpler and makes sense. If, however, New Features are planned, then having a separate processes for Errata and New Features makes less sense. Having two processes seems to imply having two separate documents, one with the Errata changes and the other with both the Errata changes and the New Feature changes. This seems to imply a duplication of work, although New Features may make some of the Errata changes be different than they would otherwise be.

Another piece of the story is that New Feature Working Document may progress much more slowly (due to implementation uptake) than do Errata changes (which are often aimed at improving interoperability and have quicker uptake). Getting these agreed and implemented changes into a Normative status as quickly as feasible is one justification for using separate processes (with some duplication) for Errata and New Features.

There seem to be two separate sub-issues: (a) should we have two processes, one for REC track work in general and one (simpler one) for Errata and (b) should it be possible to handle Errata processing using the general REC track process? If we do have two separate processes, then it is important to have a definition of what Errata are. If we chose to use the REC track process for Errata, then such a definition is not important.

Received on Sunday, 8 February 2015 00:19:28 UTC