|
How To Propose New Guidelines
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 StyleGuideline
Process for Idea Champions
- 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.
- Create a new wikipage for the proposal. This should be located at http://wiki.musicbrainz.org/User:(you)/(proposal name).
- The proposal template should be at the top of the page:
{{Template:proposal
|proposal=
|discussion=
|champion=
|rfc=
|rfv=
|status=
|ar=
|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.
- 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.
- 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:
- The expected expiration date for the RFC.
- A brief summary of the proposal.
- A link to the proposal's wikipage.
- 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 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.
- 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:
- The expected passage date for the RFV.
- A brief summary of the proposal, including a summary of any changes which have been made since the RFC.
- A link to the proposal's wikipage.
- 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.
- 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
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 style issues. 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.
- Add the site to the list on the relevant page for the AR.
- 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.
- 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.
- 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 the instrument addition process.
Current Proposals
Next New Proposal Number
Next new proposal number: 258
Proposal numbers 112 - 200 and 206 - 250 have been reserved for RFCs to fill in holes in the guidelines and documentation.
March 2010 Proposal Cleanup
NOTE: Effective March 24, 2010, any proposal which has no Champion will be closed, including any associated proposal pages and trac tickets!
If you do not want to see one of these proposals die, then adopt it today, then make it happen!
Style Proposals
Categorized as Category:Proposed Style.
Advanced Relationship Proposals
Categorized as Category:Proposed Advanced Relationship Type.
| RFC #
| Title & Wikipage
| Champion
| Affects
| Trac ticket
| Status
| RFC
| RFC Date
| RFV
| RFV Date
| Passage Date
|
RFC-4: Redesign of the Vocal Relationship Attribute
RFC-4
| Redesign of the Vocal Relationship Attribute
| BrianFreud
| AR modification
| 1140 4437
| Discussion
|
|
|
|
|
|
RFC-21: Linking Different Artist Names
RFC-21
| Linking Different Artist Names
| None: Caution!
| ?
| ?
| Abandoned
| ?
| ?
| ?
| ?
|
|
RFC-26: Miscellaneous Production Relationship Type/Artwork
RFC-26
| Miscellaneous Production Relationship Type/Artwork
| None: Caution!
| ?
| ?
| Abandoned
| ?
| ?
| ?
| ?
|
|
RFC-29: Narrator Relationship Type
RFC-29
| Narrator Relationship Type
| None: Caution!
| New vocal role
| 1368
| Abandoned
| ?
| ?
| ?
| ?
|
|
RFC-35: Part Of Series Relationship Type
RFC-35
| Part Of Series Relationship Type
| voiceinsideyou
| New release-release, or RG-RG, AR
| ?
| Discussion
|
|
|
|
|
|
RFC-39: Reader Relationship Type
RFC-39
| Reader Relationship Type
| None: Caution!
| New vocal role
| 1370
| Abandoned
| ?
| ?
| ?
| ?
|
|
RFC-52: Supporting Release Relationship Type
RFC-52
| Supporting Release Relationship Type
| BrianFreud
| New release-release AR
|
| RFC+second
| RFC+second
| 2010-03-18
|
| 2010-03-25
| 2010-03-27
|
RFC-55: Speaker Relationship Type
RFC-55
| Speaker Relationship Type
| None: Caution!
| New vocal role
| 1731
| Abandoned
| ?
| ?
| ?
| ?
|
|
RFC-68: Add Has News Coverage AR
RFC-68
| Add Has News Coverage AR
| Original ruoak; currently BrianFreud
| New release-URL AR
| 5636
| Discussion
| RFC, RFC2
| 2010-02-28, 2010-03-15
|
| In discussion
|
|
RFC-69: Defining instruments and vocals for members of bands
RFC-69
| Defining instruments and vocals for members of bands
| None: Caution!
| Artist-artist AR enhancement
| 1141
| Abandoned
|
|
|
|
|
|
RFC-83: Add track-url Work-URL Wikipedia AR
RFC-83
| Add track-url Work-URL Wikipedia AR
| BrianFreud
| New track-URL AR
| 3852
| Delayed until work ARs are opened to debate
|
|
|
|
|
|
RFC-84: Add 'provides discographic information about' AR
RFC-84
| Add 'provides discographic information about' AR
| BrianFreud
| New track-URL AR
| 3734
| In development
|
|
|
|
|
|
RFC-86: Add Release-Track Relationship for pre-gap tracks
RFC-86
| Add Release-Track Relationship for pre-gap tracks
| None: Caution!
| New track-release AR
| 4235
| Abandoned
|
|
|
|
|
|
RFC-87: Add 'is a project of' AR
RFC-87
| Add 'is a project of' AR
| None: Caution!
| New artist-artist AR
| 1739
| Abandoned
|
|
|
|
|
|
RFC-88: Add microblog/Twitter AR
RFC-88
| Add microblog/Twitter AR
| Andrew John Hughes (gnu_andrew)
| New artist-URL AR
New label-URL AR
| 5330
| In development
|
|
|
|
|
|
RFC-89: Add Facebook AR
RFC-89
| Add Facebook AR
| Andrew John Hughes (gnu_andrew)
| New artist-URL AR
New label-URL AR
| 5329
| In development
|
|
|
|
|
|
RFC-95: Add Live Journal
RFC-95
| Add Live Journal
| None: Caution!
| New artist-URL AR
|
| Abandoned
|
|
|
|
|
|
RFC-97: Expanded Samples Relationship Type
RFC-97
| Expanded Samples Relationship Type
| None: Caution!
| AR enhancement
|
| Abandoned
|
|
|
|
|
|
RFC-98: Allow Instrument Attribute for Members of a Band
RFC-98
| Allow Instrument Attribute for Members of a Band
| None: Caution!
| AR enhancement
|
| Abandoned
|
|
|
|
|
|
RFC-103: Add Changed Name To AR
RFC-103
| Add Changed Name To AR
| None: Caution!
| New artist-artist AR
|
| Discussion died (this RFC has been independently attempted multiple times)
| one RFC, one RFC, others
| 2007-05, 2008-02-09, others
|
|
|
|
RFC-106: Conductor AR Changes
RFC-106
| Conductor AR Changes
| BrianFreud (was luks )
| Conductor and Chorus Master Relationship Types modification
| New AR(s)/AR(s) modification
| In development
| RFC
| (2007-05-03, original)
current: none yet
|
|
|
|
RFC-110: Same Artist With Different Names Suggestion
RFC-110
| Same Artist With Different Names Suggestion
| None: Caution!
| AR style guideline changes
|
| Abandoned
|
|
|
|
|
|
RFC-111: Writer Relationship Type
RFC-111
| Writer Relationship Type
| Chris B (Gecks)
| New AR
|
| Will do a new RFC at some point!
|
|
|
|
|
|
RFC-202: Chorusmaster/Orchestra conductor
RFC-202
| Chorusmaster/Orchestra conductor
| BrianFreud (was gioele)
| New AR
|
| In development
| RFC
| (original: 2008-04-18), current: none
|
|
|
|
RFC-251: Change how we handle Engineers and their roles
RFC-251
| Change how we handle Engineers and their roles
| BrianFreud
| Changes all 9 Engineer ARs, adds attribute to Engineer Position AR
|
| RFC+Seconded
| RFC
| 2010-03-17
|
| 2010-03-24
| 2010-03-26
|
RFC-255: Detail and Clarify Personal Association Relationship Class and its Relationship Types
RFC-255
| Detail and Clarify Personal Association Relationship Class and its Relationship Types: Page 1, Page 2, Page 3
| BrianFreud
| Adds guidelines to PARC, Adds 2 attributes each to Sibling RT and Parent RT, includes RFC-192, RFC-193, RFC-232, and RFC-233
|
| RFC
| RFC
| 2010-03-20
|
| 2010-03-27
| 2010-03-29
|
RFC-256: Clarify Involved With Relationship Type vs Married Relationship Type
RFC-256
| Clarify Involved With Relationship Type vs Married Relationship Type
| BrianFreud
| Adds guideline to Involved With Relationship Type
|
| RFC
| RFC
| 2010-03-20
|
| 2010-03-27
| 2010-03-29
|
RFC-257: Associate attribute
RFC-257
| Associate attribute: Page 1 and Page 2
| BrianFreud
| Adds attribute to the Producer Relationship Type and the Engineer Relationship Type
|
| RFC
| RFC
| 2010-03-20
|
| 2010-03-27
| 2010-03-29
|
Other Proposals
Categorized as Category:Proposal.
| RFC #
| Title & Wikipage
| Champion
| Affects
| Trac ticket
| Status
| RFC
| RFC Date
| RFV
| RFV Date
| Passage Date
|
RFC-3: Advanced Entity
RFC-3
| Advanced Entity (Post-NGS)
| BrianFreud
| Catchall for various post-NGS entity suggestions
|
| Waiting for NGS
|
|
|
|
|
|
RFC-5: Album Rework
RFC-5
| Album Rework
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-6: Artist Type Project
RFC-6
| Artist Type Project
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-11: Change Default Data Quality Proposal
RFC-11
| Change Default Data Quality Proposal (Data)
| BrianFreud
| Voting, Quality, and Edit expiration
|
| On hold until post-NGS, when edit/voting system is given specific attention
| pre-RFC RFC
| 2007-06-19
|
|
|
|
RFC-15: Disentangle Interfaces From Schema
RFC-15
| Disentangle Interfaces From Schema
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-16: Display Inheritance
RFC-16
| Display Inheritance
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-17: Distributed MusicBrainz
RFC-17
| Distributed MusicBrainz
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-24: Location Proposal
RFC-24
| Location Proposal
| BrianFreud
| New entity
|
| In development, Post-NGS
|
|
|
|
|
|
RFC-30: Add Descarga cat #s field
RFC-30
| Add Descarga cat #s field
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-31: Subscribe to release
RFC-31
| Subscribe to release
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-32: Separately identify hidden tracks
RFC-32
| Separately identify hidden tracks
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-33: Add support for displaying and editing related artists
RFC-33
| Add support for displaying and editing related artists
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-34: Add support to become an open source AccurateRip replacement
RFC-34
| Add support to become an open source AccurateRip replacement
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-36: Performance Restructuring Proposal
RFC-36
| Performance Restructuring Proposal
| BrianFreud
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-37: Performances And Recordings Proposal
RFC-37
| Performances And Recordings Proposal
| BrianFreud
| New entity
|
| In development, post-NGS
|
|
|
|
|
|
RFC-40: Reason Not To Treat DVD As CD
RFC-40
| Reason Not To Treat DVD As CD
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-44: Release Data Set
RFC-44
| Release Data Set
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-48: Release Transliteration And Translation
RFC-48
| Release Transliteration And Translation
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-49: Release Type Restructuring Proposal
RFC-49
| Release Type Restructuring Proposal
| BrianFreud
| ?
| 1372
| In development
|
|
|
|
|
|
RFC-50: Removing the clutter
RFC-50
| Removing the clutter
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-57: Make a DAML+OIL ontology for music
RFC-57
| Make a DAML+OIL ontology for music
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-58: Public Namespace URIs
RFC-58
| Public Namespace URIs
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-59: Music Ontology (MO) project
RFC-59
| Music Ontology (MO) project
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-60: Track Grouping
RFC-60
| Track Grouping
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-63: Updating Subscription Mails
RFC-63
| Updating Subscription Mails
| None: Caution!
| ?
| ?
| Discussion
|
|
|
|
|
|
RFC-65: Voting Motivations
RFC-65
| Voting Motivations
| None: Caution!
| ?
| ?
| Abandoned
|
|
|
|
|
|
RFC-75: Add release format: VHS
RFC-75
| Add release format: VHS
| BrianFreud
| New release format
| 5605
| Abandoned, see RFC-93
|
|
|
|
|
|
RFC-76: Add release format: VCD
RFC-76
| Add release format: VCD
| BrianFreud
| New release format
| 4615
| Abandoned, see RFC-93
|
|
|
|
|
|
RFC-77: Add release format: SVCD
RFC-77
| Add release format: SVCD
| BrianFreud
| New release format
| 4615
| Abandoned, see RFC-93
|
|
|
|
|
|
RFC-78: Add release format: 7" vinyl
RFC-78
| Add release format: 7" vinyl
| Per Øyvind Øygard (Wizzcat)
| New release format/format+format attribute
| 3941
| Discussion
|
|
|
|
|
|
RFC-79: Add release format: 10" vinyl
RFC-79
| Add release format: 10" vinyl
| Per Øyvind Øygard (Wizzcat)
| New release format/format+format attribute
| 3941
| Discussion
|
|
|
|
|
|
RFC-80: Add release format: 12" vinyl
RFC-80
| Add release format: 12" vinyl
| Per Øyvind Øygard (Wizzcat)
| New release format/format+format attribute
| 3941
| Discussion
|
|
|
|
|
|
RFC-81: Add release format: HDCD
RFC-81
| Add release format: HDCD
| BrianFreud
| New release format
| 3942
| Abandoned, see RFC-93
|
|
|
|
|
|
RFC-93: Add release formats: VHS, VCD, SVCD, Betamax, HDCD, USB Flash Drive, slotMusic
RFC-93
| Add release formats: VHS, VCD, SVCD, Betamax, HDCD, USB Flash Drive, slotMusic
| BrianFreud
| New release formats, would close RFC-75, RFC-76, RFC-77, RFC-81, and address some unknown fields on Release Format.
| 5605 4615 3942, Related to 2565
| RFC3
| RFC RFC2, RFC3
| 2010-03-01, 2010-03-08, 2010-03-15
| RFV1
| 2010-03-22
| 2010-03-24
|
RFC-99: Also Known As
RFC-99
| Also Known As
| None: Caution!
| ?
|
| Abandoned
|
|
|
|
|
|
RFC-100: Rename Legal Name to Birth Name
RFC-100
| Rename Legal Name to Birth Name
| None: Caution!
| ?
|
| Abandoned
|
|
|
|
|
|
RFC-105: New Release Status: "Upcoming"
RFC-105
| New Release Status: "Upcoming"
| None: Caution!
| Unreleased releases
|
| Abandoned
| RFC
| 2007-04-14
|
|
|
|
RFC-108: Add release format: Universal Media Disc (UMD)
RFC-108
| Add release format: Universal Media Disc (UMD)
| BrianFreud
| New release format
| Related to 2565
| RFC3
| original RFC current RFC, RFC3
| 2010-03-06, 2010-03-15
|
| 2010-03-22
| 2010-03-24
|
RFC-252: Require +1 for RFC text prior to moving to RFV
RFC-252
| Require +1 for RFC text prior to moving to RFV
| PBryan
| Proposals process
|
| RFC+Second
| RFC+second
| 2010-03-18
|
| 2010-03-25
| 2010-03-27
|
Pre-Reserved RFCs for cleaning up documentation and guidelines
These are all official entities, relationships, guidelines, or other things which have some minor element which is missing. Most are only a sentence or two, but need an RFC to be made official; this table lists those, and pre-reserves RFC numbers for these future RFCs. As these are intended to be truly short RFCs of only a sentence or two (in almost all cases), most won't actually have proposal pages, only proposal emails.
Fodder for Future Proposals
|
Contact details
