- From: Jeff Jaffe <jeff@w3.org>
- Date: Mon, 09 Feb 2015 14:28:58 -0500
- To: David Singer <singer@apple.com>, Revising W3C Process Community Group <public-w3process@w3.org>
+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). > >> 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 19:29:15 UTC