Style Council: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(CAT:Style_Council = 2x redirect. Otoh: Cat:STYLE points to ARTICLE:Style_Council since 2009 correctly. Hence, obsolete reference removed.)
Line 59: Line 59:
<references/>
<references/>


[[Category:Style]] [[Category:Style Council]]
[[Category:Style]]

Revision as of 14:38, 10 February 2011

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 Style Mailing List 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
Nikki 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

Note: This process has been updated, based on the StyleCouncil/August2008ProcessReview, to address some problems in the previous process.

  1. Present your issue and the changes you propose to the Style Mailing List 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 consensus.
  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' mailing list (most didn't see the style discussion) and to Recent Style Changes.

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 no-one 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 Style mailing list. That community has no formal organization. We can still call it the StyleCouncil, though.
  • If you want a Style Issue 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 Style Issue 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 Style Mailing List, 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 Beta Editing on the Users Mailing List. 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 Style Mailing List. 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 dissension 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 Request For Comment first, wait for a week or two, and then issue a Request For Veto. 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.