User:OutsideContext/Not Yet Released Releases

From MusicBrainz Wiki
< User:OutsideContext
Revision as of 21:29, 4 September 2007 by OutsideContext (talk | contribs) (Answer to Arty about release dates (Imported from MoinMoin))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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 advise

  • 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.
  • It might be good to 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.

Examples

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