Proposals: Difference between revisions
From MusicBrainz Wiki
Jump to navigationJump to search
m (→Process for Idea Champions: Fix template display for clean copy/paste; thanks http://it-max.pl/wiki/index.php?title=Indenting_block_tags_like_pre_in_MediaWiki) |
mNo edit summary |
||
| (681 intermediate revisions by 50 users not shown) | |||
| Line 1: | Line 1: | ||
Modifications to the [[Style|style guidelines]], adding types of [[Advanced Relationship|relationship]]s, and other similar changes happen through the following user-initiated process. |
|||
== Process for Idea Champions == |
|||
# Come up with an idea for something new or something that should be changed. |
|||
# Create a new wikipage for the proposal. This should be located at <nowiki>http://wiki.musicbrainz.org/User:(you)/(proposal name)</nowiki> and assigned the most relevant of <nowiki>[[Category:Proposal]] [[Category:Proposed Style]] or [[Category:Proposed Advanced Relationship Type]]</nowiki>. |
|||
#* The proposal template should be at the top of the page: |
|||
<dl><dd><dl><dd><dl><dd><pre> |
|||
{{Template:proposal |
|||
|proposal= |
|||
|discussion= |
|||
|champion= |
|||
|rfc= |
|||
|rfv= |
|||
|status= |
|||
|ar= |
|||
|style= |
|||
|trac= |
|||
}}</pre></dl></dl></dl> |
|||
#: '''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 [http://bugs.musicbrainz.org trac] ticket number for your proposal. |
|||
# Send an RFC announcement to the [http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style 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! |
|||
==Request== |
|||
=== Time Periods === |
|||
* '''RFC''': 7 days |
|||
* '''RFV''': 2 days |
|||
If you would like to make a change, improvement or addition, it should be |
|||
=== Style Leaders === |
|||
requested by opening a ticket in [[jira: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. |
|||
* [[User:BrianFreud|BrianFreud]] |
|||
* warp, aka [[User:kuno|kuno]] |
|||
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. |
|||
=== Style Elder === |
|||
* ruaok, aka [[User:RobertKaye|RobertKaye]] |
|||
== |
==Decision== |
||
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 (Request for Change) |
|||
: The initial discussion period for any proposal |
|||
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 (Request for Veto) |
|||
: The decision period for any proposal |
|||
==Update== |
|||
;Style Leader |
|||
Updates to style issues will be posted regularly (every two weeks, as long as something has changed at all) on the [https://blog.metabrainz.org/ MetaBrainz blog]. The changes themselves might be implemented earlier than that, although major changes will generally happen in the same schedule as new code releases. |
|||
: 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 Issue|StyleIssue]]<code><nowiki></nowiki></code>s. If the process goes off the rails, or if someone disputes the style leaders' decisions, the elder steps in. |
|||
Latest revision as of 20:17, 28 April 2020
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 MetaBrainz blog. The changes themselves might be implemented earlier than that, although major changes will generally happen in the same schedule as new code releases.
