[mb-style] Composition/Performer/Production ARs at Release or Track level? - PROPOSAL

[Brian Schweitzer]

Ok, we just had a lengthy debate on this in IRC, which has, I think, helped
to clarify the issue.
( starts around
http://chatlogs.musicbrainz.org/2008/2008-01/2008-01-02.html#T00-42-16-600403)

Essentially, I think this whole thing falls into one of two views.  Problem
is, those two views are 100% incompatible.  I think we REALLY do need to
decide that one or the other is the viewpoint we're using, however, as this
is causing more and move confusion as to which ARs people should be adding,
which ARs are correct or wrong, etc.

Viewpoint 1:
   A release is the sum of its tracks.
   An AR added at the release level is valid if and only if it applies to
all tracks.
   ---------------------------------------------------
   Thus: ARs can therefore not be "vague" or "fuzzy" - they either are
factually correct for the entire release, or they should be in annotations
until someone else can update them.


Viewpoint 2:
   A release and its tracks are two entirely separate considerations.
   An AR added at the release level is valid if is says something about at
least one of the tracks on the release.
   ---------------------------------------------------
    Thus: ARs at the release level can be "fuzzy" - if you know someone
played alto sax on some track, but you don't know which track(s), then it
can be added at the release level for someone later (who has better info) to
move to the proper track(s).


Now I personally have always thought akin to #1.  A release is, to me,
essentially a collection of specific versions of tracks in some particular
order on various forms of media.  Thus having release level ARs be those
which applied to all tracks made sense, especially before we had batch AR
ability, when actually adding the same AR to every single track took
forever.

However, perhaps it is time to use the 2nd viewpoint instead, now that we
can do ARs in batch.  It was argued to me in IRC that this at least gets the
release to show under the artist, rather than trapping the data in an
annotation, when the editor does only have fuzzy info.  This kind of makes
sense to me.

HOWEVER!  If we're really going to interpret release level ARs this way,
allowing for people to add release level ARs for "I know John played on some
tracks on this album, but I don't know which particular tracks", let's say
so!

Right now, half of us are voting against such ARs, while the other half of
us are adding them.  Right now, many of us are adding release level ARs,
rather than adding those same ARs to every single track, when they DO have
the info to be able to say that AR does apply to every single track.

So, if one person is adding "fuzzy" release level ARs, and another person is
adding non-fuzzy ARs at the release level, but could add them at the track
level, we're left with any given release level AR being of rather low DQ -
it *could* apply to the entire release...  or it *could* just be that
someone didn't know which tracks to apply it to.

=========================

So I've been somewhat convinced, and I suggest, let's use viewpoint 2 as the
official guidance for how to handle ARs:

Proposal:

  Release level ARs are not now or ever to be inherited to tracks.
  Release level ARs are allowed to be, and always ought to be viewed as
"fuzzy".
  However, track level (and for later, track master ARs) are *never* to be
fuzzy.
  Finally, apply ARs to every track you can, if you have the info - ie: from
this point on, if an AR applies to all tracks, it ought to be applied to all
tracks, and not just to the release.

=========================

(Any time I say AR here I mean performance and production ARs, not the ones
that inherently have nothing to do with tracks, such as the coverart AR.)

Brian

(By the way, though the ArtistRoleInheritance wikipage may have been left
untouched, this has come up several times in style, users, IRC, the forums
and there's at least one lengthy bug ticket discussing it, so I don't think
this has at all be "largely ignored" as a whole.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-style/attachments/20080101/cf4404cd/attachment.htm