History:Label Future: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(Should be good now. All (?) issues/tickets listed. (Imported from MoinMoin))
No edit summary
 
(29 intermediate revisions by 6 users not shown)
Line 1: Line 1:
=Label future=
=Label future=


==Purpose==
<small>[[Label]] > Label future </small>


This page should be used to collect the various limitations and known bugs of the current label system in [[MusicBrainz]], as well as ideas about how to enhance it and make it evolves toward a better model.
{{LabelsStatus}}


==Outstanding bugs==
==Purpose==

* The subscription mail doesn't contain edits for subscribed labels (related to tickets [[Ticket:2675|2675]] & [[Ticket:884|884]])
* [[ModBot]] doesn't "collect" empty labels and doesn't delete them
* [[Ticket:3511|3511]]: Python error when searching some specific record label

==Tech stuff==

* [[Ticket:3576|3576]]: Schema inconsistency for "label" table

==Easy enhancements==

List of suggested enhancements, supposedly easy to fix:
===Style and doc tasks===

* discuss the use of collabs labels (see [[Talk:Label|LabelDiscussion]])
* Doc task: documentation is lacking a lot on label [[Edit Type|EditType]]s, and also [[Edit Label Page|EditLabelPage]]
* Doc task: stuff examples in all existing documentation
* [[Ticket:2730|2730]]: New AR: Label/Artist has YouTube page at X

===UI quirks / missing UI===

* [[Ticket:3510|3510]]: Add Release on label pages
* [[Ticket:3299|3299]]: Right label rowid, but wrong label name indicated
* [[Ticket:2721|2721]]: lookup labels based on Label Code
* [[Ticket:2674|2674]]: Add the possibility to search edits by label
* [[Ticket:2684|2684]]: Nasty edits view sideways scrolling problem (Yet again)

===UI + back-end hack required===

* [[Ticket:2653|2653]]: Should get a warning/confirmation message when adding releases to holding label
* [[Ticket:2602|2602]]: Add a warning when duplicate barcodes are entered


===Questionnable enhancements===
This page should be used to collect the various limitations and known bugs of the current label system in [[MusicBrainz]], as well as ideas about how to enhance it and make it evolves toward a better model.


* [[Ticket:2657|2657]]: Server > Labels > New AR "ReleaseX was licensed from LabelY"
==List of outstanding active tickets that should be fixed==
* [[Ticket:2713|2713]]: Present shortlist of labels based on existing info
* [[Ticket:2711|2711]]: Batch edit for labels?


==Other enhancements==
* [http://bugs.musicbrainz.org/ticket/2565 2565]: Add "format/medium" field for release events
* [http://bugs.musicbrainz.org/ticket/2564 2564]: Barcode data type and barcode verification


==List of (easy) enhancements without ticket yet that we should do ASAP==
===List of enhancements with some (bigger or unknown) technical impact:===


* [[Ticket:3491|3491]]: Failed prerequisite for editing release event when old label has been merged in the mean time (note this looks like a more vast bug, probably hitting artist/releases as well)
* discuss and rationalize the use of [[Special Purpose Label|SpecialPurposeLabel]]<code><nowiki></nowiki></code>s (like [autorelease])
* [[Ticket:3440|3440]]: sort on cat# sorts 543483 before 55225
* need a small logo for labels for wiki use (just like we have for releases and artists).
* [[Ticket:2574|2574]]: Release date should not be mandatory in release event.
* documentation is lacking a lot on label [[Edit Type|EditType]]<code><nowiki></nowiki></code>s, and also [[Edit Label Page|EditLabelPage]]
* [[Ticket:2675|2675]]: View label edits don't show [[Advanced Relationship|AdvancedRelationship]] edits related to the label
* once we have the system live, we need to stuff examples in all existing documentation
** see [[Ticket:884|884]]:
* have a new interwiki link to directly point to labels on [[MusicBrainz]]
* subscriptions preferences wording should be updated in the site as they mention only artists
* remove the card label status link in all [[Label Category|LabelCategory]] linked page once we go live


===Wontfix for now:===
==List of enhancements that may be fixed==


* [[Ticket:2658|2658]]: Server > Labels > "LabelX was renamed to LabelY" AR does not need begin & end dates
* [http://bugs.musicbrainz.org/ticket/2344 2344]: Multiple labels with identical label codes can be created (without warning)
<ul><li style="list-style-type:none">This raise the question of "extending" the AR tree so that it supports an extra information about AR (having dates or not) -- [[User:dmppanda|dmppanda]] 15:44, 23 April 2007 (UTC)
* [http://bugs.musicbrainz.org/ticket/2341 2341]: Label creation page should offer (documentation) links
</ul>


==Needs research==
==List of things we need more informations about==


* There have been [http://lists.musicbrainz.org/pipermail/musicbrainz-users/2007-January/015517.html some discussion] lately about concurrent/additional label identification systems in the wild, apparently dependent of the country. At that time, we lack informations about how these relate to the '''Label Code''' system, and there is no solution foreseen. '''Please provide input''' on that thread if you have more informations. -- [[User:dmppanda|dmppanda]] 19:28, 29 January 2007 (UTC)
* There have been [http://lists.musicbrainz.org/pipermail/musicbrainz-users/2007-January/015517.html some discussion] lately about concurrent/additional label identification systems in the wild, apparently dependent of the country. At that time, we lack information about how these relate to the '''Label Code''' system, and there is no solution foreseen. '''Please provide input''' on that thread if you have more information. Please [[Answer Me|AnswerMe]] if you do. -- [[User:dmppanda|dmppanda]] 19:28, 29 January 2007 (UTC)


==NGS/Pie in the sky==
==Known limitations requiring lots of work and future major enhancements==


None
* Ideally, we could be able to attach multiple release events (release date and country) to a unique catalog number / EAN. -- [[User:dmppanda|dmppanda]] 21:22, 03 November 2006 (UTC)
* Also one release event could use multiple labels. For example Inside Out Music records are always distributed by SPV and they have an SPV catalogue number as well as an IO catalogue number. Therefore I think one "release set" should contain: several <release date, release region> pairs, several <label, catalogue number> pairs and single fields such as the [[EAN]] (of which the barcode is just the representation, but could leave the name like that as it's easier to identify for users which don't know that). -- [[User:Shepard|Shepard]] 13:37, 07 January 2007 (UTC)
* ARs such as the [[Discogs Relationship Type|DiscogsRelationshipType]] and the [[Amazon Relationship Type|AmazonRelationshipType]] would ideally be attached to a release set - but I guess that has to wait until we can separate between releases and albums. :) -- [[User:Shepard|Shepard]] 13:37, 07 January 2007 (UTC)
** I'm not sure I understand correctly these last points. How would we allow: on one hand, a single release event (country, date) to be linked to several different label/cat/bar (as in your example), and to single AMZ/Discogs links, and on the other hand, a single release set (single label/cat/bar) to be linked to several different release events and several different AMZ/Discogs links? Though this question is theoretical ;) - Also do you imply that Discogs/AMZ links should be unique to a release set? -- [[User:dmppanda|dmppanda]] 16:15, 07 January 2007 (UTC)
*** Well, one release date could refer to several label releases (ie, different pages on amazon and discogs), and indeed, different release dates could refer to different label releases. Finally, one label release (ie, page on amazon and discogs) could be a release on 2 or more labels (eg [http://www.discogs.com/release/374880 http://www.discogs.com/release/374880]). I think the best way to to this would be to allow for ARs (specially discogs and amazon ones, perhaps others) specific to release events, but this is probably difficult/impossible. Ultimately I think this will all be easier to deal with when NGS gets here. -- [[User:Gecks|Gecks]]
*** My initial idea in [[Release Data Set|ReleaseDataSet]] was to have one set for each unique release (identified by the EAN for example, although sometimes not even they identify a unique release). In this set you would then have a list of <release date, release country> pairs - still for this unique release, because different countries have different days in the week when music is mostly released, so the item with the EAN 1234567890123 could be released on Monday in .de and on Wednesday in the UK for example. Then you would also store a list of <label, cat> pairs, because different labels work on one unique release - as I described in my example above, InsideOut releases are always distributed by SPV and both have their own catalogue system. And then you store other identifiers in this set, like the EAN, Discogs/ASIN stuff (yes, unique to a release set).<br/> Note though that this page here is about a first step into the right direction. The ideas in [[Release Data Set|ReleaseDataSet]] are relativised by NGS where the whole tracklisting with titles, tracktimes, [[Disc ID|DiscID]]s and so on would be included in a "release set". So, not everything needs to be coded yet, limitations are implied. One label per release date is a good start. If this was to be extended before labels go live, I would prefer multiple labels per date over multiple dates per label, but that's just a personal preference. -- [[User:Shepard|Shepard]] 15:22, 09 January 2007 (UTC)


==Controversial==
* Labels activities may be very complex (dismantling, dormant labels, reviving), and the concept of a single life between two points in time (begin date and end date) may prove rather inadequate (or at least a raw approximation). At that time there's no way to provide with a better model, though there is hope this issue may be solved later (note that the problem is similar with groups). We need a richer way to describe label activities and period of activities. -- [[User:dmppanda|dmppanda]] 14:21, 22 March 2007 (UTC)
** A ticket related to that has been filled: [http://bugs.musicbrainz.org/ticket/2342 2342] Split [[Label Type|LabelType]] into 5 fields


None
==List of fixed tickets (historical purpose)==


==Wontfix==
* #2563: Label code field shouldn't be a free string
* #2366: automatically filter out "LC" from label codes
* #2348: Suggested AR: {artist} was signed to {label} from {year} to {year}
* #2347: Suggested AR: {label} has a fan page at {url}
* #2345: 'is/was division of' label AR


None
==List of old discussions (historical purpose)==


==Further Discussion==
[[Label Code|LabelCode]]:
* I have never encountered a label code with a hyphen before. I suggest we stick to just LCxxxx in [[MusicBrainz]] to stay as close to what's printed on covers and discs as possible. -- [[User:Prodoc|Prodoc]] 22:11, 08 November 2006 (UTC) I don't think we should even store the LC(-) part. Storing xxxx in the database IMO is enough, as this is the only relevant part. How it is displayed is another and IMO irrelevant problem. -- [[User:dmppanda|dmppanda]] 01:29, 11 November 2006 (UTC)


Any idea if Modbot will be removing "empty" labels any time soon? A spambot/editor added a list of nearly 4000 (phoney) labels to the database last week. They were all added despite getting three 3 NO votes, and will presumably have to be removed manually. [[Answer Me|AnswerMe]] Also, I'm about to begin merging various major label imprints, according to my previous discussions with you. I've come to the conclusion that "Mercury Records (country X)" and "Mercury Records (country Y)" should be filed together, since the actual imprint/logo is simply "Mercury" or "Mercury Records" and is owned by Universal Music Group, which uses it all over the world. I'm going to start, however, by merging some branches of Island Records, as Mercury is a sore point. ;) --[[Arty Smokes|ArtySmokes]]
[[Label Sort Name|LabelSortName]]:
* At that time, there are no known cases of two or more "collaborating" labels issuing a release, so there should theoretically be no need for rules regarding collaborations.
* The last point (4) of label [[Sortname|SortName]] style may be discussed, and one may argue that some label can use the name of their founder, and that such names may follow the usual artist [[Sortname Style|SortNameStyle]]. I don't think so, and I would like to see concrete examples before taking decision and add additional sorting rules. -- [[User:dmppanda|dmppanda]] 18:54, 29 January 2007 (UTC)


[[Category:To Be Reviewed]] [[Category:Label]] [[Category:Discussion]]
[[Category:Discussion]]

Latest revision as of 20:27, 26 May 2015

Label future

Purpose

This page should be used to collect the various limitations and known bugs of the current label system in MusicBrainz, as well as ideas about how to enhance it and make it evolves toward a better model.

Outstanding bugs

  • The subscription mail doesn't contain edits for subscribed labels (related to tickets 2675 & 884)
  • ModBot doesn't "collect" empty labels and doesn't delete them
  • 3511: Python error when searching some specific record label

Tech stuff

  • 3576: Schema inconsistency for "label" table

Easy enhancements

List of suggested enhancements, supposedly easy to fix:

Style and doc tasks

  • discuss the use of collabs labels (see LabelDiscussion)
  • Doc task: documentation is lacking a lot on label EditTypes, and also EditLabelPage
  • Doc task: stuff examples in all existing documentation
  • 2730: New AR: Label/Artist has YouTube page at X

UI quirks / missing UI

  • 3510: Add Release on label pages
  • 3299: Right label rowid, but wrong label name indicated
  • 2721: lookup labels based on Label Code
  • 2674: Add the possibility to search edits by label
  • 2684: Nasty edits view sideways scrolling problem (Yet again)

UI + back-end hack required

  • 2653: Should get a warning/confirmation message when adding releases to holding label
  • 2602: Add a warning when duplicate barcodes are entered

Questionnable enhancements

  • 2657: Server > Labels > New AR "ReleaseX was licensed from LabelY"
  • 2713: Present shortlist of labels based on existing info
  • 2711: Batch edit for labels?

Other enhancements

List of enhancements with some (bigger or unknown) technical impact:

  • 3491: Failed prerequisite for editing release event when old label has been merged in the mean time (note this looks like a more vast bug, probably hitting artist/releases as well)
  • 3440: sort on cat# sorts 543483 before 55225
  • 2574: Release date should not be mandatory in release event.
  • 2675: View label edits don't show AdvancedRelationship edits related to the label

Wontfix for now:

  • 2658: Server > Labels > "LabelX was renamed to LabelY" AR does not need begin & end dates
  • This raise the question of "extending" the AR tree so that it supports an extra information about AR (having dates or not) -- dmppanda 15:44, 23 April 2007 (UTC)

Needs research

  • There have been some discussion lately about concurrent/additional label identification systems in the wild, apparently dependent of the country. At that time, we lack information about how these relate to the Label Code system, and there is no solution foreseen. Please provide input on that thread if you have more information. Please AnswerMe if you do. -- dmppanda 19:28, 29 January 2007 (UTC)

NGS/Pie in the sky

None

Controversial

None

Wontfix

None

Further Discussion

Any idea if Modbot will be removing "empty" labels any time soon? A spambot/editor added a list of nearly 4000 (phoney) labels to the database last week. They were all added despite getting three 3 NO votes, and will presumably have to be removed manually. AnswerMe Also, I'm about to begin merging various major label imprints, according to my previous discussions with you. I've come to the conclusion that "Mercury Records (country X)" and "Mercury Records (country Y)" should be filed together, since the actual imprint/logo is simply "Mercury" or "Mercury Records" and is owned by Universal Music Group, which uses it all over the world. I'm going to start, however, by merging some branches of Island Records, as Mercury is a sore point. ;) --ArtySmokes