Re: Pointer Events Level 2 - path to REC

This sounds reasonable to me.

On Tue, Oct 4, 2016 at 4:50 PM, Rick Byers <rbyers@chromium.org> wrote:

> Hey,
> Chatting with some folks at TPAC, Once Chrome's implementation hits stable
> (and hopefully Firefox isn't far behind) I expect we'll start feeling the
> pressure to get PEL2 to REC status.  To do this I suggest we start by
> triaging issues and adding the "v2-blocking" label to those we think should
> be resolved before trying to go to CR
> <https://www.w3.org/2015/Process-20150901/#candidate-rec>.  IMHO (without
> being an expert on the W3C process) I think this should include:
>
>    - Any issues where the spec deviates from multiple implementations in
>    a non-trivial way
>    - All outstanding test issues (eg. incorrect failures) - we'll be
>    required to explain any test failures (though it's probably OK if we have a
>    couple - no software is bug free).
>    - Any high-priority features with impl plans in more than one browser.
>
>       - The only one I can think of from the blink side is the historical
>       points API <https://github.com/w3c/pointerevents/issues/22>, which
>       is now urgent for us.  Is Microsoft or Mozilla also interested in
>       implementing this, say, sometime in the next 6 months or so?  If not, then
>       we could move it from PEL2 into incubation instead (eg. a separate WICG
>       spec that extends PEL2).
>    - Any little things that are relatively easy to just fix (no point
>    carrying a bunch of little easy issues)
>
> In contrast, things that are probably not v2-blocking include:
>
>    - New features without concrete implementation plans in 2 or more
>    implementations
>       - we can continue to iterate on these in an incubation mode, eg.
>       either in a separate spec somewhere or, if we prefer, a branch.  But they
>       shouldn't delay the substantial benefits of getting our spec to REC.
>    - Issues that track a deviation in behavior in one browser of the 3,
>    especially when developers are unlikely to be hit by it
>       - Ideally we'll still address all of these, but they don't seem
>       worth blocking L2 on to me (none of us has bug-free software). As long as
>       we have 2 implementations matching the spec in each area that's good enough
>       for REC.
>    - Editorial issues that are hard to get consensus on or otherwise
>    address
>       - Again we should try to make progress, but probably not worth
>       blocking REC.  My personal opinion is that as long as we have good tests
>       that explain concretely what we mean, we can live with some less than ideal
>       spec text.
>
> Sound reasonable?
>
> BTW I have a conflict tomorrow and won't be able to make a call, but
> perhaps it'll be cancelled anyway?  We can iterate on e-mail / GitHub.
>
> Rick
>
>