User:OutsideContext/Not Yet Released Releases

From MusicBrainz Wiki
< User:OutsideContext
Revision as of 08:55, 12 September 2007 by Murdos (talk | contribs) (misunderstanding about ChangeReleaseQualityEdit & ChangeArtistQualityEdit (Imported from MoinMoin))
Jump to navigationJump to search

You sometimes find edits that add releases that are announced but not yet released. Those edits are normally heavily discussed, sometimes they are accepted, sometimes voted down. This page is intended to discuss how we should handle those releases. At the moment here are only a few random notes about my opinion on the topic. Comments are welcomed, though. Consider this a rough draft. I will eventually raise this topic on the ML. -- OutsideContext

Why adding upcoming releases is good

Adding an upcoming release allows the metadata to be available right on the release date. This makes it convenient for everybody buying the release once it is out. It also might prove the usefulness of MusicBrainz as a source of music metadata for CD players or ripping software.

As I've seen it so far only people who are really interested in a particular release add it before it's official release. This means the edits are well researched and often the editor will buy the release once it is out and will be able to correct the release in case of mistakes.

Why it is a bad thing to do

  • The release details may change.
  • Especially track durations can't be confirmed and could change.
  • The release could get cancelled.
  • MusicBrainz is a database of facts and not of speculations.

Some advice

  • I think it's a good idea to accept add release edits for upcoming releases if the expected release date is near (few weeks) and the release data can be confirmed by at last two sources, one including an official statement by the band or label.
  • One should double check before voting for such an edit.
  • It isn't very useful to vote down such an edit if the release seems otherwise reliable. It isn't fun to do the same work twice.
  • One should consider the editor who did the edit. If he seems willing to update the release after it is officially released it might be OK to accept the edit even if it is not 100% reliable.
  • lower the data quality of such a release as it was done at 7275936.
  • If track durations are unsure they should be left open.
  • The edit note should contain the release date.
  • Add an annotation to the release: "Note: This release was added before its official release date. Once this has been officially released please verify the existing information, change the data quality to normal and remove this annotation."

Examples

  • 6474608 (Dark Tranquillity - Fiction)
  • 6762368 (Paradise Lost - In Requiem)
  • 7274511 (Arch Enemy - Rise of the Tyrant)
  • 7299559 (Nightwish - Dark Passion Play)

Discussion

  • I'm not sure if this has been put to the ML yet (please do so, if not). I'm strongly in favour of forthcoming releases being added to MBz, so vote in favour if a credible tracklist is presented. The only thing I don't like is when a release event is added for a date that hasn't come to pass. For this reason, I routinely propose changing the data quality to low, and would recommend a guideline saying that release events are NOT added until tangible copies are available. --ArtySmokes
    • Good Point. But the release date must at least be given in the comment for the add edit. On the other side release dates are often very reliable (at least more reliable then track durations), especially if they get heavily advertised. Therefore I would not generally disallow release events. -- OutsideContext
      • I'd tend to prefer the reverse - having a future release date in the event is something searchable, whereas having no date, the release is much more likely to go unnoticed. That said, I think there's a degree we need to decide upon for what is considered a *reasonable* future release's reason to be listed. Worst I found a while back was a release scheduled for a 2009 release, and one scheduled for a 2012 release date. (We can ignore the ones set to 2099...) -- BrianSchweitzer 06:15, 05 September 2007 (UTC)

Considering that this was the main reason the ChangeDefaultDataQualityProposal was initiated, it may be worth some mention here as an attempted solution. -- BrianSchweitzer 06:15, 05 September 2007 (UTC)

  • Yes, I think we really should lower the data quality of such releases. That makes it even clearer that the release needs to be reviewed. In addition I think there should be a note added to the release as it was suggested by AaronCooper on the ML -- OutsideContext

Regarding "This means the edits are well researched"; I thoroughly disagree with this assertion. I deal with at least 5 or 6 hip hop adds a month prior to release date (often for tagging to bootleg/leaked rips) and they are typically quite poor quality, often based on it becoming listed on iTunes (with itunes' horrible track titling). I still agree with having them in the DB prior to release (WITH release dates, agreeing with BrianSchweitzer here) but having the system automagically lower the data quality would be lovely. It takes far too long currently. (4 unanimous votes is pretty difficult for all but pop artists) --voiceinsideyou

  • It seems there's a general misunderstanding (unless I'm wrong) about ChangeReleaseQualityEdit (and ChangeArtistQualityEdit): the 4 unanimous votes are only required to shortcut the voting period. If at the expire time there are 1 Yes / 0 No votes (or e.g. 3 Yes / 1 No), the edit will be applied like every other edits. -- murdos 08:55, 12 September 2007 (UTC)