W3C home > Mailing lists > Public > public-w3process@w3.org > January 2015

Errata - a proposal

From: <chaals@yandex-team.ru>
Date: Sat, 10 Jan 2015 23:54:06 +0300
To: Revising W3C Process Community Group <public-w3process@w3.org>
Message-Id: <218861420923246@webcorp02f.yandex-team.ru>
this is to close action-38, and issue-141...

Remove 7.7.1

Fold the requirement to track issues raised against Recommendations into 7.7.2 "Revising a Recommendation", by adding a new first paragraph as follows:
Working groups must track issues and bugs raised against Recommendations. Working Groups should propose resolutions for these issues, for example in the form of an errata page or directly incorporated in Editors' or Public Working Drafts for later versions of the Recommendation.

The current Process says [[[
7.7.1 Errata Management

Tracking errors is an important part of a Working Group's ongoing care of a Recommendation; for this reason, the scope of a Working Group charter generally allows time for work after publication of a Recommendation. In this Process Document, the term "erratum" (plural "errata") refers to any class of mistake, from mere editorial to a serious error that may affect the conformance with the Recommendation by software or content (e.g., content validity).

Working Groups must track errata on an "errata page." An errata page is a list of enumerated errors, possibly accompanied by corrections. Each Recommendation links to an errata page; see the Team's Publication Rules.

A correction is first "proposed" by the Working Group. A correction becomes part of the Recommendation by the process for Revising a Recommendation described in the next section.

A Working Group should keep their errata pages up-to-date, as errors are reported by readers and implementers. A Working Group must report errata page changes to interested parties, notably when corrections are proposed or incorporated into an Edited Recommendation, according to the Team's requirements.

The first paragraph boils down to "we find things that need to be fixed, even after Rec".

The second paragraph has a formal requirement: "Working groups must track errata on an errata page". The rest is explanatory text. I don't think we should be as rigid about *how* errata are tracked, and I think we should imagine that in many cases it will be by incorporating them into draft documents for technology.next …

The third paragraph attempts to describe how things work, but is effectively redundant with section 7.7.2.

The final paragraph has a should and a must requirement, but it is unclear how meaningful they are in practice - everything published has to go through pubrules, and incorporating things into an Edited Recommendation already has a requirement that they have been reviewed.

Ultimately this boils down to the idea that we should generally expect Recommendations to be "temporary", and replaced from time to time by an improved version - unless they are no longer of interest.

Which means that we should expect to have a draft revision somewhere, even for a Recommendation, and therefore be tracking bugs in whatever way the Working Group prefers to do that...

...hence my proposal, above.


Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Saturday, 10 January 2015 20:54:37 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 10 January 2015 20:54:37 UTC