- From: Jeff Jaffe <jeff@w3.org>
- Date: Thu, 15 Jan 2015 11:05:45 -0500
- To: Olle Olsson <olleo@sics.se>, public-w3process@w3.org
On 1/15/2015 10:56 AM, Olle Olsson wrote: > Recommendations are published by W3C, true, not WGs, > > Which raises the issue about whether there is a formal WG to handle > errata. WGs have a limited life-time. What if the WG ends by proudly > publishing a Rec, makes an orderly dissolution of itself, all > according to the plan, and then some errata are identified. So there > is no WG to propose an updated version of the Rec, right? Would this > neccessitate chartering a new WG to handle the errata? Could that be > a re-chartering, even though the previous instance was formally ended? > And what about licensing commitments etc.? In general, the Team takes responsibility to handle routine errata for dissolved WGs. There could be circumstances when the quantity and quality of errata are cause to re-create a WG. > > Jeff said: >> A Working Group should make it easy for the community to find errors >> reported by readers and implementers together with suggested >> corrections. > > Does this indicate that some framework should be in place for orderly > collection of errata findings by the world, so people would be aware > of these errata, even if no WG exists to handle them? I don't have specific data, but it is certainly my impression that most errata arrives for "supergroups" - long running key groups such as HTML, CSS, and WebApps. > > What historical data do we have about *when* errata are reported for > Recs, relative to the publication date of the Rec? > > /olle > > > > On 2015-01-13 18:12, chaals@yandex-team.ru wrote: >> Hi, >> >> I took action-141 because I disagreed with Steve's November proposal >> for errata [1]. In today's meeting Steve asked us to respond to that >> proposal and explain objections and changes that would address them. >> >> The proposed replacement text for section 7.7.1 is [[[ >> 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 error that can be resolved by one or more >> changes in classes 1-3 of section 7.2.5 Classes of Changes. >> >> A Working Group should keep their Recommendations up-to-date as >> errors are reported by readers and implementers. Such error reports >> should be processed no less frequently than quarterly and errata >> should be placed in the Recommendation. >> >> An erratum is resolved by an informative, "proposed" correction >> generated by the Working Group A correction becomes a normative part >> of the Recommendation by the process for Revising a Recommendation >> described in the next section. >> >> There are two ways in which the errata and/or proposed corrections >> may be placed in the Recommendation. First, the Recommendation may >> point to a page in which the errata (and any proposed corrections >> that fix the erratum) are incorporated in an identifiable way. >> Alternatively, the Recommendation may be edited to allow a viewer to >> selectively display: (a) the original content of the Recommendation, >> or (b) that content updated to show the corrected text. Either of >> these approaches MUST satisfy the then applicable Publication Rules. >> >> A Working Group must report changes that incorporate errata to >> interested parties, notably when corrections are proposed or >> incorporated into an Edited Recommendation, according to the Team's >> requirements. >> ]]] >> >> Responding paragraph by paragraph: >> 1. The first sentence boils down to "bugs have to be tracked when >> you find them, even after recommendation". I agree that the process >> should set that expectation. The second sentence attempts to define >> errata specific to W3C process, because that distinction is used >> later in the proposal. I do not think that defining them specifically >> is useful, and as explained below I do not think the use for the >> specific definition is helpful. >> >> 2. The first sentence assumes that a Recommendation belongs to a >> Working Group, which is false. A Recommendation is a Recommendation >> of the W3C developed through a consensus process. The Working Group >> does the "grunt work" of proposing what that should be in detail, but >> it is not a W3C Recommendation. That said, the process is intended to >> allow W3C to produce Recommendations that are useful - and this means >> that for the lifetime of a technology it is probable that there will >> be value in providing corrections, enhancements, etc. That is the >> point of being able to revise a Recommendation, and the fact that it >> should happen is already covered in the first sentence of paragraph 1. >> Specifying a particular rhythm is saying in another way what is in >> 7.2.1 (we could just link there). I strongly object to the suggestion >> that errata (statement and/or proposed resolution) should go directly >> into a Recommendation, rather than some other document such as an >> errata list, bug tracker, draft replacement version, etc. (I'll >> return to this in regards to paragraph 4). >> >> 3. This paragraph doesn't add anything useful, and could be scrapped. >> There is an existing discussion of how issues are resolved, and a >> "proposed" correction is merely an attempt to provide a formal title >> to a proposed resolution of a bug or issue. >> >> 4. There are at least 3 useful ways to track issues raised against a >> document, and the proposals made, and accepted by the working group, >> to resolve them. Putting them into an errata list, putting them in a >> bug or issue tracker, and putting them into a draft document are all >> reasonable alternatives. None of them involve touching the text of a >> W3C Recommendation. In addition, setting a constraint for "classes >> 1-3 of change" (as defined in section 7.2.5, i.e. those which do not >> involve a new feature [2]) but requiring that it not be applied to >> class 4 (new features) introduces a layer of busywork for a group >> that has a sensible way of updating documents in a timely manner and >> informing people of changes they are proposing for the specifications >> they manage. >> The second sentence is reasonable as *a suggestion* for ways to >> manage errata. Although there are many situations where that approach >> has been found to be problematic, meaning it should not be *mandated* >> there are also ways to use it reasonably, meaning it should not be >> forbidden. >> Proposing to incorporate new material that has not been reviewed by >> W3C into a Recommendation strikes me as an incredibly bad idea. W3C >> has long maintained a social contract that the text of a >> Recommendation will not change. Publishing them as static documents >> without multiple viewing options is an important part of ensuring >> that there is not confusion about what is the text of the >> Recommendation. Changing that seems a terrible idea. Publishing e.g. >> an editor's draft for a replacement version (something that W3C has >> also been doing for almost a couple of decades), or using some other >> means of tracking proposed changes that have not been approved by >> W3C, and clearly linking it from the Recommendation, seems a >> perfectly adequate mechanism of informing people about the latest >> ideas while providing a simple, reliable and stable reference for >> those who need one. >> In addition, while there are various mechanisms to identify two >> different views of a single document, such as the use of extra >> styles, they are less reliable than simply having two different >> documents e.g. a Recommendation and an Editor's Draft. In any event, >> where there are class 4 changes being proposed at the same time, it >> makes no sense to *require* a version that does not make them >> available while presenting class 1-3 proposed changes. >> >> 5. The requirement to inform "interested parties… according to the >> Team's requirements" is redundant with the requirement in the >> subsequent section 7.7.2 (first bullet in the list in that section), >> but without the explanation of what that means which is provide for >> the term "wide review". >> >> To summarise, the features of the proposal I explicitly object to are >> - Anything that suggests adding material to a published >> Recommendation (as opposed to an Editor's draft or other separate >> document with a different status) >> - Redefining the term "errata" >> - Forcing groups to use different mechanisms for different types of >> issue, beyond constraints in the existing process outside section 7.7.1 >> - The use of different text from elsewhere in the document in the >> final sentence >> - The verbosity of the section >> - Constraining the way groups present issues and proposed resolution >> of them beyond the existing Process outside section 7.7.1 >> >> The parts that I find neither objectionable nor unnecessary >> repetition are >> - a statement that publishing a Recommendation doesn't mean the >> responsibility of a working group to record and address issues has >> been discharged. >> - allowing the use of an errata page as one means of tracking issues >> raised against a Recommendation. >> - the idea (implicit but unstated) that it should be easy to find the >> issues raised against a recommendation and solutions proposed for them. >> >> It seems that these three points could be more succinctly expressed >> in a single introductory paragraph, and we could remove section 7.7.1 >> and the section 7.7.2 header entirely header If people like that >> idea, I will propose some specific text. >> >> cheers >> >> [1] >> https://lists.w3.org/Archives/Public/public-w3process/2014Nov/0004.html >> >> -- >> Charles McCathie Nevile - web standards - CTO Office, Yandex >> chaals@yandex-team.ru - - - Find more at http://yandex.com >> > >
Received on Thursday, 15 January 2015 16:05:58 UTC