Style Council: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
No edit summary
Line 29: Line 29:
===Vetos===
===Vetos===


When an RFV has been posted anyone can cast a veto. However, a veto is not valid without a good argument as to why a proposal should not be accepted.
Please try to not cast "preemptive vetos" during the RFC stage, such as "If this goes to RFV, I will veto." Instead, try to work with the proposer to find a compromise on which you both can agree.


If somebody has cast a veto, the issue gets presented to the elder, who will have to make a decision.
RFVs should not be vetoed simply because you do not like a change. Before casting a veto, please attempt to describe your concerns about the proposal, preferably during the RFC phase. A veto is not valid without a good argument as to why a proposal should not be accepted.


===Shortcut (aka "Fast Tracking" a change)===
===Shortcut (aka "Fast Tracking" a change)===

Revision as of 22:20, 10 June 2009

The MusicBrainz Style Council

The style council is the institution in MusicBrainz that creates and edits the OfficialStyleGuidelines. The style council was reformed many times, as it did not work well initially. See the HistoryOfTheStyleCouncil for details. The council has reached a relatively balanced state now.

Membership

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.

There are however two formal positions of "supervisors" of the general style process:

Elder
RobertKaye is the elder and benevolent dictator of MusicBrainz StyleIssues. If the process goes off the rails, or if someone disputes the style leader's decisions, the elder steps in.
Style Leader
BrianFreud and warp are the current style leaders. 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".

How the Style Council Works

N.B. This process is under review as of August 2008. See StyleCouncil/August2008ProcessReview . —JimDeLaHunt, StyleCouncil leader, 2008-08-06

  1. Present your issue and the changes you propose to the StyleMailingList in a new thread. Please start the subject line with "RFC:" so that the mailing list can easily see that a change is being suggested.
  2. Add a new ticket to the Bug Tracker (normally to component: Style Issues) for tracking this RFC. Please include a link to the RFC email to make tracking the RFC simpler. You should be the owner of this ticket ("Assign to:").
  3. Let discussion take place, and see if consensus emerges, or adopt into the proposal those changes that make sense to you, to work towards concensus.
  4. Once the discussion has ebbed out, or stopped from being productive, reformulate your changes and request a veto. The veto should include a short note pointing to the past discussion and a relatively specific description of your proposal. Please start the subject line with "RFV:". Then update the Bug Tracker ticket for this issue with a link to this RFV post.
  5. If no veto was cast within 48 hours, go ahead and make your changes. Please also send an email to the list making the RFC official, and update the bug ticket to indicate that this RFC has now passed.
  6. Post a brief summary of the changes to the users' mailinglist (most didn't see the style discussion) and to RecentStyleChanges.

Vetos

When an RFV has been posted anyone can cast a veto. However, a veto is not valid without a good argument as to why a proposal should not be accepted.

If somebody has cast a veto, the issue gets presented to the elder, who will have to make a decision.

Shortcut (aka "Fast Tracking" a change)

The following "shortcut" is still experimental. Do not use this if you are new to the council:

If you propose a very minor change, you can skip steps 1, 2, and 4 and request a veto right away. (However, still follow #2 and create the bug tracker ticket.) In this case you must include a short note saying that you skipped the request for comments. This means that anybody may veto if they think a detailed discussion is necessary (i.e. the change is more than very minor to them). In this case your proposal is thrown back to stage 2. If noone vetoed, you must wait for 48 hours of silence after the discussion has ebbed out before doing any changes. Finally, if there was a substantial discussion, then this is a clear sign that an initial request for comments would have been appropriate.

Some more detailed thoughts

Attention.png Status: The following still has to be updated. It offers some details which are valuable. But if you are in doubt, follow the descriptions above

  • Decisions about style issues are made by the community on mb-style mailinglist. That community has no formal organization. We can still call it the StyleCouncil, though.
  • If you want a StyleIssue to be fixed, do the work yourself.

Now at this point things get tricky. There is no working practice yet, so you'll have to experiment a bit. DonRedman described how it could work in this thread:

  • Someone wants a StyleIssue fixed. She is prepared to put in some work to get things right. So she implements a solution on test or the wiki, proposes it to the StyleMailingList, and requests _comments_. Ideally people join into a productive debate about how to enhance the change. People might also bring forth arguments against this change. The proposer can change her proposal to meet these arguments as much as _she_ wants. In a final stage she might want to call for BetaEditing on the UsersMailingList. This only applies to big or highly disputed changes. Here the practice of using (testing) the solution should show whether it is good. When she thinks she has done enough, she sends a 'request for veto' to the StyleMailingList. A veto must match the amount of productive work she has put into the change. Therefore a veto is only likely to occur if someone sees a severe problem, or if the proposer has worked on her proposal only sluggishly. If there really is dispute, the point of dissensus should be really clear by now. It will probably be a general/philosophical point. Robert should be able to make a well informed decision that everyone will have to accept.

By now it has become clear that it makes sense to issue a RequestForComment first, wait for a week or two, and then issue a RequestForVeto. You should also wait 48 hours for a veto.

History

The style council had a lot of other protocols and processes that preceded this one. They did not work that well, but since they offer some helpful insight about how things do not work in the MusicBrainz community, they are kept in the HistoryOfTheStyleCouncil.