History:Checklist For Style Changes

From MusicBrainz Wiki
Revision as of 20:58, 1 November 2006 by DonRedman (talk | contribs) (CategoryStyleCouncil and status update (Imported from MoinMoin))
Jump to navigationJump to search

Checklist for Changes to the Style Guidelines

This page describes the things that should be checked before a StyleChange is made to the StyleGuidelines. It NeedsIntertwingling, too.

There was a time when this checklist was rigidly enforced, but this paralyzed the StyleCouncil (see HistoryOfTheStyleCouncil). This list is still valuable but not to be used as a form that you have to fill out in three exemplaires with attested copies ;-) .


How will this affect the data?

  • Before a StyleChange gets approved, we must have a clear idea of how this will affect the data. This question is difficult to answer, because it involves what people will do with the data by following the new rules or using the new possibilities. However, it is very important to prevent something like the SG5Disaster from happening again. How will the change affect the way (old and new) data is stored? What is the difference between the way it is stored now and the way it will be stored? How big is the change in SoftStructure? It might very well be that the change resolves some oddities but creates problems for cases that were simple unter the old guideline. Concrete questions are: * Is the change just an addition or or a real change in structure? Do elements get reorganized? * How far does the change reach? (e.g. before the SG5DisasterRelief changing a single TrackArtist would make an album a VariousArtistsRelease, which would move it to another category on the artist page...). * What were the edge cases of the old guideline, and how are these affected?

Conflicts with other style guidelines

  • What is the scope of the affected guideline? Does the StyleChange move the boundaries of this scope? The OfficialStyleGuidelines form a balanced set. Both extending and reducing the scope of one element can unbalance the whole set.

Required editor time

  • How much work by editors is required to implement the change? If this is a lot: Can the change be automated, and is this worth it?

Required developer time

  • How much work by developers is required to implement the change? Keep in mind that developer time is limited and we wish to avoid wasting their time if at all possible. The person who requests an approval usually gets the responsibility to do the following things: * Update relevant wiki pages * Close the issue in the BugTracker * Communicate the finished change on the UsersMailingList or the BrainzBlog

Impact on paying clients

  • Could the change possibly affect paying clients? If so find out if it does. Remember that paying clients do not control what changes we make, but we think of them regarding how we roll out changes.

The initial list was created by TarragonAllen.