History:Great Dispute

Status: This Page is Glorious History! The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.

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:

1. differences in coding and communications styles
2. lack of sufficient resources for developers (enough staging/testing servers, etc.)
3. lack of guidelines or rules of behavior for the development team (and community)
4. changes in MB as the community becomes larger, and more "businesslike"
5. failures or deficiencies in the communications forums (e.g. arguments in Trac tickets)
6. lack of clarity about the "final arbiter" of disputes
7. 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:

• EncourageVolunteers

• Create an environment that encourages volunteers (developers and others).

• MakeIssuesPublic

• Transparency in communications (public) and process (documented).
  • Alternative WikiNames: MakeItPublic, PublishIssues, PublishProblems, ParticipateOpenly

• SeekMediators

• Seek mediators for conflicts, ideally, even before they occur.

• DistributeResponsibility

• Distribute responsibility, by asking for help, and growing teams.
  • Aternative WikiNames: ManyShoulders

• PutTheCommunityFirst

• Needs of the community as a whole come before the demands of any individual.
  • Any alternativeWikiNames for this one?

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 session 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:

1. Agree on and document Development process
2. Agree on and document ConflictResolution process
3. CodeOfConduct for developers and others
4. BugTriaging team for BugTracker
5. Changes to rollout process (selectable server versions? live-data testing?)
6. "Support groups" (like WikiPedia Esperanza, etc.)
7. Improvements to development resources (more testing/staging servers?)
8. Establishing web "forum(s?)" for better communication between developers/users
9. 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).