Proposals

Making changes to the style guidelines, adding new types of relationships, and other similar changes need to be accepted by the community. For that, the proper proposal process must be followed.

Definitions

RFC (Request for Comments)

The initial period, in which a proposal is discussed. Lasts at least 7 days.

RFV (Request for Veto)

The period in which the proposal can be vetoed. Lasts at least 2 days.

Style Leader

The user who guides the process and keeps it from getting stuck. If the list cannot reach consensus they will make a decision. Currently Nikki and reosarevok.

Style Elder

The benevolent dictator of MusicBrainz style issues. If the process goes off the rails, or if someone disputes the style leaders' decisions, the elder steps in. Currently RobertKaye a.k.a. ruaok

The Standard Process

Preparation

Come up with an idea for something new or something that should be changed. It sometimes makes sense to discuss the idea a bit on the style mailing list before going forward, as it will help people show you issues with it that you should take into consideration to make your proposal more likely to pass. This is not required though; if you have a clear idea of how to solve what you want to solve you can always go on directly.

Create a ticket for the proposal in our bug tracker (choose MusicBrainz Style as the project). If you don't send a proposal in more or less 24 hours after creating the ticket, it will be (temporarily) closed and set to the "RFC Required" status - once the proposal is sent it will be reopened.

If you're proposing a new relationship type, see the section below for the information that is needed.

If the proposal will require creating or modifying a wiki page, create a new wiki page for it. This should be located at http://wiki.musicbrainz.org/User:(username)/(proposal name). Use the proposal template on the page; documentation is at the template page.

RFC

Send an RFC announcement to the style list.

• The subject of the RFC mail must start with "RFC:" and include a summary of it (for example, the title of the jira ticket)
• The body of the email should contain:

1. The expected expiration date for the RFC.
2. A brief summary of the proposal.
3. A link to the proposal's page in jira and, if applicable, in the wiki.
4. Links to any previous discussion (IRC, style list, users list, forums, etc.) which led to the proposal.

During the period where the RFC is active, discussion of it will occur on the style list.

• Anyone can change the proposal's wiki page, though it is strongly encouraged that any changes which go beyond minor formatting, spelling, or example changes should be left to the proposer.

• If you are not the proposer, and you disagree with the proposal so strongly that you feel an entirely different one needs to be created, you should create a new wiki page for your version (following the same User:X/Title format). Do not rewrite the original proposal wiki page and attempt to take over the idea from the original proposer!

• Where there is disagreement, the proposer should work to find consensus.

• On minor points, the proposer maintains control of the proposal. However, ignoring complaints will probably cause vetos during the later RFV period.
• If discussion on an RFC is still ongoing, and it doesn't feel like the proposal is ready to pass, the RFC period may be extended. The RFC period only defines the minimum time for debate, not a maximum.

Before an RFC may move into RFV status, another user must endorse it with "+1" in an email to the style list, indicating that, in its current state, it has been reviewed and is acceptable to that member. Any changes to the text of the RFC prior to sending an RFV clear that +1 and reset this requirement.

RFV

When the RFC's initial period has expired, the proposer should send an RFV for the proposal.

• The subject of the RFV mail should be the same as the RFC one, but substituting "RFC:" with "RFV:"
• The body of the email should contain:

1. The expected passage date for the RFV.
2. A brief summary of the proposal, including a summary of any changes which have been made since the first RFC mail.
3. A link to the proposal's page in jira and, if applicable, in the wiki.

During the RFV period, any user may veto the RFV. However, vetos must be reasoned (a veto like "I don't like this proposal" will be ignored). Vetos must be publicly cast on the style list, and should detail what problems are believed to remain in the RFV, and what changes could be made such that the veto would be cleared. These suggested changes must be reasonable; if the changes would entail a rewrite, or rethink, of the proposal itself, then a counter-proposal should be created, and the decision as to which proposal will pass should be left to the style list.

• If an RFV receives a reasoned veto, the proposal reverts to an RFC. There is no minimum time period at this point, but no new RFV should be attempted until the problems raised in any vetos have been discussed and/or addressed. A proposal may revert to an RFC, or have replacement RFCs sent, as many times as is needed.
  • If it becomes clear that a proposal which has general agreement will keep being held indefinitely by a single veto, the style leaders have the right to decide on the issue and override the veto. This power will be used as little as possible - consensus is the ideal goal of the style process.
• If the end of the RFV period is reached, and no vetos have been cast, then the proposal has passed. The proposer should now make sure that the changes (editing or moving wiki pages, entering edits, etc.) are applied, either on his own or with the help of a style leader. Remember to remove the proposal template from the proposal's wikipage!
  • Note to wiki moderators: when moving a passed AR proposal from the Proposal: namespace to the main namespace, please remember to remove '|proposal = 1' from the text.

Special Procedures

Relationship types

In order to add a relationship type, the following information should be included with the proposal:

• Which pair of entities it should be added for.
• Short link phrases for both entities to be used when listing relationships on the entity pages.
• A long link phrase which links the two entity types as a sentence (the entity type which comes first alphabetically should go on the left).
• A description, which can be seen when adding a relationship using this relationship type.
• At least one example, which should be added after the relationship type has been created.

For example, for the existing artist-URL Wikipedia relationship type:

• The pair of entities is artist-URL.
• The short link phrases are "Wikipedia" (which is used on the artist page) and "Wikipedia page for" (which is used on the URL page).
• The long link phrase is "has a Wikipedia page at", i.e. "<artist> has a Wikipedia page at <URL>".
• The description is "Points to the Wikipedia page for this artist."
• The example is The Temptations has a Wikipedia page at https://en.wikipedia.org/wiki/The_Temptations.

Lyrics and score whitelists

These relationships only allow links to whitelisted sites. To add any site to the whitelist for any one of these relationships, the following additional procedure must be followed.

1. Send an RFC requesting the addition of the site using the normal proposal process.

   • The RFC should be limited to covering only 1 site.
   • The RFC must provide rationale and evidence for why the site can reasonably be believed to have permission to contain the content to which we would be linking.

2. The style list will then make sure that the site itself is legal; that it has a right/license/whatever to store the content (lyrics/scores) to which the relationships would be linked.

   • If any situation arises where "legal" is questionable depending on local laws, MusicBrainz is based in California, so US/California law wins.

3. Once the RFV has passed, permission must be obtained, in writing (email is fine), from the site which would be added to the whitelist.

   • This permission may be requested prior to the passage of the RFV.

Only when permission has been received and an RFV has passed may the site be added as a whitelisted site for the applicable relationship type(s).

Adding new instruments

These do not go through the normal style process. Instead, they use the instrument addition process.