Style Council

The MusicBrainz Style Council

The Style Council is the institution in MusicBrainz that creates and edits the OfficialStyleGuidelines. The Style Council is currently being restructured, since it did not work very well.

How the Style Council Works

Members

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.

The Style Council has two formal members:

An Elder

RobertKaye is the Elder and benevolent dictator of MusicBrainz StyleIssues. If the council cannot reach consensus he will make a decision.

A Secretary

The Secretry is the Elder's right hand. He does the non-controversial daily work, but cannot make actual rulings. This is a rotating position currenly filled by DonRedman until April 2006

Current Practice

1. Decisions about style issues are made by the community on mb-style. That community has no formal organization. We can still call it the Style Council, though.
2. If you do not want a StyleIssue to be forgotten, enter it as a "Style Issue" ticket in trac.
3. If you want a StyleIssue to be fixed, do the work yourself.
4. You need a formal approval from the secretary before you change anything official.
5. If you are unhappy with a decision of the Secretary, publicly call upon the Elder. Similarily, if no consensus can be reached, the Secretary calls upon the Elder

How to Get an approval for a Change

If you want an approval from the Secretary do this:

• Make sure there is an Active Ticket for the Style Issue in the BugTracker.
• Let the Style Council reach consensus.
• Make sure the requirements on the ChecklistForStyleChanges are met.
• Send a mail to the StyleMailingList that summarizes the points abvoe and asks for an OK by the Secretray.

• This will soon be changed to:
  • * Create a "request for approval" ticket in the BugTracker.
  • * Refer to the bug or improvement that you want to fix and
  • * link to a page or mail that exactly describes the fix and goes through the checklist.
  • * Assign the ticket to you and accept it.
  The secretary will wait 24 hours for a veto. If nothing happens he will close the ticket as "fixed". That means you have the approval. If he closes it as "wontfix", your request has been rejected.

The Secretary should give you an OK and maybe a date to apply the change. If no consensus could be reached or somebody objects, the Elder has to jump in and make a decision.

How to Make a Change

If you want to make a change, keep in mind that this means you will have to do all this:

• Make the change (e.g. to the AdvancedRelatinshipType tree) yourself, or collaborate jointly with the developers.
• Document the changes on the wiki.
• Blog about the change and/or notify people on the UsersMailingList

There is an old page that describes HowToProposeNewGuidelines, but this needs to be updated.

---

---

Old Stuff

• Status: The style council is currently under development. Follow discussions on the StyleMailingList to check whether the information here is still correct.

How the New Style Council Will Work

This has not been fixed yet, but there seems to be general consensus about more or less these points:

1. The Style Council will have a leader. This leader will act as a benevolent dictator and make decisions, but should not do any of the actual work involved with the issues discussed.
2. The Council will consist of members, who agree to become delegates for a specific StyleIssue. Once a person has become a delegate, she/he is responsible for the progress of this issue according to the process described in HowToSolveAStyleIssue. That means that a delegate is responsible to do the actual work, if nobody else does it. Delegates should be assigned to StyleIssues in a rotating fashion to avoid burnout.
3. All subscribers to the StyleMailingList form an interested public and take part in discussions about StyleGuidelines.
4. Each StyleIssue has a person who raised it. This proposer also has some responsibilities; see below.

The roles of these three people are distributed like this:

The Proposer's Job is to

• Open the issue in the IssueTracker and start a thread about it on the StyleMailingList.
• If the proposal is a complex one, CreateAWikiPage describing the initial issue.
• Collaborate with the delegate on summaries etc.
• In some tough cases it might be necessary or at least helpful to summarize the finally proposed change and make sure it addresses all objections raised on the StyleMailingList.

The Leader's Job is to

• Make sure that an issue is assigned to a delegate who then has the resposibility to do the work involved with it. The leader her/himself should never do the actual work, to prevent burnout as we experienced it with the StyleDudes.
• Check that all important aspects of the issue have been touched
  • impact on existing data, including edge cases and Various Artists albums (an often forgotten problem area).
  • conflicts with other style rules.
  • editor time required to implement the change.
  • developer time required to implement the change (if any), keeping in mind that developer time is limited and we wish to avoid wasting their time if at all possible.
  • impact on paying clients.
  • can the change be automated?

• Make a decision. This can be just a statement, that apperently concensus has been reached or that the outcome of a vote is positive/negtive. It can be a final and dicatorial decision.

The Delegate's Job is to

• Acompany any documentation in the wiki in a way that makes sure that a neutral description of the issue is available during discussion. This means that they must be prepared to write such a summary, should no one else do that.
• Write up a final version of the proposed change on the wiki.
• When a decision has been reached, blog about the proposed change (ot should this be done by the leader?)
• Finally, make sure the change is implemented. Agian this means to be prepared to edit the wiki or the AR definition or to collaborate with developers.

---

Old Style Council

• The following section describes the members and their roles in the old Style Council. This is going to be superceded by the reform described above.

Members of the Style Council

(a.k.a. StyleModerators)

Secretaries (Ministers of Style)

• JohnCarter
• RjMunro
• Dupuy

Editors

• ClutchEr2
• DJKC
• Gecks
• G0llum
• Mcymd
• MichelleW
• Nikki
• Steinbdj
• WolfSong

editor-without-portfolio (ombudsman)

• DonRedman

Emeriti

• TarragonAllen
• NeilCafferkey

Areas of specialization

1. MetaData -- Dupuy
   1. AdvancedRelationshipTypes (basic advanced relationships) -- WolfSong / Gecks
   2. AdvancedRelationshipAttributes (instruments, etc.) -- Mcymd
   3. AdvancedRelationshipUsage (what to represent with advanced relationships, what to omit) -- JohnCarter
   4. OtherMetaData (ExtraTitleInformation, artist comments, annotations) -- RjMunro

1. DataPresentation -- RjMunro
   1. FormattingStyle (CapitalizationStandard, punctuation, etc.) -- G0llum
   2. InterNationalization (language stuff) -- Nikki / Dupuy
   3. NonMusicalStyle (data cds tracks, silence, etc.)
   4. SpecialCaseStyle (VariousArtists albums, SpecialPurposeArtists) -- MichelleW

1. GenreStyle -- JohnCarter
   1. ClassicalStyle (orchestral & classical music) -- ClutchEr2 / WolfSong
   2. SoundtrackStyle (musicals, anime, & movie soundtracks) -- Steinbdj
   3. ElectronicStyle (electronica, DJ & fan remixes, mash-ups, etc.) -- Gecks
   4. AsianStyle (J-pop, K-pop, C-pop, etc.) -- DJKC