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

- sysbot+tracker@

TL;DR: This is a non-issue and can be closed.

Details below:

08.02.2015, 03:19, "Revising W3C Process Community Group Issue Tracker" <sysbot+tracker@w3.org>:
> 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
>
> ... 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.
>
> ... 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.

I'm not sure where you read the implication of multiple "threads" of revision being required under the Process.

It is certainly possible to do so, but as you imply it could be a lot of pointless extra work - in which case it would be stupid. However…

> 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.

If a group wants to issue a revised Recommendation as well as a new version, e.g. because it believes that it can produce the revised Rec much faster and provide real value to its stakeholders by doing so, the process allows this.

One might suggest addressing the question of why it takes so long to produce subsequent versions - and perhaps consider the way groups are chartered which in practice rarely suggests anything more than a single version of a spec will be produced.

This is also nonsense - almost all useful W3C specs I can think of have gone into multiple versions.

> 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?

a) It is not the case that there are two processes, it is simply the case that for certain classes of revision, there are optimisations allowed which are not permitted for wholly new features.

b) It is possible to handle errata 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.

Even if we don't have two processes, the circumstances in which we allow specific optimisations (i.e. waive certain requirements of the existing process) require that we define them. Which we do, in our definitions of "classes of change".

My proposal is that we close this as a non-issue.

In any event, it is not clear what a resolution to this issue would do. If we agree that we don't have two distinct processes, does that mean we don't need a definition of errata? If we do not agree, and work from the assumption that there are two separate processes, do we need to change the definition of errata that we have in the document?

cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Sunday, 8 February 2015 12:16:33 UTC