Re: errata again, responding to the november proposal

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

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?

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
>


-- 
------------------------------------------------------------------
Olle Olsson   olleo@sics.se   Tel: +46 8 633 15 19  Fax: +46 8 751 72 30
         [Svenska W3C-kontoret: olleo@w3.org]
SICS [Swedish Institute of Computer Science]
Box 1263
SE - 164 29 Kista
Sweden
------------------------------------------------------------------

Received on Thursday, 15 January 2015 15:56:51 UTC