Re: Errata for Touch Events REC

On 4/14/15 9:10 AM, Rick Byers wrote:
> On Tue, Apr 14, 2015 at 7:48 AM, Arthur Barstow <art.barstow@gmail.com 
> <mailto:art.barstow@gmail.com>> wrote:
>
>     On 4/13/15 5:21 PM, Rick Byers wrote:
>
>         On Mon, Apr 13, 2015 at 5:13 PM, Arthur Barstow
>         <art.barstow@gmail.com <mailto:art.barstow@gmail.com>
>         <mailto:art.barstow@gmail.com <mailto:art.barstow@gmail.com>>>
>         wrote:
>
>             Hi All,
>
>             The errata for the Touch Events REC [1] is still mostly
>         empty and
>             it contains what I would characterize as a somewhat surprising
>             statement:
>
>             [[
>            
>         <http://www.w3.org/TR/2013/REC-touch-events-20131010/REC-touch-events-20131010-errata.html>
>             ...
>
>             An updated specification will be located at WebPlatform Specs.
>             ]]
>
>             I say "surprising" because I don't recall us agreeing to
>         publish
>             an update at specs.webplatform.org
>         <http://specs.webplatform.org> <http://specs.webplatform.org>.
>             Would someone please clarify?
>
>
>         IIRC Doug said that was the new preferred path for publishing
>         errata the last time we discussed the errata process on a
>         call.  Perhaps "updated specification" is misleading though :-)
>
>             Anyhow, what, if anything should be added to the errata
>         document?
>             Does the CG have consensus about text for the errata document?
>             Alternatively, perhaps the errata document could link to a
>         version
>             of the spec that is the REC + agreed errata text (all
>         inlined, and
>             perhaps styled such all of the changes from the REC are very
>             clearly identifiable and enumerated in the Changes Since
>         last Pub
>             section)?
>
>             Personally, I think having a document that is the REC + agreed
>             errata changes is more useful than adding text to the
>         errata document.
>
>
>         I like that plan too.  From our recent call though it sounds
>         like some of the 'errata' changes we've made may need to be
>         considered normative.  Eg. fractional co-ordinates.  That one
>         change alone is important enough to me (and, IMHO, the
>         platform) that I wouldn't want to let it fall through the
>         cracks.  So perhaps we should be talking more about publishing
>         a minor v1.1 update instead of worrying about errata?
>
>
>     Yes, I think the consensus is to put all of the changes in a
>     single document and then Doug and I (and anyone interested in the
>     `sausage making`) will figure out how to get that doc published as
>     a Technical Report.
>
>     BTW, what is the rough status and plan of that document (perhaps
>     we should call it TE Level 2)? Have all of the changes we want to
>     make been added to one of the branches (and if yes, which
>     branch)?  Do we want to block publication pending more feedback
>     from implementations and deployment? I noticed there are some open
>     issues <https://github.com/w3c/touch-events/issues>.
>
>
> We've got two branches/documents at the moment - v1-errata and 
> 'master' which has the TEE.  It sounds like we should merge the errata 
> and TEE back into a single document in master (returning us to 
> single-branch sanity), is that right?  I'd want to make sure we have 
> consensus on this before making the change.

Yes, doing that merge seems right to me.

Re getting consensus, perhaps the simplest thing to do is to create a PR 
and then announce it with a short-ish review cycle that will result in 
merging the PR if no one raises any objections by the end of the cycle.

> There are still a few outstanding issues / changes.  I haven't been in 
> any big rush to get them done (as I don't currently have any impl work 
> blocked on further spec changes), but perhaps I should be making that 
> a priority?

If the REC being out of date is causing problems (for developers, 
implementers, etc.), then I would say, yes, getting a new TR published 
is something we should do sooner rather than later.

-ArtB

Received on Friday, 17 April 2015 12:36:15 UTC