Re: Proposal for Publishing REC Errata

Hi Fantasai,

> Proposal
> --------
> 
> The proposal to resolve this problem is to keep the errata inline in
> the official REC publication. Two options make sense to me:
> 
>  A. Write in the errata as diff marks (using <ins> and <del>) in the
>     spec. Maintain a separate list similar to a DoC explaining
>     the changes, and possibly also tracking the status of their tests
>     and impls.
> 
>  B. Fold in the errata completely into the spec text. Maintain a
>     separate list of changes including the exact diffs from the
>     validated REC text.
> -------


Hi Fantasai,

I would like to see a more reader friendly approach to errata management. Here are a few considerations:

1) Our process says [1], "W3C strives to make archival documents indefinitely available at their original address in their original form."
    We have at least two goals: 
        a) Give readers a clear understanding of corrections.
        b) Ensure that the original publication is still available.

   There are various ways to do that, including:
       - Making the commit history available
       - Using the latest version URI to get the in-place corrections, and the dated URI to get the original version.

 2) Wherever corrections are shown, we need to make clear (e.g., via the status section) that various agreements
     (consensus process, patent policy commitments) do not extend to the corrections until the spec has
     been through some formal process (whatever it is).

 3) Two more usability goals:
     a) Make it easy to find an explanation or other information about the correction
     b) Make it easy to just see the corrections (perhaps with a bit of surrounding context).

    Those could be satisfied in-place or by reference. One idea (I've not pondered deeply) is
    an in-place solution where explanations  are made available on demand (hide / show explanation) 
    and where one could see the corrections without the rest of the spec. (There are considerations here 
    like printing and accessibility.) The in-place solution might make it easier to maintain the spec and its
    corrections in one place.

There are various other details like URI-addressability of corrections, notification, and so on that people probably
already do today with github or other tools.

Cheers,

Ian

[1] http://www.w3.org/2014/Process-20140801/#general-requirements

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447

Received on Wednesday, 15 October 2014 22:02:51 UTC