RE: Errata - a proposal

Comments inline below
Steve Z

> -----Original Message-----
> From: chaals@yandex-team.ru [mailto:chaals@yandex-team.ru]
> Sent: Saturday, January 10, 2015 12:54 PM
> To: Revising W3C Process Community Group
> Subject: Errata - a proposal
> 
> this is to close action-38, and issue-141...
> 
> TL;DR:
> 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.
> ]]]
> 
[SZ] I do not object to doing a re-organization of both of 7.7.1 and 7.7.2, but this proposed change does nothing to resolve Issue-141 which was concerned with improving the frequency of updates to specifications in a way that makes them more current and less out of date. Secondly it removes the definition of what Errata are, by "boiling down the text" of the first paragraph. Thirdly, it changes one of the proposed restrictions on putting Errata in a Public Working Draft; namely, insuring that such Errata are clearly marked as such and that the original text can be retrieved. See 
  http://lists.w3.org/Archives/Public/public-w3process/2014Nov/0004.html

for text which does treat the sections you have left out.
> 
> 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".
[SZ] On the contrary, the role of the first paragraph is to define Errata (as distinct from New Work which would require a First Public Working Draft).
> 
> 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 …

[SZ] I believe there is agreement that some flexibility in how Errata are documented (the issue is not how they are tracked), but there was agreement that because Errata are not normative until the process in  paragraph 7.7.2 is completed, it should be possible for a reader of a public draft to tell what is Normative and what is proposed Errata. This is missing from your proposal. 
> 
> The third paragraph attempts to describe how things work, but is effectively
> redundant with section 7.7.2.

[SZ] This paragraph is not totally redundant as it defines, "proposed Errata", but it might be compress or moved to 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.

[SZ] The point of this paragraph is a requirement to keep things up-to-date and to tell people when changes to the Errata have been made. If this were only done when making an Edited Reccomendation, that would be way to late.
> 
> 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.

[SZ] No, that is not the point of Issue-141. The point of Issue-141 is that Errata are recorded in a useful way in a document that is accessible to the public and that relevant changes are easy to find. Experience has shown that it may take a long while to issue a replacement REC and that we need a better way to communicate proposed Errata in the interim.
> 
> 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.
> 
> cheers
> 
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Sunday, 11 January 2015 15:46:01 UTC