History talk:Release Locking

From MusicBrainz Wiki
Revision as of 07:08, 26 March 2010 by BrianSchweitzer (talk | contribs)

Release Locking Discussion

Tentative Summary of the ReleaseLocking Discussion

Attention.png ReleaseLocking has morphed and will be implemented as DataQuality and discussed in DataQualityDiscussion. This page will be kept for historical purposes.

Agreed upon and open issues in QualityAndQuantityDiscussion and the email thread (59 messages!)

Releases are either locked or open

  • Releases will have a new "locked" flag. If a release is locked, any edits made to the release will be forced to a vote. If the release is open, all edits will be AutoEdits.

But which releases should be opened initially?

When ReleaseLocking is implemented we have to decide, which releases are open and which not. We cannot open (or close) the whole database. We could start like this (listed here in a random order and we might only choose some of these):

  • Releases belonging to non-subscribed artists are unlocked.
  • With releases that have subscribers we just ask the subscribers to lock the releases they deem correct:
    1. The locking tag is set to "open" before the ReleaseLocking rules take effect.
    2. Every subscriber is sent a mail saying "Artist XXX will be unlocked in 2 weeks (say), please go to this page to lock any data you are sure is correct".
    3. During this period LockEdits will be AutoEdits.
    4. 2 weeks later, all hell breaks loose :-)
  • Data that has never been changed since it was entered in the db is initially open (ie. there is only one edit to it: the one that created it). We assume that this has still to be reviewed/corrected. If has never been touched because nobody cares, then we leave it upon until someone does :-).

Releases can be opened or locked

But will these be AutoEdits, VoteEdits or RobotEdits? We all seem to agree that UnlockEdits should be voted upon, but there are different opinions on LockEdits:

  • TarragonAllen proposed that LockEdits should be voted upon because locking a release means that it "is in its final state and shouldn't require any further edits". Also as the proposal is about opening the database, it should not be too easy to close it again.
  • JoeEmenaker proposed that LockEdits should not be entered by editors at all, but a robot should lock all releases that have not changed for an amount of time ore where a certain number of changes had been made to the data within a short amount of time (is this correct? --DonRedman)
  • DonRedman proposed that LockEdits should be AutoEdits because locking a release means that is is in "a state, where further corrections have to be done with care". Only humans could decide when this is the case and such a lock would usually have to be made directly after some far reaching edits.

Additional Locking Schemes

This one was proposed by TarragonAllen:

  • If an artist has subscribers then its releases are locked to non-subscribers.

The idea is to make people feel more responsible for their edits by encouraging people to subscribe to an artist. It will also stop someone who isn't that interested in an artist going and making automatic changes to an artist that has subscribers, who by definition care about the artist and therefore the edits made to the artist - they wouldn't have subscribed otherwise.

This one was proposed by Dupuy:

This isn't really a locking scheme, but rather an idea to get some of the advantages of unlocked releases without requiring new database fields or user interface components in the web pages. The basic idea is that while the AddReleaseEdit is still open for voting, any changes to the release title, attributes, or release events, or track titles or numbers would be AutoEdits (just like ones that only change case/accent marks). Once the AddReleaseEdit edit passes, regular moderation rules would apply.

I considered making the MergeReleasesEdit an AutoEdit while a release is still newly added, but on reflection I don't think that this is a good idea, as merge releases is too difficult to revert if you make a mistake. (MergeReleasesEdit is not an auto-edit even for AutoEditors.)

Note that since AddReleaseEdit by AutoEditors go through immediately as auto-edits, those releases would never be unlocked. While I'm not sure this is ideal, it doesn't seem worth special-casing to make them unlocked for some period, at least not unless it were part of a more complete unlocking implementation.


If a release is locked and there is a pending edit to it. What happens if an UnlockEdit to that release passes?

  1. The edit remains a VotingEdit.
  2. The edit immediately turns into an AutoEdit and gets applied.
  3. Resons for #1:
    • VoteEdits and AutoEdits are a very different thing internally. A VoteEdit could not pass immediately. Rather it would be applied the next time the vote-counting daemon passes it (which might be up to an hour)
  1. Reasons for #2:
    • The voting mechanism tells you "There are already pending changes to that item" so you know what will happen.
    • This way you could enter many edits to an release and also and OpenEdit. If the OpenEdit gets applied first, everything else passes.


There is still some discussion on QualityAndQuantityDiscussion