EME & MSE: Updated triage process for v1

Paul and Philippe have informed the editors of a new aggressive timeline
for the MSE and EME specs. They can provide more details and background,
but the relevant dates are below. (If you have questions about the
timeline, please start a separate thread so we can keep this one focused on
triage.)

In reverse chronological order, since the dates are driven by the end goal:

   - The goal is to publish both specs as Recommendations in September and
   finally close the old HTML WG.
   - To meet this goal, the specs must be in PR in mid-June.
   - We need to have a clear picture of the remaining work (open issues for
   v1) by the AC meeting in two weeks.


Most significantly to this group and the specs, the second bullet means
that *all changes we wish to make to the spec must be reflected in the spec
text, have tests, and be reflected in at least two implementations by
mid-June.*

In the interest of producing high quality specs while still achieving the
timeline, the editors have agreed on the following triage process. The core
tenets are consensus, identified solutions, and minimizing disruption and
thus risk. We also introduce a new milestone, v1-NonBlocking, for issues
that are not necessarily vNext but also will not block v1.

When running the following steps, once a milestone is assigned, abort the
steps for that issue. In other words, do not run subsequent steps and
change the milestone. This process can be run at any time, though common
sense and W3C process will need to be applied as we approach mid-June. For
example, it won’t be possible to add a trivial feature on June 10th
regardless of what the steps say.

1. Is the issue an editorial change to improve spec language? If so, mark
it v1-NonBlocking.
(These wouldn’t reset any CR review. We should fix as many as possible
before going to PR because they result in a higher quality spec, but only
after more substantive changes are fixed. These would not be treated as
blocking on the WG timeline, so the clock may run out before all are fixed.)

2. Is the issue otherwise non-blocking, such as registry additions? If so,
mark it v1-NonBlocking.
(Such items are not deferred to a new version but are lower priority and
may not be completed before PR.)

3. Is there current agreement on fixing the issue with an identified fix?
If so, mark it v1 and follow through on that agreement and complete the
planned spec edits.
(In addition to bugs, this step may apply to a feature for which there is
agreement that it should be added as long as there are agreed upon changes
to the spec that are minimal and not disruptive to the spec.)

4. Is the issue likely to be raised as part of review, such as may occur in
response to a request to advance in maturity level, by the TAG, Advisory
Committee, Advisory Board, or Director? If so, mark v1.
(For example, known privacy, security, or accessibility concerns.)

5. Is today’s date after April 30, 2016.? If so, push the issue to vNext.
(At some point, it will become too late for us to address bugs and still
meet the deadline. If we do not have agreement on an identified fix by this
date, the issue will be pushed to vNext.)

6. Is there current agreement that a known problem exists and needs to be
fixed in v1? If so, mark it v1 and work to identify a solution ASAP (such
that it falls into step #3).

7. Move the issue to vNext.


We recognize that it is likely that some desirable features may be deferred
to vNext, but this is necessary to achieve the timeline above. We
appreciate your cooperation and assistance in helping to resolve issues and
get both specs to Recommendation.


-- The EME and MSE editors