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