History talk:Release Locking

From MusicBrainz Wiki
Revision as of 19:24, 23 July 2005 by WikiMigrationBot (talk) ((Imported from MoinMoin))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Discussion of the AlbumLocking Proposal

as presented in QualityAndQuantity

Tentative Summary of the Discussion

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

Albums are either locked or open

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

But which albums should be opened initially?

When AlbumLocking is implemented we have to decide, which albums 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):

  • Albums belonging to non-subscribed artists are unlocked.
  • With albums that have subscribers we just ask the subscribers to lock the albums they deem correct:
    1. The locking tag is set to "open" before the AlbumLocking 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 touced because nobody cares, then we leave it upon until someone does :-).

Albums 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 an album means that it "is in it's final state and shouldn't require any furtheredits". 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 albums 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 an album 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 albums 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:

  • Newly added albums are unlocked until the AddAlbum passes.

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

I considered making Merge Albums an auto-edit while an album is still newly added, but on reflection I don't think that this is a good idea, as merge albums is too difficult to revert if you make a mistake. (MergeAlbums is not an auto-edit even for auto-moderators.)

Note that since AddAlbums by AutoModerators go through immediately as auto-edits, those albums 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 impelementation.

Synchronization

If an album is locked and there is a pending edit to it. What happens if an UnlockEdit to that album 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 album and also and OpenEdit. If the OpenEdit gets applied first, everything else passes.


Discussion

There is still some discussion on QualityAndQuantityDiscussion


Alert.png The Markup on This Page Needs Fixing 

This wiki page has been ported by the WikiMigrationBot, and this link to the WikiMigrationBotReport flags that this page contains wiki markup that needs fixing.

WikiNameInTitles on these lines:

  • 0 = Discussion of the AlbumLocking Proposal =
  • 1 = as presented in QualityAndQuantity =