Difference between revisions of "Proposals"
From MusicBrainz Wiki
Jump to navigationJump to search (→Next New Proposal Number: increase next new proposal number) |
|||
| Line 106: | Line 106: | ||
=== Next New Proposal Number === |
=== Next New Proposal Number === |
||
| − | Next new proposal number: |
+ | Next new proposal number: 331 |
''Proposal numbers 112 - 200 and 206 - 250 have been reserved for RFCs to fill in holes in the guidelines and documentation.'' |
''Proposal numbers 112 - 200 and 206 - 250 have been reserved for RFCs to fill in holes in the guidelines and documentation.'' |
||
Revision as of 00:03, 17 July 2011
Proposals
Changes to MusicBrainz are made 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 Style Guidelines, 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
- 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/Proposal:(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: The RFC number from this page
- 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, if there is one.
- Send a 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 a 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.
- Before a RFC may move into RFV status, another style council member 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 RFC text prior to RFV clear that +1 and reset this requirement.
- When the RFC's initial period has expired, the Idea Champion (or a Style Leader) will send out a 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 a RFV receives a veto, the proposal reverts to a 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 a 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!
- 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.
Time Periods
- RFC: 7 days
- RFV: 2 days
Style Leaders
Style Elder
- ruaok, aka RobertKaye
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 'in-progress' 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.
- 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.
- 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: 331
Proposal numbers 112 - 200 and 206 - 250 have been reserved for RFCs to fill in holes in the guidelines and documentation.
Style Proposals
Categorized as Category:Proposed Style. Passed proposals waiting to be implemented and closed proposals are found on the talk page.
| RFC | Title & Wikipage | Champion | Affects | Status | RFCs | RFVs |
|---|---|---|---|---|---|---|
RFC-1: AudioBook Style1 |
Audiobook Style | Jormangeud | New guideline | In development | ||
RFC-8: Capitalization Standard Swedish8 |
Capitalization Standard Swedish | symphonick | New guideline | In development | ||
RFC-19: Game Soundtrack Style19 |
Game Soundtrack Style | BrianFreud | New guideline | In development | ||
RFC-20: Instrumental Style20 |
Instrumental Style | Bogdanb | ETI style for instrumental tracks | In development | ||
RFC-25: Medley Style25 |
Medley Style | Jacobbrett | New guideline | In development | ||
RFC-42: Release Artist Style42 |
Release Artist Style | navap | New guideline | In development | ||
RFC-43: Release
|
Release |
Jacobbrett | Release events | |||
RFC-53: Soundtrack Style53 |
Soundtrack Style | BrianFreud | New guideline | In development | ||
RFC-54: Soundtrack Title Style54 |
Soundtrack Title Style | BrianFreud | New guideline | In development | ||
RFC-61: Track Title Style61 |
Track Title Style | warp | Naming of track titles | In development | ||
RFC-62: Untitled Release Style62 |
Untitled Release Style | Bogdanb | New guideline | In development | ||
RFC-67: Revised Classical Style Guide (aka CSGv2)67 |
Revised Classical Style Guide (aka CSGv2) | BrianFreud | Rewrites all of CSG | RFC, On hold pending NGS release | 2009-02-15 | |
RFC-202: Part Number Style rewrite202 |
Part Number Style rewrite | BrianFreud | Part Number Style | On hold pending RFC-61 | ||
RFC-109: Release Groups109 |
Release Groups | Jacobbrett | New guideline | In development | ||
RFC-204: Decommission Don't Make Relationship Clusters204 |
Decommission Don't Make Relationship Clusters | BrianFreud | Removes a guideline | vetoed, awaiting counter-proposal | 2010-03-15 | |
RFC-275: Clarify order of precedence of guidelines and principles275 |
Clarify order of precedence of guidelines and principles | BrianFreud | Cleans up & assigns order of precedence for guidelines and principles | RFC2 | ||
RFC-288: Capitalization Standard Japanese288 |
Capitalization Standard Japanese | kepstin |
New caps standard guideline | RFC+1 | 2010-11-27 |
|
RFC-290: Live Bootleg Style:
|
Live Bootleg Style: |
BrianFreud | Add reference list for state abbreviations | RFC3 | 2010-12-05 |
|
RFC-299: Continuous Mix Style299 |
Continuous Mix Style | chancey | New style guideline | RFC | 2010-09-22 | |
RFC-307: Futuramerlin.com Album Artwork307 |
Futuramerlin.com Album Artwork | Calculator Ftvb | ? | ? | ||
RFC-320: Revised Sortname Style320 |
Revised Sortname Style | caller#6 | re-write of Sortname_Style | RFC | ||
RFC-327: Featured Artists327 |
Featured Artists | GNU_Andrew | re-write of Featured artists | RFC | ||
RFC-328: Expansion of Style/Language/Hungarian328 |
Style/Language/Hungarian | kovacsur | expansion of Style/Language/Hungarian | RFC | 2011-07-13 | |
RFC-329: Removal of CDON.COM and AMG from What not to Link to329 |
Removal of CDON.COM and AMG from What not to Link to | Jacobbrett | Style/Relationships/URLs/What not to link to | RFC | 2011-07-15 |
Advanced Relationship Proposals
Categorized as Category:Proposed Relationship Type. Passed proposals waiting to be implemented and closed proposals are found on the talk page.
| RFC | Title & Wikipage | Champion | Affects | Status | RFCs | RFVs |
|---|---|---|---|---|---|---|
RFC-4: Redesign of the Vocal Relationship Attribute4 |
Redesign of the Vocal Relationship Attribute | BrianFreud | AR modification | discussion, Pre-RFC | ||
RFC-26: Miscellaneous Production Relationship Type/Artwork26 |
Miscellaneous Production Relationship Type/Artwork | BrianFreud | In development | |||
RFC-29: Narrator Relationship Type29 |
Narrator Relationship Type | symphonick | New vocal role | In development | ||
RFC-35: Part Of Series Relationship Type35 |
Part Of Series Relationship Type | abandoned |
New release-release, or RG-RG, AR | In development | ||
RFC-39: Reader Relationship Type39 |
Reader Relationship Type | symphonick | New vocal role | In development | ||
RFC-55: Speaker Relationship Type55 |
Speaker Relationship Type | symphonick | New vocal role | In development | ||
RFC-68: Add Has News Coverage AR68 |
Add Has News Coverage AR | abandoned |
New release-URL AR | Tabled until post-NGS | ||
RFC-69: Defining instruments and vocals for members of bands69 |
Defining instruments and vocals for members of bands | BrianFreud | Artist-artist AR enhancement (#1141) | In development | ||
RFC-83: Add
|
Add |
BrianFreud | New track-URL AR (#3852) | In development | ||
RFC-84: Add 'provides discographic information about' AR84 |
Add 'provides discographic information about' AR | BrianFreud | New track-URL AR (#3734) | In development | ||
RFC-87: Add 'is a project of' AR87 |
Add 'is a project of' AR | abandoned | New artist-artist AR (#1739) | In development | ||
RFC-260: Extend License attribute260 |
Extend License attribute | Murdos | Adds new licenses to existing License Relationship Attribute | In development | ||
RFC-261: Clean up link phrases261 |
Clean up link phrases | BrianFreud | Makes AR link phrases consistent and comprehensible | RFV | 2010-03-24 | 2010-04-07 |
RFC-106: Conductor AR Changes106 |
Conductor AR Changes | BrianFreud |
Conductor and Chorus Master Relationship Types modification | discussion, RFC | 2010-12-06 |
|
RFC-106a: Deprecate Chorus Master Relationship Type106a |
Deprecate Chorus Master Relationship Type | BrianFreud | Depricates the Chorus Master Relationship Type (follow up to RFC-106) | discussion, RFC | 2010-12-31 | |
RFC-264: Choirmaster Position Relationship Type264 |
Choirmaster Position Relationship Type | BrianFreud | New artist-artist AR | discussion, RFC | 2010-12-06 | |
RFC-265: Concertmaster Position Relationship Type265 |
Concertmaster Position Relationship Type | BrianFreud | New artist-artist AR | discussion, RFC | 2010-12-21 | |
RFC-265a: Concertmaster Relationship Type265a |
Concertmaster Relationship Type | BrianFreud | New release/track-artist AR | discussion (see RFC-265) | ||
RFC-266: Conductor Position Relationship Type266 |
Conductor Position Relationship Type | BrianFreud | New artist-artist AR | discussion, RFC | 2010-12-06 | |
RFC-319: Modify Member Of Band Relationship Type319 |
Modify Member Of Band Relationship Type | BrianFreud | Add a guideline to the MoB AR | (Split out from RFC-264 and RFC-266), discussion, RFC | 2010-12-16 | |
RFC-267: Manager Position Relationship Type267 |
Manager Position Relationship Type | BrianFreud | New artist-artist AR | discussion, RFC | 2010-12-21 | |
RFC-268: Road Crew Position Relationship Type268 |
Road Crew Position Relationship Type | BrianFreud | New artist-artist AR | discussion, RFC | 2010-12-31 | |
RFC-269: Music Director Position Relationship Type269 |
Music Director Position Relationship Type | BrianFreud | New artist-artist AR | discussion, Pre-RFC | ||
RFC-270: Bandleader Position Relationship Type270 |
Bandleader Position Relationship Type | BrianFreud | New artist-artist AR | discussion, RFC | 2010-12-31 | |
RFC-271: Teacher Position Relationship Type271 |
Teacher Position Relationship Type | BrianFreud | New artist-artist AR | discussion, Pre-RFC | ||
RFC-272: Vocal Coach Position Relationship Type272 |
Vocal Coach Position Relationship Type | BrianFreud | New artist-artist AR | discussion, Pre-RFC | ||
RFC-273: Instrument Instructor Position Relationship Type273 |
Instrument Instructor Position Relationship Type | BrianFreud | New artist-artist AR | discussion, Pre-RFC | ||
RFC-274: Supporting Musician Relationship Type enhancement274 |
Supporting Musician Relationship Type enhancement | BrianFreud | Add attribute to existing artist-artist AR | discussion, RFC | 2010-12-21 | |
RFC-278: Add label-URL to Discography Relationship Type278 |
Add label-URL to Discography Relationship Type | BrianFreud | Adds AR | RFC+1 | 2010-06-03 | 2010-06-10 |
RFC-279: Add label-URL to Mail Order Relationship Type279 |
Add label-URL to Mail Order Relationship Type | BrianFreud | Adds AR | Waiting for RFC | ||
RFC-280: Add label-URL and artist-URL to Review Relationship Type280 |
Add label-URL and artist-URL to Review Relationship Type | BrianFreud | Adds 2 ARs | Waiting for RFC | ||
RFC-281: Add artist-label to Miscellaneous Role Relationship Type281 |
Add artist-label to Miscellaneous Role Relationship Type | BrianFreud | Adds AR | Waiting for RFC | ||
RFC-291: Jamendo Relationship Type291 |
Jamendo Relationship Type | navap | New URL AR | In development | ||
RFC-297: Toured With Relationship Type297 |
Toured With Relationship Type | BrianFreud | New AR | In development | ||
RFC-298: Bandcamp Relationship Type298 |
VxJasonxV | New |
In development, RFC1 withdrawn | |||
RFC-309: Married Relationship Type enhancement309 |
Married Relationship Type | BrianFreud | New attributes | In discussion | ||
RFC-310: Emeritus Position Relationship Attribute310 |
Emeritus Position Relationship Attribute | BrianFreud | relationship attribute | In discussion | ||
RFC-310: Principal Position Relationship Attribute311 |
Principal Position Relationship Attribute | BrianFreud | relationship attribute | In discussion | ||
RFC-312: Executive Committee Position Relationship Type312 |
Executive Committee Position Relationship Type | BrianFreud | New AR | In discussion | ||
RFC-313: Principal Position Relationship Type313 |
Principal Position Relationship Type | BrianFreud/Symphonick | New AR | In discussion | ||
RFC-314: Soloist Relationship Type314 |
Soloist Relationship Type | Symphonick | New AR | In discussion | ||
RFC-315: Contractor Position Relationship Type315 |
Contractor Position Relationship Type and Position Relationship Attribute | BrianFreud | New AR | RFC | 2010-01-02 | |
RFC-322: Performed Relationship Type Attributes322 |
Performed Relationship Type Attributes | Cjk32 | New Attributes | RFC | 2011-06-06 | |
RFC-323: Live Attribute for Performed Relationship Type323 |
Performed_Relationship_Type_Live_Attribute | Bitmap | Relationship attribute | RFV | 2011-06-08 | 2011-06-15 |
RFC-324: Official Website and Discography Entry ARs for Releases/Release Groups324 |
Official Homepage Relationship Type Discography Entry Relationship Type | Kepstin | Official Homepage | RFC | ||
RFC-325: Cover Relationship Type325 |
Cover Relationship Type | Bitmap | Rewrites AR | RFV | 2011-06-18 | 2011-06-26 |
Other Proposals
Categorized as Category:Proposal. Passed proposals waiting to be implemented and closed proposals are found on the talk page.
| RFC | Title & Wikipage | Champion | Affects | Status | RFCs | RFVs |
|---|---|---|---|---|---|---|
RFC-3: Advanced Entity3 |
Advanced Entity (Post-NGS) | BrianFreud | Catchall for various post-NGS entity suggestions | post-NGS | ||
RFC-6: Artist Type Project6 |
Artist Type Project | abandoned | New Artist type | abandoned | ||
RFC-11: Change Default Data Quality Proposal11 |
Change Default Data Quality Proposal (Data) | BrianFreud | Voting, Quality, and Edit expiration | discussion, post-NGS | ||
RFC-24: Location Proposal24 |
Location Proposal | BrianFreud | New entity | discussion, post-NGS | ||
RFC-36: Performance Restructuring Proposal36 |
Performance Restructuring Proposal | BrianFreud | In development | |||
RFC-37: Performances And Recordings Proposal37 |
Performances And Recordings Proposal | BrianFreud | New entity | discussion, post-NGS | ||
RFC-49: Release Type Restructuring Proposal49 |
Release Type Restructuring Proposal | BrianFreud | In development | |||
RFC-49a: Release Status Proposals277 |
Various Release Status Proposals | BrianFreud | This is a catchall for Release Status proposals formerly part of RFC-49 | In development | ||
RFC-49b: Release Format Proposal278 |
Release Format Proposal | BrianFreud | This is the Release Format proposal, formerly part of RFC-49 | In development | ||
RFC-258: How to Identify Release Details258 |
How to Identify Release Details | Jacobbrett | Will replace How To Identify Labels | In development | ||
RFC-296a: Change "Release Country"296a |
Change "Release Country" | BrianFreud | RFC+1 | 2010-12-28 | ||
RFC-300: Add new release type: Production Music300 |
Add new release type: Production Music | BrianFreud | discussion, pre-RFC | |||
RFC-301: Add new release type: Studio/Demo301 |
Add new release type: Studio/Demo | BrianFreud | discussion, pre-RFC | |||
RFC-302: Add new release type: Audio Drama302 |
Add new release type: Audio Drama | BrianFreud | discussion, pre-RFC | |||
RFC-303: Add new release type: Multi-Album303 |
Add new release type: Multi-Album | BrianFreud | discussion, pre-RFC | |||
RFC-304: Add new release type: Live Compilation304 |
Add new release type: Live Compilation | BrianFreud | discussion, pre-RFC | |||
RFC-305: Add new release type: Soundtrack Single305 |
Add new release type: Soundtrack Single | BrianFreud | discussion, pre-RFC | |||
RFC-306: Add new release type: Soundtrack Compilation306 |
Add new release type: Soundtrack Compilation | BrianFreud | discussion, pre-RFC | |||
RFC-326: Add new artist type: Other326 |
Artist Type Other | hrglgrmpf | New Artist type | RFC | 2011-07-18 |
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
- Old concepts for new entities (possibly of use for proposals/development, post-NGS)
- Some other old concepts for new entities These originally were potential uses for Advanced Relationships, but most would not work with relationships as they have since been implemented. However, they may be useful post-NGS for further consideration.
- Any of Category talk:External Website Relationship Class
