[mb-style] RFC-327: Featured Artists

SwissChris swisschris at gmail.com
Sat Jul 16 01:04:16 UTC 2011

On Sat, Jul 16, 2011 at 1:55 AM, Andii Hughes <gnu_andrew at member.fsf.org>wrote:

> On 16 July 2011 00:45, SwissChris <swisschris at gmail.com> wrote:
> > I wouldn't disagree on the fact that "feat." has a specific meaning
> > different from other link phrases. A said before I wouldn't thus oppose
> > keeping it as link phrase between artists even on recording level.
> > But fact is:
> > 1. We agreed on adding (featured) artists on tracks (instead of artists)
> > only because of the pre-NGS technical limitations. Now that these
> > limitations are finally gone, we should get rid of this (wrong) guideline
> > asap.
> Yes, which is what this proposal is progress towards.
> > 2. Many (if not most) of the so called "feat." artists we now have in MB
> are
> > actually not "featured" artists in reality, since the guideline asked to
> > always use "feat." whatever the actual link phrase on a release may be.
> It's
> > wrong or at least inaccurate information that we shouldn't wait any
> longer
> > to correct.
> I don't see this; there are plenty of 'vs.' and '&' connected artists
> instead of 'feat' and these have mostly been converted to artist
> credits.

Obviously we're not editing the same kind of music. I know of hundreds and
thousands of tracks where the link phrase should be "und", "avec", "con",
"Duett mit", "en duo avec" etc. (as said I mostly don't edit in english).
All these now have this ugly, wrong and redundant ("feat." artists) attached
to the title – and your proposal asks to keep these for another year even
after having added all the information to artist credits?

> > 3. If I understood correctly ws/1 users will still get the information,
> it
> > will only be displayed in a less elegant, less accurate way. This is IMHO
> > not reason enough to double the work of the editors trying to improve the
> DB
> > according to the NGS principles.
> They'll get a huge bunch of new artists called 'X feat. Y'.  In some cases,
> that
> will turn a discography under a single artist under to one split into
> maybe 10 or 20
> different artists (if a lot of their tracks have feat. artists).
> I don't see how this 'double[s] the work of the editors'.  You still
> have to change
> existing track and recording titles separately, and even if we change
> the track guidelines,
> it sounds like they will be different from the strict recording
> structure as people want them
> closer to the cover.

Well after adding the correct AC with the link phrase "as on the cover" -
and eventually a normalized link phrase for recording, based on the wording
of the guideline I should also add the "feat." part to the track title (or
not be allowed to remove it) – and then come back in a year, to remove it
again: That's what I call unnecessarily doubling my work ;-)

> > 4. The current guideline is a pre-NGS guideline, which - like so many
> others
> > - has obviously not really been updated. What editors do in such cases is
> to
> > ignore the parts that no longer apply because we now have a better way to
> > deal with a specific problem. They have done so in the past and will
> > hopefully do so again, until there's an agreement on a new guideline. If
> > your proposal passes, it would be a post-NGS guideline much harder to
> ignore
> > ;-)
> You shouldn't be ignoring it.  I'll vote down or revert any such edit
> I see and others should too.

I could think of more productive ways to use your time seen the problems
with the UI and other unresolved issues with the (premature?) implementation
of NGS ;-)

> --
> Andii :-)


> _______________________________________________
> MusicBrainz-style mailing list
> MusicBrainz-style at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-style/attachments/20110716/5d58f569/attachment.htm 

More information about the MusicBrainz-style mailing list