RE: w3process-ISSUE-155 (Errata Access in RECs): Errata access from TR page [Process Document]

Comments inline below
Steve Z

> -----Original Message-----
> From: Jeff Jaffe [mailto:jeff@w3.org]
> Sent: Monday, February 09, 2015 11:29 AM
> To: David Singer; Revising W3C Process Community Group
> Subject: Re: w3process-ISSUE-155 (Errata Access in RECs): Errata access from
> TR page [Process Document]
> 
> +1
> 
> On 2/9/2015 12:13 PM, David Singer wrote:
> > OK
> >
> > I think we’re making a mountain out of a molehill here.
> >
> > While, for all sorts of reasons, we can’t have a working group claiming that
> the edits are only editorial, and that the revised document IS the Rec that was
> approved, without giving people at least a cursory opportunity to look and
> agree or disagree, that does NOT mean that the header of the Rec can’t say
> >
> > “There is a draft of this document in which the working group has corrected
> a number of errors; you may prefer to work from that.”
> >
> > (with appropriate linking).
> >
> > That means that visitors get the right information: The TR is the document
> that went through formal IPR review etc.; but there is a document that
> corrects errors and is probably more suitable as a technical reference.
> >
> > The TR page could also link both (not that I ever visit it, myself; I use a search
> engine to find things).

[SZ] This last point is the heart of the problem. Search Engines are more likely to point to out of date copies. AND, people often end up finding a linking NOT to the whole document, but to a section inside that document and do not see the warning at the top of the document. There is a need for a mechanism which shows the warning about a more up-to-date document no matter how one arrives at the document in question.
> >
> >> On Feb 7, 2015, at 15:06 , Revising W3C Process Community Group Issue
> Tracker <sysbot+tracker@w3.org> wrote:
> >>
> >> w3process-ISSUE-155 (Errata Access in RECs): Errata access from TR page
> [Process Document]
> >>
> >> http://www.w3.org/community/w3process/track/issues/155

> >>
> >> Raised by: Steve Zilles
> >> On product: Process Document
> >>
> >> This issue arose because, in the original discussion of Issue-141 Errata
> Management [0], some of the commenters (and, in particular, Fantasai [1])
> noted that people (whether users or developers or implementers) were going
> to the REC (via the TR pages) and getting out of date information.
> >>
> >> [0] http://www.w3.org/community/w3process/track/issues/141

> >> [1] http://lists.w3.org/Archives/Public/public-

> w3process/2014Oct/0139.html
> >>
> >> The goal of these commenters was to attempt to insure that people
> accessing RECs would be aware that there might be more current information
> which, although not yet normative, was better than that in the REC.
> >>
> >> Some people have argued that RECs should stay as they are and that such
> updated information should be in a separate document which itself might take
> a number of forms, ranging from an auto-generated errata/issues/bugs list to
> a draft of the REC which has the Errata text in situ.  There seems to be little
> disagreement that a separate document can be used. The disagreement
> seems to be whether the REC document can, itself, have better indications as
> to what the errata are and what changes are proposed to correct the errata.
> >>
> >> The November proposal [2] allowed the REC to be updated in place
> provided that a reader could recover, say by a style sheet change or some
> other mechanism, the original text of the Normative REC. Recent commenters
> seem to believe that this would be a bad thing for the W3C to do although in
> practice this may be little different from having a separate draft with the
> errata.
> >>
> >> [2] http://lists.w3.org/Archives/Public/public-

> w3process/2014Nov/0121.html
> >>
> >> The goal of this issue is to find solutions associating a REC and its Errata
> that both (1) make it easy and natural for someone retrieving the REC
> document to find the most up-to-date document (including Errata) and (2)
> preserve the necessary permanence of a REC. (Here, “necessary permanence”
> is intended to mean what the community thinks is necessary to insure is
> preserved; we already allow updates to things like broken links in place so
> permanence does not mean bit by bit fidelity.)
> >>
> >>
> >>
> >>
> >>
> > David Singer
> > Manager, Software Standards, Apple Inc.
> >
> >
>

Received on Monday, 9 February 2015 22:25:29 UTC