History:History Of Featuring Artist Style
|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.
History of the Featuring Artist Style Guideline
- This page describes the lengthy and winded evolution of the FeaturingArtistStyle (aka StyleGuideline 5 or SG5 in short)
The old FeaturingArtistStyle was very disputed. It read:
- When two artists collaborate on a track or release, file the track/release under the primary artist, and then append the name of the secondary artist to the name of the track/release as follows:
- "Put Your Lights On (feat. Everlast)"
There was a lot of discussion going on on the MailingLists regarding this guideline (10/2004). General consensus was that we wanted to scrap this guideline, however there was no "good" way to to do this with the system at that time, and so work on this was be postponed until AdvancedRelationships would be implemented.
Nothing has really changed since then and in 10/2005 RodBegbie has raised this issue again in this email thread. This OpenStyleIssue was on the agenda for the MusicBrainzSummit7 and was called GettingRidOfFeaturingArtistStyle.
Several lengthy and heated discussions happened on the StyleMailingList (and only there. A huge section of the users never knew what happened). Finally a new guideline was proposed (see below).
During these discussions we found out that the StyleCouncil lacked procedures for deciding upon issues. The majority of the members of the StyleCouncil supported the new guideline in an apache-like vote launched by RodBegbie. This vote however has no legitimity.
Finally the new guideline was made quasi official by Zout on 15-11-2005 by changing this wiki page. He did so because it was supported by a majority of those people that took part in the discussion. But there was no legitimate decision.
The moment that it was being applied, other people have raised strong objections to the new guideline, mainly because it forced editors to change albums into VariousArtists albums. To end this chaos TarragonAllen has been made StyleDude. He has made clear that, since no legitimate decision was made, the old guideline had to be considered official for the moment.
Following that two good things happened:
- The StyleCouncil adapted some new procedures (which are, however, still undocumented)
- Keschte and RobertKaye coded a solution to the VariousArtists problem called SG5DisasterRelief.
In 01/2006 SG5DisasterRelief went live. It does not remove the need for "feat." but at least allows for collaborations where two artists contributed equally to a track. The guideline has been changed to reflect this.
The guideline will probably stay this way until NadelnderBambus.
Attempted summary of the underlying problem
(this does not yet reflect the discussion of 10/2005 and needs to be worked into the above)
There was some kind of consensus that the very best way to handle many of these collaborations would be to attach more than one primary artist to a song or an album, similar to how discogs does it. There was an objection that many applications expect a single primary artist, but this could be solved by just concatenating artists together with "&" for those applications. There was also (somewhere, can't find it now) an objection that this would be inefficient for the back end. The major problem with this, however, is that it's a pretty big upheaval of the database, requiring a huge amount of website code to change, and so this isn't going to happen any time soon.
In the meantime, the guidelines are there to try and strike a compromise between readability and usefulness now, and the ease of conversion to the above system whenever it becomes available.
The current, pre-AdvancedRelationships FeaturingArtistStyle does this by arbitrarily choosing one artist to be primary, and putting the others in brackets with "feat.". This guideline is widely reviled because it's counter-intuitive and impedes searching for works by an artist. A script to convert to a full multi-artist system would have to parse out all the "feat." bits and figure out which artists were meant, intelligently bypassing commas and ampersands only where appropriate.
The alternative proposal is to add new artists representing the collaboration, called "X and Y" or something, and link both artists to the collaboration using "collaborated on" relationships (see MusicalAssociationRelationshipClass).
Problems with this:
- Will add thousands of pseudo-artists to the database, which strikes lots of people as counter-intuitive.
- Makes it harder to navigate from an artist to all of the works they actually performed on.
- Much slower to add these collaborations using the website, since you have to go through the palaver of adding new artists and setting up a bunch of relationships.
- Results in a mess like what's happened to Tom Morello (see here and here).
- Probably a cleaner way of setting ourselves up for the "nice" system above
- Means recording collaborations with actual artist IDs rather than merely putting their names in a freetext field
- Helps when trying to identify which tracks on different albums are actually just the same track
- Probably going to be more straightforward for a script to convert to the ideal situation above.
There's still lots of disagreement over which style is the best. In the database right now, we have a mixture of styles, depending largely on what made sense to the editor at the time. In the absence of a real consensus this seems likely to continue. Each style is particularly appropriate or inappropriate in certain situations, so even if we came up with an "official ruling", it'd probably be ignored by those users who don't read the mailing list ('desire lines', like David Scotson says).