- From: <chaals@yandex-team.ru>
- Date: Tue, 13 Jan 2015 14:33:11 +0300
- To: David Singer <singer@apple.com>
- Cc: Revising W3C Process Community Group <public-w3process@w3.org>
13.01.2015, 01:41, "David Singer" <singer@apple.com>: >> On Jan 10, 2015, at 12:54 , chaals@yandex-team.ru wrote: >> >> 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. >> ]]] > > I think there is value BOTH to admitting of an error/problem, and to proposing a fix. Can we try something like: > > Working groups must track issues and bugs raised against Recommendations, and should also propose resolutions, in a way that makes it possible to find them when reading a Recommendation. Both the tracking of errors and the proposed resolutions can be, for example, in the form of an errata page, or in the form of material (e.g. links to the issues or bugs) directly incorporated in Editors' or Public Working Drafts, for later versions of the Recommendation. I can live with that. I find my version preferable because it has: - clear statements of rfc2119 conformance requirements - less text The idea that what working groups do should be obvious is one of common sense, although I agree that many groups think they are their only audience so don't find it important. I'm not sure that dealing with it in this (and each other relevant section of the process - there are many of them) is the right approach - I would rather put it somewhere in the process and repeat it in best practices guidance. cheers >> 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. >> >> cheers >> >> -- >> Charles McCathie Nevile - web standards - CTO Office, Yandex >> chaals@yandex-team.ru - - - Find more at http://yandex.com > > David Singer > Manager, Software Standards, Apple Inc. -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Tuesday, 13 January 2015 11:33:47 UTC