Issue Review Process

Hi Group,

We are ready to enter an active period for the group in which we make
steady progress in refining and building out the MNX specification, with
the ambitious goal of finishing an initial draft by the end of the year.

The largest part of this progress is going to be the creation,
consideration and resolution of issues in the MNX GitHub repository, via
online discussion involving all of us. The issue list plays a central role
in the work of the group because of the ease with which issues can be
tracked and managed on GitHub, and because issue-based discussions do a
good job of clearly separating concerns when used properly.

To make this process easier and more orderly, we've created a Review
Process document that can act as a guide for our examination of issues. It
is located on the wiki at:

    https://www.w3.org/community/music-notation/wiki/Review_Process

The biggest thing to know about this process is that at any given point,
we'll be focusing on a smallish "batch" of issues that include those of the
highest priority to the group, and hoping to get the CG to review and
discuss that batch over a period of a few weeks, then create a new or
augmented batch as issues get resolved. This will require some ongoing care
and attention from us all to keep things moving.

We're asking members to look at the process and respond in this thread with
your thoughts or suggestions. We don't expect it to be perfect from the
outset, and the chairs will certainly amend it as needed based on what we
find is working or not working. I'm including the text below for your
convenience.

Later in the week, the chairs will follow up and announce the initial set
of issues for us to focus on, and we'll get going in earnest!

Best to all of you,

Daniel, Michael and Joe

================

*Music Notation CG Spec Review Process*

This document describes the general process followed by the W3C Music
Notation Community Group (MNCG) to review issues raised by group members.

*Goals*
The goals of the process are:

   - Timely discussion, review and resolution of issues.
   - Broad coverage of all significant topics
   - Directing attention first to the highest-priority issues
   - Grounding the discussion in use cases wherever possible
   - Openness, fairness and mutual respect
   - Maintaining momentum for the group's work
   - Keeping good records of arguments and rationales for decisions
   - Avoidance of confusing repetition and duplication


*Scope*
All spec review issues must be filed on the appropriate GitHub repository
by a CG member.

Only issues filed on the GitHub repositories maintained by the chairs will
be considered for discussion. Issues in other repositories are out of scope.

*Process Outline*
An issue progresses through the following steps:

Filing: a CG member creates the issue. Issues must identify an aspect of
the present specification to be changed, added or removed, and must present
or identify a use case and show how the issue affects it. (Issues filed by
non-CG members will be closed with a request that the filer join the CG. If
the filer joins the CG, the issue can be re-opened and follow the rest of
the review process.)

Initial examination: The chairs will look at newly filed issues and close
them as duplicates, close them as already resolved, refactor them or
request clarification. Those which have been examined will be placed in the
"Uncommitted" milestone.

Duplicates and Already Resolved: Issues appearing to be duplicates of
existing issues will be closed immediately with a reference to the
duplicate issue. Issues that appear to be already resolved will be closed
immediately with a reference to the specification, and placed in the "V1"
milestone . In case of a mistake, the issue can be further clarified by the
creator.

Refactoring: Any issue may be split out into multiple individual issues for
clarity by the chairs. This will typically be done early on.

Request for clarification: An issue whose nature or relevance is unclear up
front, will be immediately assigned to its creator for clarification, and
labeled "Needs Clarification". Issues remaining in this state without
progress will ultimately be recommended for closure by the chairs.

Active Review: On a roughly weekly basis, the chairs will identify the
highest priority issues for group review and discussion. All such issues
will be labeled "Active Review". The chairs will email the group weekly
with a reminder of the current list that is in active review. When placing
an issue into Active Review, the chairs may recommend a specific resolution
of the issue and provide their reasoning.

Review Discussion: Issues in Active Review undergo discussion by the CG,
within their respective GitHub issue threads. A discussion period of at
least two weeks is expected. The discussion may continue as long as new
arguments are being advanced in favor of different resolutions or while
additional members contribute to the discussion, in the judgment of the
chairs. Discussion of issues on the CG mailing list is discouraged.

Proposed Resolution: Following discussion, the chairs will record a
resolution in the issue thread and remove the "Active Review" label. The
following outcomes may occur:

   - Inclusion of the issue in the V1 milestone
   - Deferral of the issue to the V.Next milestone
   - Closure of the issue

Pull Request Review: For V1 milestone issues, a pull request is created and
the issue is marked as "PR Review".

Final Resolution: The pull request is merged, and the issue is closed.

Reopening: If new arguments and reasons emerge after resolution, in the
judgment of the chairs, issues may re-enter Active Review.