Re: Errata - a proposal

11.01.2015, 18:45, "Stephen Zilles" <szilles@adobe.com>:
> 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.

Well, it provides the flexibility to organise errata however a working group thinks that is best done. Actually making work happen isn't something the process can mandate, except by providing some consequence of it not happening, and I don't see any useful mechanism to do that.

> Secondly it removes the definition of what Errata are, by "boiling down the text"
> of the first paragraph.

Right. But since it is a standard word in english, I don't think it is helpful to define it in the process.

> 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

Yes. IMHO that is a feature of this proposal. The general process of producing a revision may be something done to correct "identified errata", or "bugs", or "desirable missing functionality", or even just to editorially clarify the text for better readability.

I don't think there is a lot of value in trying to describe the differences exactly - the key ones are whether a TR document can simply be republished, requires a new PR or CR or is developed as a completely new version.

And that is defined by the types of changes, which in turn is constrained by the social contracts implied by the longstanding policy of W3C to provide persistence of documents at certain URLs, and the Patent Policy. I'm happy to look at changes to either of those, but don't think we make much progress by suggesting changes that are contingent on changes to those constraints.

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

That isn't what the text says - it effectively allows for any kind of error. In other words, the common english usage of the term.

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

No, in my proposal, Recommendations are published and are normative, and other drafts provide guidance as appropriate (Working Drafts noting each issue's consensus within the WG, Editor's Drafts noting the latest Saturday Night brainwave, issue/bug trackers/errata lists noting that things are still under discussion). Which is the status quo in terms of understanding the difference.

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

That's incorrect. It doesn't define "proposed errata", it describes a process for treating errata. Inter alia, it makes the assumption that the Working Group is responsible for proposing a correction, whereas what happens in reality is that almost anyone can propose a correction, but the Working Group are the ones responsible for agreeing on one and subsequently making it normative by including it in a revision (edited Rec, version..next, both, etc).

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

The fundamental point of the "wide review" requirements is that only seeking it when you are about to publish a Rec is far too late. Whatever flavour of Recommendation it is.

If a working group doesn't understand its responsibility to the wider community of users, then I think its problem is far deeper, and a requirement in this part of the process isn't the solution. If it does, then the requirement is redundant with common sense, the requirements for wide review and guidance given on that, and all the work W3C does to remain relevant.

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

And rather than propose a specific mechanism that forces specific work patterns on Working Groups (who generally understand the problem - unless they are among those who happily issue an editorial revision every year since it actually only takes about 8 weeks if you agree on what you want to revise, in which case they don't have a problem), I am proposing that we remind our various audiences of the requirement to do so, and let them decide the most useful mechanism of the day. The groups using a github tracker, or specifiction, or effectively updating drafts of version.next with a pointer from their last recommendation, or who regularly publish edited recommendations, probably don't need to be told how to do the task.

cheers

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

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Sunday, 11 January 2015 16:14:29 UTC