History talk:Release Locking
Release Locking Discussion
Tentative Summary of the ReleaseLocking Discussion
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 AutoEdit
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:
- The locking tag is set to "open" before the ReleaseLocking rules take effect.
- 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".
- During this period LockEdit
s will be AutoEdit
- 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
- TarragonAllen proposed that LockEdit
s 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 LockEdit
s 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 LockEdit
s should be AutoEdit
s 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:
- Newly added releases are unlocked until the AddReleaseEdit passes.
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 AutoEdit
s (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 AutoEditor
Note that since AddReleaseEdit by AutoEditor
s 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?
- The edit remains a VotingEdit.
- The edit immediately turns into an AutoEdit and gets applied.
- Resons for #1:
- Reasons for #2:
There is still some discussion on QualityAndQuantityDiscussion