Style Council: Difference between revisions
From MusicBrainz Wiki
Jump to navigationJump to search
(update (Imported from MoinMoin)) |
(Adde description from Mailinglist, and moved history out (Imported from MoinMoin)) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
The '''Style Council''' is the institution in [[MusicBrainz]] that creates and edits the [[Official Style Guideline|OfficialStyleGuideline]]<code><nowiki></nowiki></code>s. The Style Council is currently being restructured, since it did not work very well. |
The '''Style Council''' is the institution in [[MusicBrainz]] that creates and edits the [[Official Style Guideline|OfficialStyleGuideline]]<code><nowiki></nowiki></code>s. The Style Council is currently being restructured, since it did not work very well. |
||
==Membership== |
|||
==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 [[Style Guideline|StyleGuideline]]<code><nowiki></nowiki></code>s, [[MusicBrainz Development|MusicBrainzDevelopment]], and the general culture of the project, you are welcome to subscribe to the [[Style Mailing List|StyleMailingList]] and join the discussions. |
There is no formal membership to the Style Council. If you are an interested contributor to [[MusicBrainz]] and reasonably well informed about existing [[Style Guideline|StyleGuideline]]<code><nowiki></nowiki></code>s, [[MusicBrainz Development|MusicBrainzDevelopment]], and the general culture of the project, you are welcome to subscribe to the [[Style Mailing List|StyleMailingList]] and join the discussions. |
||
| Line 16: | Line 14: | ||
<dd> |
<dd> |
||
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 [[User:DonRedman|DonRedman]] |
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 [[User:DonRedman|DonRedman]]. Who wanted to step off in April 2006 but is still secretary. |
||
</dl> |
</dl> |
||
==How the Style Council Works== |
|||
===Current Practice=== |
|||
# Present your issue and the changes you propose to the [[Style Mailing List|StyleMailingList]] in a new thread. |
|||
# Decisions about style issues are made by the community on mb-style. That community has no formal organization. We can still call it the StyleCouncil, though. |
|||
# Let there be a discussion, see if consensus emerges, or pick up those changes that make sense to you. |
|||
# If you do not want a style issue to be forgotten, enter a [http://test.musicbrainz.org/trac/report/8 Ticket for the Style Issue] in the [[Bug Tracker|BugTracker]]. |
|||
# Once the discussion has ebed 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''. |
|||
# If you want a [[Style Issue|StyleIssue]] to be fixed, do the work yourself. |
|||
# If no veto was cast within 48 hours, go ahead and make your changes. |
|||
If somebody has cast a veto, the issue gets presented to the elder, who will have to make a decision. The question, when it is sensible to cast a veto and when not is a difficult one. If you are new to the council, you should take part in the normal discusions for a month or two. Then you should get a feel for when a veto is sensible. |
|||
Now at this point things get tricky. There is no working practice yet, so you'll have to experiment a bit. [[User:DonRedman|DonRedman]] described ''how it could work'' in [http://www.nabble.com/-mb-style-State-of-the-Style-Secretary-t1068709c2885.html#a2813225 this thread]: |
|||
<ul><li style="list-style-type:none">Someone wants a [[Style Issue|StyleIssue]] fixed. She<ref>Today our example person is female. That is balancing sexism :-) .</ref> 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|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 [[Beta Edtiting|BetaEdtiting]] on the [[Users Mailing List|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 [[Style Mailing List|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. |
|||
</ul> |
|||
By now it has become clear that it makes sense to issue a [[Request For Comment|RequestForComment]] first, wait for a week or two, and then issue a [[Request For Veto|RequestForVeto]]. You should also wait 48 hours for a veto. |
|||
---- |
|||
==Old "Approval" Mechanism== |
|||
''This one 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. |
|||
# 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 want an approval from the Secretary do this: |
|||
#* Make sure there is an [http://test.musicbrainz.org/trac/report/8 Active Ticket for the Style Issue] in the [[Bug Tracker|BugTracker]]. |
|||
#* Let the Style Council reach consensus. |
|||
#* 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. |
|||
<ul><li style="list-style-type:none">This could even be more complicated: |
|||
#* * Create a "request for approval" ticket in the [[Bug Tracker|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 For Style Changes|ChecklistForStyleChanges]]. |
|||
#* * Assign the ticket to you and accept it. |
|||
</ul>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. |
|||
<ul><li style="list-style-type:none">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. |
|||
</ul> |
|||
===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 [[Advanced Relatinship Type|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 [[Users Mailing List|UsersMailingList]] |
|||
If you propose a '''''very'' minor change''', you can skip steps 1 to 3 and request a veto right away. In this case you must include a short note saying that you skipped the request for comments. This means that anybody can veto if they think a detailed discussion is necessary. Similarly you should extend the veto period if the discussion takes longer than two days. |
|||
There is an old page that describes [[How To Propose New Guidelines|HowToProposeNewGuidelines]], but this needs to be updated. |
|||
---- |
---- |
||
| Line 68: | Line 32: | ||
==Some more detailed thoughts== |
|||
=Even Older Stuff= |
|||
<ul><li style="list-style-type:none"> |
<ul><li style="list-style-type:none">'''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. That community has no formal organization. We can still call it the StyleCouncil, though. |
|||
If you want a [[Style Issue|StyleIssue]] to be fixed, do the work yourself. |
|||
</ul> |
</ul> |
||
Now at this point things get tricky. There is no working practice yet, so you'll have to experiment a bit. [[User:DonRedman|DonRedman]] described ''how it could work'' in [http://www.nabble.com/-mb-style-State-of-the-Style-Secretary-t1068709c2885.html#a2813225 this thread]: |
|||
==How the New Style Council Will Work== |
|||
<ul><li style="list-style-type:none">Someone wants a [[Style Issue|StyleIssue]] fixed. She<ref>Today our example person is female. That is balancing sexism :-) .</ref> 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|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 [[Beta Editing|BetaEditing]] on the [[Users Mailing List|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 [[Style Mailing List|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. |
|||
This has not been fixed yet, but there seems to be general consensus about more or less these points: |
|||
# 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. |
|||
# The Council will consist of members, who agree to become '''delegates''' for a specific [[Style Issue|StyleIssue]]. Once a person has become a delegate, she/he is responsible for the progress of this issue according to the process described in [[How To Solve A Style Issue|HowToSolveAStyleIssue]]. That means that a delegate is responsible to ''do the actual work'', if nobody else does it. Delegates should be assigned to [[Style Issue|StyleIssue]]<code><nowiki></nowiki></code>s in a rotating fashion to avoid burnout. |
|||
# All subscribers to the [[Style Mailing List|StyleMailingList]] form an '''interested public''' and take part in discussions about [[Style Guideline|StyleGuideline]]<code><nowiki></nowiki></code>s. |
|||
# Each [[Style Issue|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 [[Issue Tracker|IssueTracker]] 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. |
|||
* 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]]. |
|||
====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. |
|||
* 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= |
|||
<ul><li style="list-style-type:none">''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.'' |
|||
</ul> |
</ul> |
||
By now it has become clear that it makes sense to issue a [[Request For Comment|RequestForComment]] first, wait for a week or two, and then issue a [[Request For Veto|RequestForVeto]]. You should also wait 48 hours for a veto. |
|||
==Members of the Style Council== |
|||
(a.k.a. [[Style Moderator|StyleModerator]]<code><nowiki></nowiki></code>s) |
|||
===Secretaries (''Ministers of Style'')=== |
|||
* [[User:JohnCarter|JohnCarter]] |
|||
* [[User:RjMunro|RjMunro]] |
|||
* [[User:Dupuy|Dupuy]] |
|||
===Editors=== |
|||
* [[User:ClutchEr2|ClutchEr2]] |
|||
* [[User:DJKC|DJKC]] |
|||
* [[User:Gecks|Gecks]] |
|||
* [[G0llum]] |
|||
* [[Mcymd]] |
|||
* [[User:MichelleW|MichelleW]] |
|||
* [[User:Nikki|Nikki]] |
|||
* [[User:Steinbdj|Steinbdj]] |
|||
* [[User:WolfSong|WolfSong]] |
|||
''editor-without-portfolio'' (ombudsman) |
|||
* [[User:DonRedman|DonRedman]] |
|||
===Emeriti=== |
|||
* [[User:TarragonAllen|TarragonAllen]] |
|||
* [[User:NeilCafferkey|NeilCafferkey]] |
|||
==Areas of specialization== |
|||
# [[Metadata|MetaData]] -- [[User:Dupuy|Dupuy]] |
|||
## [[Advanced Relationship Type|AdvancedRelationshipType]]<code><nowiki></nowiki></code>s (basic advanced relationships) -- [[User:WolfSong|WolfSong]] / [[User:Gecks|Gecks]] |
|||
## [[Advanced Relationship Attribute|AdvancedRelationshipAttribute]]<code><nowiki></nowiki></code>s (instruments, etc.) -- [[Mcymd]] |
|||
## [[Advanced Relationship Usage|AdvancedRelationshipUsage]] (what to represent with advanced relationships, what to omit) -- [[User:JohnCarter|JohnCarter]] |
|||
## [[Other Meta Data|OtherMetaData]] ([[Extra Title Information|ExtraTitleInformation]], artist comments, annotations) -- [[User:RjMunro|RjMunro]] |
|||
# [[Data Presentation|DataPresentation]] -- [[User:RjMunro|RjMunro]] |
|||
## [[Formatting Style|FormattingStyle]] ([[Capitalization Standard|CapitalizationStandard]], punctuation, etc.) -- [[G0llum]] |
|||
## [[Internationalization|InterNationalization]] (language stuff) -- [[User:Nikki|Nikki]] / [[User:Dupuy|Dupuy]] |
|||
## [[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 |
|||
==History== |
|||
# [[Genre Style|GenreStyle]] -- [[User:JohnCarter|JohnCarter]] |
|||
## [[Classical Style|ClassicalStyle]] (orchestral & classical music) -- [[User:ClutchEr2|ClutchEr2]] / [[User:WolfSong|WolfSong]] |
|||
## [[Soundtrack Style|SoundtrackStyle]] (musicals, anime, & movie soundtracks) -- [[User:Steinbdj|Steinbdj]] |
|||
## [[Electronic Style|ElectronicStyle]] (electronica, DJ & fan remixes, mash-ups, etc.) -- [[User:Gecks|Gecks]] |
|||
## [[Asian Style|AsianStyle]] (J-pop, K-pop, C-pop, etc.) -- [[User:DJKC|DJKC]] |
|||
The Style Council had a lot of other protocols and processes that preceeded 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 [[History Of The Style Council|HistoryOfTheStyleCouncil]]. |
|||
[[Category:To Be Reviewed]] |
|||
[[Category:To Be Reviewed]] [[Category:Style]] |
|||
Revision as of 21:16, 11 June 2006
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.
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.
The Style Council has two formal members:
- An Elder
-
RobertKaye is the Elder and benevolent dictator of MusicBrainz StyleIssue
s. 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. Who wanted to step off in April 2006 but is still secretary.
How the Style Council Works
- Present your issue and the changes you propose to the StyleMailingList in a new thread.
- Let there be a discussion, see if consensus emerges, or pick up those changes that make sense to you.
- Once the discussion has ebed 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.
- If no veto was cast within 48 hours, go ahead and make your changes.
If somebody has cast a veto, the issue gets presented to the elder, who will have to make a decision. The question, when it is sensible to cast a veto and when not is a difficult one. If you are new to the council, you should take part in the normal discusions for a month or two. Then you should get a feel for when a veto is sensible.
If you propose a very minor change, you can skip steps 1 to 3 and request a veto right away. In this case you must include a short note saying that you skipped the request for comments. This means that anybody can veto if they think a detailed discussion is necessary. Similarly you should extend the veto period if the discussion takes longer than two days.
Some more detailed thoughts
- 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. 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[1] 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 preceeded 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.
- ↑ Today our example person is female. That is balancing sexism :-) .
