RFC: Modify edit conditions for destructive edits
2009-12-01 16:54:57 GMT
I ran into a situation today where, when retagging some files, I found that a vinyl VA release I'd entered (with 4 verification links to show it's existence plus track list, etc) 6 months ago had been removed. Being VA, especially, it's hard to catch these, as you cannot subscribe to releases, nor to VA. But even had it been some specific artist, unless one is diligent about checking open remove * edits, these can slip through without the adding editor noticing.
This RFC is intended to solve one other problem this edit brought to my attention, namely, that destructive edits pass on a 0:0 vote at expiration, just like most other edit types. This RFC would change the following edit types so that, if on expiration the edit count is 0:0, the edit would fail, rather than pass:
* Remove Artist
* Remove Artist Alias
* Remove Disc ID
* Remove Release
* Remove Release Event(s)
* Remove Releases
* Remove Track
* Remove PUID
* Remove Relationship
* Remove Relationship Attribute
* Remove Relationship Type
* Remove Release Group
* Remove ISRC
* Remove Label
* Remove Label Alias
It's my opinion that any destructive edit should have at least some review - additive or modifying edits can always be fixed if bad ones expire in, but destructive edits mean the entire entity has to be recreated from scratch, which is far more work to fix. (I'm tempted to suggest that destructive edits should only pass if they at least meet the threshold for them to pass - *:3, rather than simply 0:1, but the latter has no apparent negatives, while the former might have some hidden problems that simply haven't occurred to me.)
In addition, I would note that the particular remove edit in this case came from an editor who, in the 8 months since he created his account, has made a whole 2 edits - only one (this one) a votable edit, and who ignored the info given in the add release edit. I've noticed that most other problematic (at best misguided, but often contrary to guidelines, common sense, etc) destructive edits that I've encountered also came from similarly new and low-edit-count editors. Thus, in addition to modifying the minimum vote count for such an edit to pass, I would also add the same conditions to create destructive edits which apply to creating add NAT edits; this would raise the minimum edit count to even create such an edit, if only slightly, in hopes that editors with 10 voted edits at least have some basic familiarity with MusicBrainz, which cannot be assumed of the brand new editor making his or her first voted edit.
Side note: In the future, it'd be nice also if we could have two new abilities - have the adding editor auto-included on the email list for any destructive edit (so if you added the release, if someone tries to remove it, you get emailed), but also, to make researching the remove edit much more possible, it'd be nice if the "This release has been removed" and "This release group has been removed" texts also contained a link to the removing edit. But those are merely requests for future server development, so I'm not making them part of this RFC.
_______________________________________________ Musicbrainz-style mailing list Musicbrainz-style@... http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style