Proposals

From MusicBrainz Wiki
Revision as of 14:04, 24 February 2010 by BrianSchweitzer (talk | contribs) (Initial page creation/draft)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Proposals

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.

Definitions

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, MusicBrainzDevelopment, and the general culture of the project, you are welcome to subscribe to the StyleMailingList and join the discussions.

Process for Idea Champions

  1. Come up with an idea for something new or something that should be changed.
  2. Create a new wikipage for the proposal.
    • The proposal template should be at the top of the page:
    {{Template:proposal
    |proposal=
    |discussion=
    |champion=
    |rfc=
    |rfv=
    |status=
    |style=
    |trac=
    }}
    proposal, rfc, rfv, status: Leave these blank
    discussion: A link to the initial discussion (IRC, forums, or style list) of an idea.
    champion: You.
    style: If your proposal changes a style guideline, then "true", otherwise, "false".
    trac: The trac ticket number for your proposal.
  3. 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.
  4. 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.
  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

Definitions

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.

Current Proposals

Next new proposal number: 2

RFC # Title & Wikipage Champion Affects Trac ticket Status RFC RFC Date RFV RFV Date Passage Date
1 AudioBook Style None Audiobooks 2147 Inactive