2022 Proposed Charter Update

Music Notation Community Group Charter

Start Date: 5 August 2015
Charter Revision Date: 18 January 2022

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 Community Group documents, maintains and updates 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 and SMuFL specifications.

The group is developing a new specification to embody this broader set of use cases and technologies, under the working title of MNX. The MNX specification is 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. A primary design goal for MNX is ease of migration from MusicXML.

The group is proposing the development of an additional new specification to provide a standard, machine-readable source of musical instrument data. This data includes information both for the display and playback of music notation that is specific to each different instrument.

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
Musical instrument databases for use with notated music

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.
Specification and schema of the MusicXML markup language. This would update MusicXML 4.0, delivered in 2021.
Specification of the SMuFL music font standard, and accompanying metadata and schemas. This would update SMuFL 1.4, delivered in 2021.
Specification of the MNX format, with a version 1.0 draft to be completed by the end of 2023.
Specification of the musical instrument database, with a version 1.0 draft to be completed by the end of 2023.

Community Group Reports that are Specifications

Specification and schema of the MusicXML markup language.
Specification of the SMuFL music font standard.
Metadata and schemas accompanying the SMuFL standard.
Specification and schema of the MNX markup language.
Specification and machine-readable data file for musical instrument data.

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 specification, and to develop software to aid in the translation of existing MusicXML content into MNX and vice versa. The Community Group intends to continue development of the software used to produce its specifications. 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. 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.