RE: Pointer Events Level 2 - path to REC

Sounds like a great plan Rick! I agree that we can skip tomorrow’s call and can discuss over email. Expect a more detailed response from me tomorrow.

From: Rick Byers [mailto:rbyers@chromium.org]
Sent: Tuesday, October 4, 2016 1:51 PM
To: public-pointer-events@w3.org
Subject: Pointer Events Level 2 - path to REC

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