History:Checklist For Style Changes
|Status: This page is out of date. It is retained solely for historical purposes. Up to date information is found at Proposals.|
This page describes the things that should be checked before a style change is made to the style guidelines.
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 style change 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 style change 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.