From MusicBrainz Wiki
< User:PBryan
Revision as of 04:42, 13 December 2010 by BrianSchweitzer (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
Status: Implemented! This page describes a proposal which is now official and has been implemented.

Proposal number: RFC-252
Champion: Paul C. Bryan (pbryan)
Current status: Passed and Implemented
This proposal was not tracked in Trac.


Changes to MusicBrainz are agreed to using this proposal process.

The process is simple. Someone has an idea, either for something new, or for a change to how something existing is done. After discussion of the idea has taken place, one person takes control of the idea. This person is then known as the Idea Champion for that proposal. The Idea Champion has the responsibility for moving the idea from a vague concept to a clear proposal, then working for Style Council passage of the proposal.

Though it is somewhat dated, Turning Your Ideas into Reality is well worth a read.


Idea Champion
The person who currently is handling a proposal.
Style Council
Any members of the Style mailing list who wish to take part in discussion of a proposal. There is no formal membership to the style council. If you are an interested contributor to MusicBrainz and reasonably well informed about existing StyleGuidelines, MusicBrainz development, and the general culture of the project, you are welcome to subscribe to the Style mailing list and join the discussions. Also see the history of the Style Council.

Process for Idea Champions

  1. Come up with an idea for something new or something that should be changed. While somewhat out of date, the points raised on this former checklist for style changes are still worth consideration as part of your proposal.
  2. Create a new wikipage for the proposal. This should be located at name).
    • The proposal template should be at the top of the page:
  1. proposal, rfc, rfv, status: Leave these blank
    discussion: A link to the initial discussion (IRC, forums, or style list) of an idea.
    champion: You.
    ar: If your proposal changes or adds an Advanced Relationship, then "true", otherwise leave the value blank.
    style: If your proposal changes or adds a style guideline, then "true", otherwise leave the value blank.
    trac: The trac ticket number for your proposal.
  2. Send an RFC announcement to the style list.
    • The RFC should have "RFC:" at the beginning of the subject line.
    • 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 wikipage.
    4. Links to any previous discussion (IRC, style list, users list, forums, etc) which led to the proposal.
  3. During the period where the RFC is active, discussion of it will occur on the style list.
    • Anyone can change the proposal's wikipage, though it is encouraged that any changes which go beyond minor formatting, spelling, or example changes should be left to the Idea Champion.
    • If you are not the Idea Champion, and you have sufficient disagreement with the proposal that you feel an entirely different proposal needs to be created, a new proposal wikipage should be created, for which you would become that proposal's Idea Champion. Do not rewrite the original proposal wikipage and attempt to take over the idea from the original Idea Champion!
    • Where there is disagreement, the Idea Champion should work to find consensus.
    • On minor points, the Idea Champion maintains control of the proposal. However, for the Idea Champion, you ignore dissent at the risk of the proposal - disagreement can easily become vetos during the RFV period.
    • If discussion on an RFC is still ongoing, and there is not yet agreement that the proposal is ready to pass, the RFC period may be extended. The RFC period only defines a minimum, not a maximum, time period for debate.
  4. Before RFC text qualifies for RFV, another style council member must endorse it with a "+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 RFC text prior to RFV repeats this requirement.
  5. When the RFC's initial period has expired, the Idea Champion (or a Style Leader) will send out an RFV for the proposal.
    • The RFV email should have "RFV:" at the beginning of the subject line.
    • 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 RFC.
    3. A link to the proposal's wikipage.
  6. During the RFV period, any member of the style council may veto the RFV. However, vetos must have merit (no vetos simply because "I don't like this proposal"). 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 wikipage should be created, and the decision as to which proposal will pass should be left to the style council.
    • If an RFV receives a 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.
  7. If the end of the RFV period is reached, and no vetos have been cast, then the proposal has passed. The Idea Champion is now responsible for ensuring that the changes described by the proposal are enacted (changing wiki pages, entering edits, creating trac or jira tickets, etc.). This includes remembering to remove the proposal template from the proposal's wikipage!

Time Periods

  • RFC: 7 days
  • RFV: 2 days

Style Leaders

Style Elder


RFC (Request for Change)
The initial discussion period for any proposal
RFV (Request for Veto)
The decision period for any proposal
Style Leader
They guide the process and keep it from getting stuck. If the council cannot reach consensus they will make a decision. This position was previously called "secretary".
Style Elder
The benevolent dictator of MusicBrainz StyleIssues. If the process goes off the rails, or if someone disputes the style leaders' decisions, the elder steps in.

Special Procedures

Has Cover Art At, Has Lyrics At, and Has Score At Relationship Types

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

  1. Add the site to the list on the relevant page for the AR.
  2. Using the normal proposal process, send a RFC requesting the addition of the site.
    • The RFC should be limited to covering only 1 site.
    • Rhe 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.
  3. The Style Council will then make sure that the site itself is legal; that it has a right/license/whatever to store the content (lyrics/scores/cover art) which which the relationships would be link.
    • If any situation arises where "legal" is questionable depending on local laws, MusicBrainz is based in California, so US/California law wins.
  4. 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 a RFV has passed may the site be added as a whitelisted site for the applicable relationship type(s).

Adding new instrument types

These do not go through the Style Council process. Instead, they use [instrument addition process].

Current Proposals


Fodder for Future Proposals