History:Style Council/History: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
((Imported from MoinMoin))
(typos + broken links (Imported from MoinMoin))
Line 2: Line 2:


'''or'''
'''or'''
=How the Style Coucil did not work=
=How the Style Council did not work=


The [[Style Council|StyleCouncil]] has a long history of reforms which have led to the current practice, which is documented on the [[Style Council|StyleCouncil]] page. This history is kept here, because it offers some lessons about how things do not work in the [[MusicBrainz]] community.
The [[Style Council|StyleCouncil]] has a long history of reforms which have led to the current practice, which is documented on the [[Style Council|StyleCouncil]] page. This history is kept here, because it offers some lessons about how things do not work in the [[MusicBrainz]] community.
Line 65: Line 65:
## [[Internationalization|InterNationalization]] (language stuff) -- [[User:Nikki|Nikki]] / [[User:Dupuy|Dupuy]]
## [[Internationalization|InterNationalization]] (language stuff) -- [[User:Nikki|Nikki]] / [[User:Dupuy|Dupuy]]
## [[Non Musical Style|NonMusicalStyle]] (data cds tracks, silence, etc.)
## [[Non Musical Style|NonMusicalStyle]] (data cds tracks, silence, etc.)
## [[Special Case Style|SpecialCaseStyle]] ([[Various Artist|VariousArtist]]<code><nowiki></nowiki></code>s albums, [[Special Purpose Artist|SpecialPurposeArtist]]<code><nowiki></nowiki></code>s) -- MichelleW
## [[Special Case Style|SpecialCaseStyle]] ([[Various Artists|VariousArtists]] releases, [[Special Purpose Artist|SpecialPurposeArtist]]<code><nowiki></nowiki></code>s) -- MichelleW


# [[Genre Style|GenreStyle]] -- [[User:JohnCarter|JohnCarter]]
# [[Genre Style|GenreStyle]] -- [[User:JohnCarter|JohnCarter]]
## [[Classical Style|ClassicalStyle]] (orchestral & classical music) -- [[User:ClutchEr2|ClutchEr2]] / [[User:WolfSong|WolfSong]]
## [[Classical Style Guide|ClassicalStyleGuide]] (orchestral & classical music) -- [[User:ClutchEr2|ClutchEr2]] / [[User:WolfSong|WolfSong]]
## [[Soundtrack Style|SoundtrackStyle]] (musicals, anime, & movie soundtracks) -- [[User:Steinbdj|Steinbdj]]
## [[Soundtrack Style|SoundtrackStyle]] (musicals, anime, & movie soundtracks) -- [[User:Steinbdj|Steinbdj]]
## [[Electronic Style|ElectronicStyle]] (electronica, DJ & fan remixes, mash-ups, etc.) -- [[User:Gecks|Gecks]]
## [[Electronic Style|ElectronicStyle]] (electronica, DJ & fan remixes, mash-ups, etc.) -- [[User:Gecks|Gecks]]
Line 91: Line 91:
====The Proposer's Job is to====
====The Proposer's Job is to====


* Open the issue in the [[Issue Tracker|IssueTracker]] and start a thread about it on the [[Style Mailing List|StyleMailingList]].
* Open the issue in the [[Bug Tracker|BugTracker]] and start a thread about it on the [[Style Mailing List|StyleMailingList]].
* If the proposal is a complex one, [[Create A Wiki Page|CreateAWikiPage]] describing the initial issue.
* If the proposal is a complex one, create a [[Wiki Page|WikiPage]] describing the initial issue.
* Collaborate with the delegate on summaries etc.
* 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 [[Style Mailing List|StyleMailingList]].
* 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 [[Style Mailing List|StyleMailingList]].
Line 98: Line 98:
====The Leader's Job is to====
====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 [[Style Dude|StyleDude]]<code><nowiki></nowiki></code>s.
* Make sure that an issue is assigned to a delegate who then has the responsibility 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 [[Style Dude|StyleDude]]<code><nowiki></nowiki></code>s.
* Check that all important aspects of the issue have been touched
* 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).
** impact on existing data, including edge cases and Various Artists albums (an often forgotten problem area).
Line 107: Line 107:
** can the change be automated?
** 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.
* Make a decision. This can be just a statement, that apparently consensus has been reached or that the outcome of a vote is positive/negative. It can be a final and dictatorial decision.


====The Delegate's Job is to====
====The Delegate's Job is to====
Line 122: Line 122:
==Approval Mechanism==
==Approval Mechanism==


When it became clear, that nobody was willing to do all this work if they had not "an itch" that scrathced them, the job of fixing a [[Style Issue|StyleIssue]] was laid upon th eperson requesting the fix. As a means of quality assurance a [[Style Secretary|StyleSecretary]] was appointed. His job was to require certain formalisms that should prevent bad changes to the [[Style Guideline|StyleGuideline]]<code><nowiki></nowiki></code>s to come through.
When it became clear, that nobody was willing to do all this work if they had not "an itch" that scratched them, the job of fixing a [[Style Issue|StyleIssue]] was laid upon the person requesting the fix. As a means of quality assurance a [[Style Secretary|StyleSecretary]] was appointed. His job was to require certain formalisms that should prevent bad changes to the [[Style Guideline|StyleGuideline]]<code><nowiki></nowiki></code>s to come through.


This system did not work well at all. Everything was pushed to the secretary and he became the bottleneck of the whole process:
This system did not work well at all. Everything was pushed to the secretary and he became the bottleneck of the whole process:
# You need a formal approval from the secretary before you change anything official.
# You need a formal approval from the secretary before you change anything official.
# 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
# If you are unhappy with a decision of the Secretary, publicly call upon the Elder. Similarly, if no consensus can be reached, the Secretary calls upon the Elder
# If you want an approval from the Secretary do this:
# If you want an approval from the Secretary do this:
#* Make sure there is an [http://bugs.musicbrainz.org/report/8 Active Ticket for the Style Issue] in the [[Bug Tracker|BugTracker]].
#* Make sure there is an [http://bugs.musicbrainz.org/report/8 Active Ticket for the Style Issue] in the [[Bug Tracker|BugTracker]].
#* Let the Style Council reach consensus.
#* Let the Style Council reach consensus.
#* Make sure the requirements on the [[Checklist For Style Changes|ChecklistForStyleChanges]] are met.
#* Make sure the requirements on the [[Checklist For Style Changes|ChecklistForStyleChanges]] are met.
#* Send a mail to the [[Style Mailing List|StyleMailingList]] that summarizes the points abvoe and asks for an OK by the Secretray.
#* Send a mail to the [[Style Mailing List|StyleMailingList]] that summarizes the points above and asks for an OK by the Secretary.
<ul><li style="list-style-type:none">This could even be more complicated:
<ul><li style="list-style-type:none">This could even be more complicated:
#* * Create a "request for approval" ticket in the [[Bug Tracker|BugTracker]].
#* * Create a "request for approval" ticket in the [[Bug Tracker|BugTracker]].

Revision as of 16:31, 25 April 2007

History of the Style Coucil

or

How the Style Council did not work

The StyleCouncil has a long history of reforms which have led to the current practice, which is documented on the StyleCouncil page. This history is kept here, because it offers some lessons about how things do not work in the MusicBrainz community.




The Style Dudes

At the Beginning we had a single StyleDude. This worked very well. The first StyleDude was NeilChafferkey, the second was TarragonAllen. After a long period (when exaclty) Tarragon resigned, because he felt that the job was too big for one person. This led to the creaton of the first StyleCouncil.



First Formalized Style Council

The following section describes the members and their roles in the first Style Council. This has not worked well, mostly because the distribution of roles was not really applicable in practice (is this correct?):

Members of the Style Council

(a.k.a. StyleModerators)

Secretaries (Ministers of Style)

Editors

editor-without-portfolio (ombudsman)

Emeriti

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.) -- Keschte
    2. InterNationalization (language stuff) -- Nikki / Dupuy
    3. NonMusicalStyle (data cds tracks, silence, etc.)
    4. SpecialCaseStyle (VariousArtists releases, SpecialPurposeArtists) -- MichelleW
  1. GenreStyle -- JohnCarter
    1. ClassicalStyleGuide (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


Delegate System

Then (when?) the strict distribution of roles was abolished in favor of a system in which people would become delegates for a specific StyleIssue on a case by case basis. This did not work well, mostly because the delegates were not really motivated to work hard on issues that someone else had reported.

The Delegate system was never really fixes. But there was 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 BugTracker and start a thread about it on the StyleMailingList.
  • If the proposal is a complex one, create a WikiPage 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 responsibility 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 apparently consensus has been reached or that the outcome of a vote is positive/negative. It can be a final and dictatorial 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.


Approval Mechanism

When it became clear, that nobody was willing to do all this work if they had not "an itch" that scratched them, the job of fixing a StyleIssue was laid upon the person requesting the fix. As a means of quality assurance a StyleSecretary was appointed. His job was to require certain formalisms that should prevent bad changes to the StyleGuidelines to come through.

This system did not work well at all. Everything was pushed to the secretary and he became the bottleneck of the whole process:

  1. You need a formal approval from the secretary before you change anything official.
  2. If you are unhappy with a decision of the Secretary, publicly call upon the Elder. Similarly, if no consensus can be reached, the Secretary calls upon the Elder
  3. If you want an approval from the Secretary do this:
  • This could even be more complicated:
      • * 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 ChecklistForStyleChanges.
      • * 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 AdvancedRelationshipType 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.



Conclusions

These experiences have led to some important lessons.

  • First, the current process of the StyleCouncil (documented on that page), which has its quirks, is relatively slow but works astonishingly well.
  • Second, a very fundamental rule for "organizational development" in the MusicBrainz community:
  • Rules follow practice

This means, that we establish a practice by improvising and discussing it first and then, when it seems to work, we write up the rules, not the other way around.