Re: Proposal: use only github for new MSE spec bugs

One further label that we added to MSE's GitHub issue tracker real-time
during today's TPAC Media TF MSE F2F is "breaking change":
This label is meant to indicate that the fix for the issue (which could
also be marked with other labels like "needs implementation", etc) is
likely to break web author's implementations. Examples of this might be a
rename of an API method or member which is already in common usage across
one or more implementations.

There are two MSE issues currently marked with this label:
https://github.com/w3c/media-source/issues?q=is%3Aopen+is%3Aissue+label%3A%22breaking+change%22

For MSE, further discussion among chair, editors, and possibly the director
would be needed to understand if fixing issues with this label would cause
CR re-entry, if the issues should be V.Next, or if the actual breaking
impact is significant limited or easily mitigated.

Matt

On Mon, Oct 19, 2015 at 5:57 PM, David Dorwin <ddorwin@google.com> wrote:

> I support these values for EME as well. (Many of the labels are based on
> EME labels or their original intent.) I've updated the EME labels to match,
> though we don't currently use the new “needs feedback” label.
>
> David
>
> On Mon, Oct 19, 2015 at 11:21 AM, Matt Wolenetz <wolenetz@google.com>
> wrote:
>
>> On Thursday, October 15, Jerry and I went through the current set of open
>> MSE spec bugs on GitHub (approximately 22) and applied labels, milestone,
>> and assignee. The result is a rebalanced editor workload along with
>> preliminary expectations of what next steps are needed for each issue.
>>
>> To assist similar MSE spec bug triaging in the future, as well as to help
>> inform potentially similar EME spec bug triaging, I have summarized the
>> meanings of the labels and milestone selections we applied in this round of
>> MSE triage.  I welcome any clarifying corrections; the purpose of this
>> summary is to help get everyone on the same page.
>>
>> While preparing this summary, some further clarifications and actions
>> were discovered:
>>
>> 1) Generally, we should consider closing V.Next MSE issues (for now, at
>> least).
>>
>> 2) We should change the currently-labeled “needs author input” to “needs
>> feedback” and assign to appropriate reporter to obtain that feedback.
>> During triage, we misunderstood “author” to mean bug author, not web
>> author. We’ll also need to add a separate, new, “needs author input” label
>> for future usage for when we might need input from web authors.
>>
>> The following is a snapshot of a section of the README.md from
>> https://github.com/w3c/media-source/pull/33 (GitHub will have slightly
>> different markdown formatting versus this email, but the content is
>> otherwise the same.)
>>
>> == Labels ==
>>
>> Each bug may have multiple labels.
>>
>> “needs feedback”
>>
>> The issue is pending further clarification from the assignee, likely the
>> original bug filer or another who reported aspects of the issue in the
>> bug’s history. The feedback request needs to be in a comment associated
>> with the addition of this label, along with a request for reassignment back
>> to an editor once feedback is provided.
>>
>> “needs author input”
>>
>> The editors are seeking input from web authors on the issue. For example,
>> whether a requested change is useful or how best to expose information.
>>
>> “needs follow-up”
>>
>> The assignee, likely an editor, needs to investigate more deeply before
>> we can decide if this “needs implementation” or to otherwise move forward.
>> The editors have discussed the issue and do not need to discuss it further
>> until we have the resulting follow-up from the assignee. This includes
>> things like determining external spec dependencies, seeking input from
>> other spec owners and/or WGs, confirming the understanding of the nature of
>> the bug, and beginning to formulate a path to a solution.
>>
>> This doesn’t necessarily mean follow-up has “Started” or is “In Progress.”
>>
>> “needs implementation”
>>
>> The steps needed to resolve this issue are clearly understood and agreed
>> upon. This likely means drafting and committing a spec change, possibly via
>> a pull request. No further discussion is necessary at this time, though
>> review of the change may still be appropriate. Should that change, this
>> label should be removed.
>>
>> For a bug to be labeled with this, it needs to be understood well enough
>> and in scope of the marked milestone. Otherwise, “needs follow-up” or
>> punting milestone might be options.
>>
>> This label does not refer to user agent implementations.
>>
>> “blocked”
>>
>> Some external dependency or another GitHub issue identified in comment
>> associated with this label’s addition is (or might be) blocking progress on
>> this bug.
>>
>> “feature request”
>>
>> The issue is related to or requesting a new use case or capability not
>> currently (explicitly) covered by the spec. Depending on the nature and
>> impact of the request and the stage of the spec, it may be assigned to a
>> future milestone.
>>
>> “interoperability”
>>
>> Resolution of this issue is particularly important for interoperability
>> among user agents. This may include breaking API changes, issues related to
>> media compatibility across user agents, or ambiguous parts of the spec that
>> could lead to different incompatible interpretations. There may be known or
>> probable differing interpretations in implementations of the associated
>> portion of the spec. If the identified issue is not addressed, there is a
>> high likelihood of meaningful interoperability problems. The fix for the
>> issue would need to provide a clear direction to prevent differing
>> interpretations by user agents.
>>
>> “wontfix”, “invalid”, “duplicate”
>>
>> Self-explanatory :)
>>
>> Issues with these labels should always be closed (unless they were
>> re-opened at which time an editor should probably remove these labels if
>> the re-opening is accepted).
>>
>>
>> == Milestones ==
>>
>> “V#”: A bug in version # of the spec.
>>
>> Currently, V1 is the first version of MSE (in CR in Q4 2015).
>>
>> “V.Next”:
>>
>> Perhaps to be addressed by some later version of the spec; not currently
>> expected to be in scope of specific version of the spec. Typically, this
>> milestone is correlated with issues labeled “feature request”. This is
>> equivalent to Bugzilla’s RESOLVED LATER status. As such and to keep the
>> issue tracker focused, issues with this milestone will generally be closed.
>> When work on a new version of the spec starts, the V.Next issues, including
>> those that are closed, should be reviewed and considered for the new
>> version.
>>
>> (no milestone):
>> The issue has not been triaged or the editors are currently discussing.
>>
>> --
>>
>> Matt
>>
>>
>> On Tue, Oct 13, 2015 at 4:24 PM Matt Wolenetz <wolenetz@google.com>
>> wrote:
>>
>>> All of the currently active w3c bugzilla MSE spec bugs have now been
>>> migrated to GitHub.
>>> We have 23 open MSE spec bugs in total at the moment.
>>> We'll also need to keep an eye on the w3c bugzilla to catch any stray
>>> new bugs or bug updates that might occur (incorrectly) there and migrate
>>> them to GitHub as appropriate.
>>>
>>> On Tue, Oct 13, 2015 at 3:24 PM Matt Wolenetz <wolenetz@google.com>
>>> wrote:
>>>
>>>> The spec update PR is pending review @
>>>> https://github.com/w3c/media-source/pull/13.
>>>>
>>>> On Tue, Oct 13, 2015 at 3:11 PM Matt Wolenetz <wolenetz@google.com>
>>>> wrote:
>>>>
>>>>> Thanks for the pointer. It looks like the origin of that utility
>>>>> script (webcomponents) no longer uses it, either. I'll remove it for MSE
>>>>> for now.
>>>>> Matt
>>>>>
>>>>> On Tue, Oct 13, 2015 at 3:03 PM David Dorwin <ddorwin@google.com>
>>>>> wrote:
>>>>>
>>>>>> I believe there is a <script> tag and some <meta> tags near the top
>>>>>> of the ReSpec source. I commented them out in EME since it pointed to
>>>>>> Bugzilla. I'm sure the script could be adapted; it's possible someone has
>>>>>> done that since I last looked.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On Tue, Oct 13, 2015 at 2:55 PM, Matt Wolenetz <wolenetz@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> What's the correct way of removing the "See a problem? Select text
>>>>>>> and [file a bug]" box at the top right of the MSE spec? I noticed this
>>>>>>> refers to the w3c bug tracker; also, the EME spec does not include this box.
>>>>>>>
>>>>>>> On Tue, Oct 13, 2015 at 2:14 PM Jerry Smith (IEP) <
>>>>>>> jdsmith@microsoft.com> wrote:
>>>>>>>
>>>>>>>> Perfect.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* Paul Cotton
>>>>>>>> *Sent:* Tuesday, October 13, 2015 11:59 AM
>>>>>>>> *To:* Matt Wolenetz <wolenetz@google.com>; David LaPalomento <
>>>>>>>> dlapalomento@brightcove.com>
>>>>>>>> *Cc:* Jerry Smith (IEP) <jdsmith@microsoft.com>; <
>>>>>>>> public-html-media@w3.org> <public-html-media@w3.org>
>>>>>>>> *Subject:* RE: Proposal: use only github for new MSE spec bugs
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> >I assume I should resolve the original w3c bug as "MOVED" with an
>>>>>>>> appropriate link to the github bug.
>>>>>>>>
>>>>>>>> Works for me!
>>>>>>>>
>>>>>>>> Sent from my Windows Phone
>>>>>>>> ------------------------------
>>>>>>>>
>>>>>>>> *From: *Matt Wolenetz
>>>>>>>> *Sent: *13/10/2015 2:10 PM
>>>>>>>> *To: *David LaPalomento; Paul Cotton
>>>>>>>> *Cc: *Jerry Smith (IEP); <public-html-media@w3.org>
>>>>>>>> *Subject: *Re: Proposal: use only github for new MSE spec bugs
>>>>>>>>
>>>>>>>> As discussed in this morning's media task force MSE teleconf, I'll
>>>>>>>> file new github issues for each of the currently active w3c bugzilla MSE
>>>>>>>> spec bugs and link to them from the w3c bugs, and update the bug tracker
>>>>>>>> links in the editor's draft.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Paul/Jerry*: Once I've created the corresponding github bug, I
>>>>>>>> assume I should resolve the original w3c bug as "MOVED" with an appropriate
>>>>>>>> link to the github bug. Is this correct? This would allow us to more easily
>>>>>>>> discover newly filed w3c MSE bugs that might still happen after this
>>>>>>>> migration.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Matt
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 9, 2015 at 8:23 AM David LaPalomento <
>>>>>>>> dlapalomento@brightcove.com> wrote:
>>>>>>>>
>>>>>>>> As a developer very interested in MSE but less involved in the w3c
>>>>>>>> process, a big +1 to this proposal. Having both trackers is a bit confusing
>>>>>>>> and I suspect having more activity occurring in github will encourage the
>>>>>>>> huge community active there to participate more.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 8, 2015 at 8:17 PM, Paul Cotton <
>>>>>>>> Paul.Cotton@microsoft.com> wrote:
>>>>>>>>
>>>>>>>> > Would it make sense to make placeholder github issues for
>>>>>>>> existing, open, w3c MSE bugs, and restrict all MSE spec bug activity to
>>>>>>>> github issues?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I have no problem with us doing as long as we add a comment to each
>>>>>>>> of the former 19 Bugzilla bugs pointing forward to the appropriate GitHub
>>>>>>>> issue.   I suggest you go ahead and do this ASAP.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> >2. Is it possible to update the w3c bug tracker to indicate that
>>>>>>>> new MSE bugs or activity on existing w3c MSE spec bugs should occur on
>>>>>>>> github's issue tracker?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I am not sure how to do this.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> > Which versions of the MSE spec would need updating to reference
>>>>>>>> using github as the primary issue tracker for spec bugs (just the current
>>>>>>>> editor's draft, or some retro-active editing of earlier published snapshots
>>>>>>>> of the spec too?)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> W3C does not normally change even the Status section of published
>>>>>>>> documents.  And for older documents we would NOT want to get rid of the
>>>>>>>> pointer to the Bugzilla component since historically it is the right
>>>>>>>> pointer.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I would recommend that the best way to make sure that people are
>>>>>>>> looking at a TR page specification with the correct Status information is
>>>>>>>> to get going on turning on automatic publication of Editor’s draft for MSE
>>>>>>>> as we have for EME.  I believe Jerry has an action to look into that.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> /paulc
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Paul Cotton, Microsoft Canada
>>>>>>>>
>>>>>>>> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
>>>>>>>>
>>>>>>>> Tel: (425) 705-9596 Fax: (425) 936-7329
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* Matt Wolenetz [mailto:wolenetz@google.com]
>>>>>>>> *Sent:* Thursday, October 08, 2015 7:18 PM
>>>>>>>> *To:* <public-html-media@w3.org>
>>>>>>>> *Subject:* Proposal: use only github for new MSE spec bugs
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> At the moment, we are using both w3c and github to track open MSE
>>>>>>>> spec bugs.
>>>>>>>>
>>>>>>>> At the recent FOMS 2015 & Demuxed 2015 conferences, we heard praise
>>>>>>>> from other attendees of the move by EME to primarily using github's issue
>>>>>>>> tracker.
>>>>>>>>
>>>>>>>> In light of EME's move to gh for new issue tracking, external
>>>>>>>> appeals of similar for MSE, and to consolidate tracking of all new MSE spec
>>>>>>>> bugs, I propose that we move to using solely github for tracking newly
>>>>>>>> opened MSE spec bugs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Before moving forward, I would like to understand better:
>>>>>>>>
>>>>>>>> 1. Would it make sense to make placeholder github issues for
>>>>>>>> existing, open, w3c MSE bugs, and restrict all MSE spec bug activity to
>>>>>>>> github issues?
>>>>>>>>
>>>>>>>> 2. Is it possible to update the w3c bug tracker to indicate that
>>>>>>>> new MSE bugs or activity on existing w3c MSE spec bugs should occur on
>>>>>>>> github's issue tracker?
>>>>>>>>
>>>>>>>> 3. Which versions of the MSE spec would need updating to reference
>>>>>>>> using github as the primary issue tracker for spec bugs (just the current
>>>>>>>> editor's draft, or some retro-active editing of earlier published snapshots
>>>>>>>> of the spec too?)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Matt
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>