2017 Group Charter

From Music Notation Community Group

2017 Music Notation Community Group Charter

  • Start Date: 5 August 2015
  • Charter Revision Date: 4 July 2017
  • Charter End Date: 17 January 2022
  • Current Charter

Goals

The Music Notation Community Group develops and maintains format and language specifications for notated music used by web, desktop, and mobile applications. The group aims to serve a broad range of users engaging in music-related activities involving notation, and will document these use cases.

Scope of Work

The initial task of the Community Group is to document, maintain and update the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle a broader set of use cases and technologies, including use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML 3.0 and SMuFL specifications.

The group is proposing the development of a new specification to embody this broader set of use cases and technologies, under the working title of MNX. The MNX specification itself consists of three parts:

  • The MNX container format, which can describe and relate an arbitrary number of components and documents which collectively describe a notated work as a whole.
  • The CWMNX format (working title), designed to represent Common Western Music Notation in a tightly specified, semantic fashion in order to deliver a high degree of interoperability between a broad range of applications that require such a representation. CWMNX is designed to leverage as much as possible of the existing MusicXML schema.
  • The GMNX format (working title), designed to represent instantiations of scores in terms of specific visual, performance and audio content and a set of relationships between these facets. GMNX aims to supply a high degree of interoperability to applications that do not depend on particular notational systems or their semantics.

Specific technologies involved in this scope include:

  • The semantic representation of notated music and its performance
  • Graphical rendering of notated music
  • Audible performance of notated music
  • Synchronization of visual and audio media with notated music
  • Music notation font design and organization

Out of Scope

While synchronization of notated music with visual and audio media is in scope, visual and audio media technologies themselves are out of scope for this Community Group.

Deliverables

  • Living document describing use cases for digital musical notation
  • Schema of the MusicXML markup language, version 3.1, to be completed by the end of July 2017.
  • Specification of the SMuFL music font standard, and accompanying metadata and schemas, version 1.2, to be completed by the end of July 2017.
  • Specification of the MNX format, including the container format, CWMNX and GMNX formats, with a version 1.0 draft to be completed by the end of 2018.

Community Group Reports that are Specifications

  • Schema of the MusicXML markup language.
  • Specification of the SMuFL music font standard
  • Metadata and schemas accompanying the SMuFL standard
  • Specification of the MNX container format.
  • Specification and schema of the CWMNX markup language.
  • Specification and schema of the GMNX markup language.

Community Group Reports that are not Specifications

  • Document describing use cases for digital musical notation

Test Suites and Other Software

The Community Group intends to develop a test suite embodying the MNX, CWMNX and GMNX specifications, and to develop software to aid in the translation of existing MusicXML content into CWMNX. All software developed by the Community Group will be Open Source and use the W3C Software License.

Dependencies or Liaisons

The SMuFL specification is best explained and understood in reference to a specific font conforming to that standard. The Bravura music font (owned by Steinberg) is available under an open source license and is an important resource for users of SMuFL.

Community and Business Group Process

Terms in this charter that conflict with those of the Community and Business Group Process are void.

Work Limited to Charter Scope

The group will not publish Community Group Reports that are Specifications on topics other than those listed under "Community Group Reports that are Specifications" above. See below for how to modify the charter.

Contribution Mechanics

Who can make a Contribution

Contributions can only be made by Community Group Participants (so all Contributors have agreed to the Contributor License Agreement). Particular care must be taken by Chairs and Editors to ensure Contributions of content that is implementable comes from Community Group participants.

In particular, individuals who are employed by an organization owning intellectual property within this group's Scope of Work must either join the group as a member of that organization (making it a party to the Contributor License Agreement), or refrain from contributing implementable content.

How to make a Contribution

Community Group Participants agree that all Contributions will be documented in pull requests and commits for a particular document in the group's GitHub repository.

Specifications

For Contributions to Specifications, if someone other than the Contributor makes the pull request, the pull request should indicate who the request was made on behalf of and should provide a reference to the relevant archived GitHub Issue or group mail thread where practical. The information should be specific enough to identify the Contributor easily as well as a clear intention to Contribute to a particular Specification.

If you are not the sole contributor to a contribution (pull request), please identify all contributors in the commit message. In the commit, include on a new line,

Contributors: +@githubusername1, +@githubusername2, ...

Software

The Community Group will produce no software beyond what is specified in Test Suites and Other Software above. All software developed by the Community Group will be Open Source and use the W3C Software License.

Transparency

The group will conduct all of its technical work in public via the group's public contributor mailing list and GitHub issues lists. For convenience, GitHub pull requests will be archived to the group's contrib list. Other contributions may be directly posted to the contrib list.

Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public contributor mailing list.

Decision Process

Consensus Decisions

This group will seek consensus decisions by the 3 co-chairs, taking input and direction from the community group at large. After discussion (via the mailing lists or issues lists) and due consideration of different opinions, the Chair should record a decision and any objections.

A common way to determine consensus for important decisions is to conduct a Call for Consensus (CfC) where the Chair puts a proposal to the group on the public mail list and asks for feedback from the Participants within some period of time that is at least 7 days. Silence implies consent. Direct feedback is encouraged, especially to weigh the degree of consensus when there is dissent.

Chair Selection

Participants dissatisfied with the actions of the Chair may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the request, may take any action including no action.

Amendments to this Charter

The group may decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.

Retrieved from "https://www.w3.org/community/music-notation/wiki/index.php?title=2017_Group_Charter&oldid=592"