Proposals: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
No edit summary
(Copy editing)
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Making changes to the [[Style|style guidelines]], adding new types of [[Advanced Relationship|relationship]]s, and other similar changes need to be accepted by the community. For that, the proper proposal process must be followed.
Modifications to the [[Style|style guidelines]], adding types of [[Advanced Relationship|relationship]]s, and other similar changes happen through the following user-initiated process.


== Definitions ==
==Request==
;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 [[User:Nikki|Nikki]] and [[User:Reosarevok|reosarevok]].
;Style Elder
: The benevolent dictator of [[MusicBrainz]] [[Style Issue|style issues]]. If the process goes off the rails, or if someone disputes the style leaders' decisions, the elder steps in. Currently [[User:RobertKaye|RobertKaye a.k.a. ruaok]]


If you would like to make a change, improvement or addition, it should be
== The Standard Process ==
requested by opening a ticket in [http://tickets.musicbrainz.org/browse/STYLE our bug tracker]. If any relevant previous discussion has happened (on the mailing lists, forums, IRC or even edit notes), be sure to link to that discussion from the ticket.
=== 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 [[Mailing List|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.


Make sure that the ticket is pretty clear on what exactly is being requested. While it’s not necessary for the requester to write the final documentation, it’s perfectly acceptable to submit a draft that makes the request more clear. If your proposed change is a non-trivial change, please include as much detail as possible in your ticket.
Create a ticket for the proposal in [[Bug Tracker|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.


==Decision==
If the proposal will require creating or modifying a wiki page, create a new wiki page for it. This should be located at <nowiki>http://wiki.musicbrainz.org/User:(username)/(proposal name)</nowiki>. Use [[Template:proposal|the proposal template]] on the page; documentation is at the template page. If you're creating a page for a relationship, you should use [[Template:Relationship|the relationship template]] too.
The Style Leader/BDFL ([[User:Reosarevok|reosarevok]]) will review the request and decide how to proceed. Trivial and/or obviously useful additions are very likely to be accepted immediately. In the cases where the Style Leader feels more community input is needed, they’ll request it, by calling for an informational vote and/or initiating further discussion. Please note that any vote called by the Style Leader will not be binding; the BDFL will not be required to act in accordance with the vote outcome.


Once enough input has been achieved for the Style Leader to make an informed decision, they will document the decision on the relevant ticket and then update the needed documentation/links.
=== RFC ===
Send an RFC announcement to the [http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style 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:
::# The expected expiration date for the RFC.
::# A brief summary of the proposal.
::# A link to the proposal's page in jira and, if applicable, in the wiki.
::# 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.


Unreasonable requests, or requests that, while useful, would require unreasonable amounts of developer time that just won’t be available to MusicBrainz anytime soon, will be rejected.
=== 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:
::# 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 first RFC mail.
::# 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.


==Update==
==Special Procedures==
Updates to style issues will be posted regularly (every two weeks, as long as something has changed at all) on the [http://blog.musicbrainz.org/ MusicBrainz blog]. The changes themselves might be implemented earlier than that, although major changes will generally happen in the same schedule as new code releases.

===Has Cover Art At, Has Lyrics At, and Has Score At Relationship Types===
These relationships only allow links to whitelisted sites. To add any site to the whitelist for any one of these [[Advanced Relationship|relationships]], the following additional procedure '''must''' be followed.

# Add the site to the 'in-progress' list on the relevant page for the relationship: [[Style/Relationships/URLs/Cover_art_whitelist|Cover art]], [[Style/Relationships/URLs/Lyrics_whitelist|Lyrics]] or [[Style/Relationships/URLs/Score_whitelist|Score]]
# 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.
# 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/cover art) 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.
# 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 [[Advanced Relationship Type|relationship type(s)]].

===Adding new instrument types===
These do not go through the normal style process. Instead, they use [[Instrument_Tree/Requests|the instrument addition process]].

[[Category:WikiDocs Page]]

Revision as of 07:59, 20 October 2014

Modifications to the style guidelines, adding types of relationships, and other similar changes happen through the following user-initiated process.

Request

If you would like to make a change, improvement or addition, it should be requested by opening a ticket in our bug tracker. If any relevant previous discussion has happened (on the mailing lists, forums, IRC or even edit notes), be sure to link to that discussion from the ticket.

Make sure that the ticket is pretty clear on what exactly is being requested. While it’s not necessary for the requester to write the final documentation, it’s perfectly acceptable to submit a draft that makes the request more clear. If your proposed change is a non-trivial change, please include as much detail as possible in your ticket.

Decision

The Style Leader/BDFL (reosarevok) will review the request and decide how to proceed. Trivial and/or obviously useful additions are very likely to be accepted immediately. In the cases where the Style Leader feels more community input is needed, they’ll request it, by calling for an informational vote and/or initiating further discussion. Please note that any vote called by the Style Leader will not be binding; the BDFL will not be required to act in accordance with the vote outcome.

Once enough input has been achieved for the Style Leader to make an informed decision, they will document the decision on the relevant ticket and then update the needed documentation/links.

Unreasonable requests, or requests that, while useful, would require unreasonable amounts of developer time that just won’t be available to MusicBrainz anytime soon, will be rejected.

Update

Updates to style issues will be posted regularly (every two weeks, as long as something has changed at all) on the MusicBrainz blog. The changes themselves might be implemented earlier than that, although major changes will generally happen in the same schedule as new code releases.