View source for User:OutsideContext/Not Yet Released Releases

{{proposal_failed}}

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. -- [[User:OutsideContext|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 its 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 [[Edit:7275936|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==

* [[Edit:6474608|6474608]] (Dark Tranquillity - Fiction) 
* [[Edit:6762368|6762368]] (Paradise Lost - In Requiem) 
* [[Edit:7274511|7274511]] (Arch Enemy - Rise of the Tyrant) 
* [[Edit:7299559|7299559]] (Nightwish - Dark Passion Play) 

==Discussion==

<ul><li style="list-style-type:none">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. --[[Arty Smokes|ArtySmokes]] 
<ul><li style="list-style-type:none">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 than track durations), especially if they get heavily advertised. Therefore I would not generally disallow release events.  -- [[User:OutsideContext|OutsideContext]] 
<ul><li style="list-style-type:none">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...)  -- [[Brian Schweitzer|BrianSchweitzer]] 06:15, 05 September 2007 (UTC) 
<ul><li style="list-style-type:none">Dates on Wikipedia and Amazon aren't set in stone, so I'm still against adding release event info even for things that are due imminently. See [[Edit:7627873|7627873]] (UK release of J-Lo's latest album put back a week). --[[Arty Smokes|ArtySmokes]]  
</ul>
</ul>
</ul>
</ul>

Considering that this was the main reason the [[Change Default Data Quality Proposal|ChangeDefaultDataQualityProposal]] was initiated, it may be worth some mention here as an attempted solution.  -- [[Brian Schweitzer|BrianSchweitzer]] 06:15, 05 September 2007 (UTC) 
<ul><li style="list-style-type:none">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 [[User:AaronCooper|AaronCooper]] on the ML -- [[User:OutsideContext|OutsideContext]] 
</ul>

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 [[Brian Schweitzer|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) --[[User:voiceinsideyou|voiceinsideyou]] 
<ul><li style="list-style-type:none">It seems there's a general misunderstanding (unless I'm wrong) about [[Change Release Quality Edit|ChangeReleaseQualityEdit]] (and [[Change Artist Quality Edit|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. -- [[User:murdos|murdos]] 08:55, 12 September 2007 (UTC) 
<ul><li style="list-style-type:none">I can assure you this isn't my misunderstanding; that's why I said "it takes far too long". Without the 4 votes it'll take two weeks for that change to go through; most releases that are added before release date are only added 2-3 weeks before release; and this is the exact period at which you want the data to be able to rapidly change as new info is available. Most of the time I don't bother changing the DQ because there is only 2-3 weeks till release and there's just no point. The lowering of DQ needs to either be automatic for releases with release events in the future, or quicker in some way to get applied. (or [[Auto-Editor|AutoEditor]]<code><nowiki></nowiki></code>s need to more regularly watch "change data quality" edits as part of their regular edit set, I guess?) --[[User:voiceinsideyou|voiceinsideyou]] 
<ul><li style="list-style-type:none">Sure, you're right. I think I've misunderstood your first comment ;) -- [[User:murdos|murdos]] 15:55, 12 September 2007 (UTC) 
</ul>
</ul>I've seen releases that had their DQ changed (even to High Quality) with no votes, but one YES is normally enough. Certainly no harm is done by lowering the DQ for forthcoming releases, and it can make it much quicker/easier to fix the troublesome tracklists of new releases. --[[Arty Smokes|ArtySmokes]] 
<ul><li style="list-style-type:none">That was actually the main point of the proposal - problem was, people didn't want the releases lowered to "low quality", as it was taken to imply something about the editor, so the "unverified" fourth DQ idea came up, but we got bogged down in a terminology debate over what to call the various DQ levels.  -- [[Brian Schweitzer|BrianSchweitzer]] 06:47, 15 September 2007 (UTC) 
<ul><li style="list-style-type:none">I don't want to go off topic for this page, but there was some good stuff in the DQ RFC. If you could re-submit some of the things in bitesize chunks, something might actually get done. --[[Arty Smokes|ArtySmokes]] 
</ul>
</ul>
</ul>