History:Great Dispute: Difference between revisions
(think we can say that its *over* now. anyone write shorttxt wat actualy happend? (Imported from MoinMoin)) |
RobertKaye (talk | contribs) ((Imported from MoinMoin)) |
||
Line 55: | Line 55: | ||
===Concrete Steps=== |
===Concrete Steps=== |
||
NOTE: Many of these concrete steps have not been followed up on since the underlying problems are no longer present in [[MusicBrainz]]. This section should be kept for historical reference and to give some perspective to future conflicts. |
|||
Although there wasn't time to discuss them in much detail, the [[User:Dupuy|moderator]] also came up with a list of various proposals (originally with two items numbered 3, and forgetting to include the last two items) that were suggested earlier on the mailing list, or which were mentioned in the IRC chat: |
Although there wasn't time to discuss them in much detail, the [[User:Dupuy|moderator]] also came up with a list of various proposals (originally with two items numbered 3, and forgetting to include the last two items) that were suggested earlier on the mailing list, or which were mentioned in the IRC chat: |
Revision as of 20:32, 1 February 2007
The Great Dispute
In the fall of 2006, there transpired a series of events that led up what we colloquially know as the Great Dispute.
Related Documents
Currently a random collection of 'places' and events of the dispute.
- The MusicBrainzHaiku gives the shortest possible summary.
- On August 15th, 2006 Robert writes a blog post entitled Developer changes, in which he states that he will remove Keschte's developer privileges.
- This blog post brought up voluminous discussions on the UsersMailingList, mainly in the threads Open Letter to the MusicBrainz Community and Digest of a personal thread that Fuchs started (Was: Uff ...).
The IRC Chat
On August 21st, 2006, from 2100 to about 2330 GMT, there was an IRC discussion about this problem (see chatlog), which still managed to be less voluminous than the UsersMailingList discussion.
Underlying Problems
During this discussion, the participants developed a list of the underlying problems that had led up to the dispute:
- differences in coding and communications styles
- lack of sufficient resources for developers (enough staging/testing servers, etc.)
- lack of guidelines or rules of behavior for the development team (and community)
- changes in MB as the community becomes larger, and more "businesslike"
- failures or deficiencies in the communications forums (e.g. arguments in Trac tickets)
- lack of clarity about the "final arbiter" of disputes
- missing development guidelines/concept + master plan
Generally, points 1 and 3 were felt to be the most significant, with 4, 5, and 6 also important.
Guiding Principles
To address these problems, a number of of guiding principles for the MusicBrainz community were outlined; these should eventually have their own WikiPages, once we come up with good WikiPhrases for them:
The MusicBrainzPrinciples:
- Create an environment that encourages volunteers (developers and others).
- Transparency in communications (public) and process (documented).
- Alternative WikiName
s: MakeItPublic, PublishIssues, PublishProblems, ParticipateOpenly
- Alternative WikiName
- Seek mediators for conflicts, ideally, even before they occur.
- Distribute responsibility, by asking for help, and growing teams.
- Aternative WikiName
s: ManyShoulders
- Aternative WikiName
- Needs of the community as a whole come before the demands of any individual.
- Any alternativeWikiName
s for this one?
- Any alternativeWikiName
Concrete Steps
NOTE: Many of these concrete steps have not been followed up on since the underlying problems are no longer present in MusicBrainz. This section should be kept for historical reference and to give some perspective to future conflicts.
Although there wasn't time to discuss them in much detail, the moderator also came up with a list of various proposals (originally with two items numbered 3, and forgetting to include the last two items) that were suggested earlier on the mailing list, or which were mentioned in the IRC chat:
- Agree on and document development process
- Agree on and document ConflictResolution process
- Codes of conduct for developers and others
- Bug triage team for Trac
- Changes to rollout process (selectable server versions? live-data testing?)
- "Support groups" (like Wikipedia Esperanza, etc.)
- Improvements to development resources (more testing/staging servers?)
- Establishing web "forum(s?)" for better communication between developers/users
- Enhance mb server to collect immediate feedback from users
There is much that still needs to be done - some of these proposals must be made much more specific to be meaningful, and some of them are surely quite contentious (notably the first two or three). As a start, if you are interested in participating in one or more of these, please note your interest in the Discussion section below. As the mailing lists have been pretty swamped lately, it may be more effective to create wiki pages for each of these and to have the discussion there; please discuss the page names here before creating them (that will probably happen sometime later on Tuesday).
Discussion
Support Groups
Brainstorm for a Name
(just add to the list, no negative comments)
- Esperanza
- CupOfHope
- RentAMoose - inspired by our unofficial mascot; expresses that you "rent" a mediator/helper when you have problems.
- I would hope we could find a music-related name; a bit of searching turned up GleeClub, which I like quite a bit @alex
- Another music related idea: Are there songs titles that inspire you with hope?
- WhatWouldTheMooseDo
- While we're at it, we could probably use a name for the bug triage group as well; I thought of PianoTuners...
- The GentleMoose or the KindlyMoose - This strengthens the aspect that these people offer help, instead of people "renting" their services, and it shows that moose are friendly creatures :-)
- I think some of you never met a real moose! They're scary! Meanwhile, I would like to start writing up a guide to 'how to go about bug triaging', but I've been hampered by fear of the wiki and getting growled at for picking a bad WikiName. So I'm gonna start it offline, but could someone like, choose a name already? -- KrazyKiwi
- Here it is: BugTriaging. :-) BTW CamelCase
d Words become links without the tedious
[""]
--DonRedman