History:Release Locking

From MusicBrainz Wiki
Status: This Page is Glorious History!

The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.

  • Status: This work has morphed into DataQuality. This page is kept for historical purposes.

Release Locking was first proposed by DanielBumke under the Name QualityAndQuantity. See also ReleaseLockingDiscussion and QualityAndQuantityDiscussion.

The funny thing about the "locking" is that it will loosen up parts of MusicBrainz. Right now MB has one "strictness" that it applies to all edits. With locking editors will have a way of marking the boundaries between

  1. releases to which an edit is probably beneficial
  2. releases to which an edit is probably harmful.

Then MB can be stricter in accepting changes to the first and looser in accepting changes to the second case, e.g. by

  • accepting or rejecting an edit after the grace period if noone has voted,
  • requiring more or less yes votes to make an edit pass,
  • making the grace period longer or shorter.

Since this system is new and we cannot know for sure what the consequences will be, it will just be enabled for releases whose artist has enough subscribers (what does "enough" mean? tree? more?). This way we can be sure that there are many eyes watching the releases in question. And as a byproduct it will encourage subscribers.

many subcribers few subscribers
release locked strict normal
release unlocked loose normal

For each of these editing levels (loose, normal, strict) we will need to define the following values for each moderation type (or perhaps a moderation type class):

  • Edit voting duration (in days)
  • Number of unanimous votes to pass
  • Expire action: Keep open, accept, reject
  • EditTypes which are AutoEdits (is this doable?)

The following is just a vague proposal:

Normal Strict Loose
Voting period 2 weeks (3 weeks if there are subscribers) 2 weeks 1 week
Yes votes required to pass +1 (=1 more yes than no) +3 +1
Action on expiration accept reject accept
AutoEdits see EditType none All non-structural changes

ReleaseLocking will be introduced in two steps:

  1. First the locking mechanism will be set in place and subscribers will be encouraged to lock releases which they believe to be relatively good (i.e. you expect more than 50% of future edits to deteriorate it). But this will have no effect on the voting system.
  2. After a month or so (we will ask on the UsersMailingList, whether people are finished with locking, the voting system will use the lock-state of releases and make editing easier and harder.