Re: Proposal for Publishing REC Errata

On Oct 17, 2014, at 3:42 , chaals@yandex-team.ru wrote:

>> [SZ] I believe there was some level of agreement in the discussion on the Telcon, but there ought to be some accepted conventions for how errata are presented to insure that readers can reliably find them. I am not sure whether those conventions should be part of the Process or Best Practices.
> 
> The Process requires a page, and a link to it. I don't see how that would not be satisfied by a pointer to bugzilla, tracker, a hand-crafted page, or a list of github issues since the Rec publication…

I agree. The important thing is that we want to give timely notice to readers of errata.  A slip of paper inside the front cover of a book is not ‘convenient’, but it is timely, and that is adequate.

I do not think it worth optimizing prettiness at the expense of timeliness.  If people want to do something prettier as well (e.g. a redlined copy), that’s great, but even then users deserve to know of issues that the WG agrees are a problem but for which they have not yet agreed the edit.

> I did not say "nobody wants to do this". What I said is (equivalent in logic to) "without people prepared to do something, making a Process statement that they should do it will not automatically produce the outcome that they do”.

Right, and as the degree to which something is manual rises, the likelihood of it happening falls.

> 
>> As far as I can tell most WG members would prefer to have one very public document that reflects consensus agreement on the specification. The complaint being addressed by ISSUE-141 is that too often that is only the Editor's Draft and that does not always reflect consensus.
> 
> Then get better editors, who can make it clearer what in the document represents consensus.

Rather, if the editor/chair are unable to get a simple WG consensus that editor’s draft X has the consensus of the WG as a WG WD, then get better chairs/editors.

Editor’s drafts are GOOD, they enable the editors to attempt to make a coherent document, make progress, and so on.

> 
>> The CSS WG would like to update it prior specs (earlier versions) when errata are discovered, but find that the "errata page" is not a very useful way to accomplish these updates. Or provide the existing editors with better tools to do the same.
> 
> Not useful to whom?
> 
> Identifying errata is like identifying changes. Expecting people to read a full "diff" that includes all kinds of irrelevancies is very unhelpful to those who are not tracking the work directly themselves. A list of errata (or changes - it amounts to the same thing) tells someone who periodically checks to see what they should update exactly what they need to look at (if it is moderately well-organised - again something the process doesn't guarantee and that in practise is often not the case). 


There are two problems here.

a) advising readers of errors in what they are reading (‘errata’)
b) providing readers with a better document with fewer errors (revised document, red-lined document).

We can certainly provide redlined unofficial (well, WG consensus) copies if we like.  I think that the Process CG somehow needs to work out what the most expeditious way to publish a Revised-X is, where X is a CR, PR, Rec. or other document with formal status, such that the revision gets the same status.

So, please can we separate Errata management (the process requirements should be low, and simple to achieve, and open to automation, IMHO, and we can suggest people exceed them) from Revised Document management (where we somehow have to convince ourselves that the revised document is harmless, or rather, no differently harmlful from the original.)

I think Chaals and I are on the same line: manage errata by Tags against Products in Issues or Bugs, and make the page generation automatic.

David Singer
Manager, Software Standards, Apple Inc.

Received on Friday, 17 October 2014 21:49:48 UTC