A similiar proposal has be implemented by DataQuality, which was inspired by QualityAndQuantity. This page will be kept for historical purposes.

A Case for a More Open and Controlled System:

More Quality AND More Quantity

The basic idea of this proposal is that each release be given a status of either 'open' or 'locked'. Initially, all releases should be 'open'. This means that any edits to release name, track names, track orders, release info, and attributes would be automatic. This would allow bad data to be easily corrected. However, there is a danger of good data being corrupted, and this is where 'locking' comes in. Any user can lock any release if they think that it is reasonably correct. When a release is locked any changes made to it would have to be voted on (as under the current system).

This has several positive effects. I would reduce the overall number of votes required (due to more automatic edits). Those edits that do need to be voted on are more likely to be meaningful: voters no longer need to waste their time approving thousands of edits that are obviously correct. On the other hand, good data is adequately protected from vandalism and inexperienced moderators.

Edits that are affected:

A: automatically applied V: voted on

Change Track Artist (A if release is open, V if it is locked) 
 

Convert to Multiple Artist (A if release is open, V if it is locked) 
 

Convert to Single Artist (A if release is open, V if it is locked) 
 

Edit Release Atributes (A if release is open, V if it is locked) 
 

Edit Release Name (A if release is open, V if it is locked) 
 

Edit Release Event (A if release is open, V if it is locked) 
 

Edit Track Name (A if release is open, V if it is locked) 
 

Edit Track Number (A if release is open, V if it is locked) 
 

(All these edits are currently V, except for case changes.)

The only new edits would be:

Lock Release (Always A) (or V with 1-vote requirement) 
 

Unlock Release (Always V) (This edit would probably hardly ever be used.) 
 

All other edits would be handled as they are handled now.

For automods all above edits would be A.

The Transition:

Essentially under the current system every single release in the database is locked. Various ways of unlocking parts of the database have been discussed. I would suggest the following procedure:

1. Unlock (or flag 'to be unlocked') all releases belonging to artist who have no subscribers. 
 

2. Mark all other releases as 'to be unlocked' and give subscribers 1 week to lock those releases they deem correct. 
 

3. After a week unlock all releases still flagged 'to be unlocked'. 
 

4. All releases added to the database are initially not locked. 
 

Done!

DanielBumke

---

---

Old Proposal

The Model:

This proposal consists of two parts. Firstly, under the new system almost all edits would be automatic for all users. Exceptions would include delete, add, move, and merge operations (merge and delete are currently never automatic). This would allow wrong data to be corrected easily without any voting being required. The obvious downside is that it would be equally easy to vandalise or inadvertently change correct data due to inexperience, since edits are no longer peer-reviewed. This is where the second part of this proposal comes in: every piece of data would have a Boolean flag attached, signifying the status of the data: ‘open’ or ‘locked’. All data would originally be ‘open’ (i.e. all edits would be possible as described above). Changing data from ‘open’ to ‘locked’ would be an automatic edit (thus any user can ‘lock’ data that they think is correct). Once locked, all edits undertaken on this data would have to be voted on as under the current system (including those edits that are currently always automatic, such as changing the case of a title). Changing data from ‘locked’ to ‘open’ should also be a non-automatic edit. This would ideally make the entire database freely editable, with those parts that are deemed to be correct gradually becoming ‘locked’.

The Changes:

When data is ‘open’, editing it would be much easier than under the current system. With the exception of merge, move, add, and delete operations all edits would be automatic. As a result bad data could easily be improved. When data is ‘closed’, changing it would be slightly more difficult than under the current system. Traditional voting procedures would be used for all edits (including minor changes in case/style). As a result any changes to good data would be peer reviewed.

Edit Type                  Old System               Automods    ‘Open’      ‘Locked’     
 

Add Release                V                          A           V           -            
 

Add Artist                 V                          A           V           -            
 

Add Artist Alias           V                          A           V           -            
 

Add TRMs                   A                          A           A           -            
 

Add Track                  V                          A           V           -            
 

Change Track Artist        V                          A           A           V            
 

Convert to Multiple Artist V                          A           A           V            
 

Convert to Single Artist   V                          A           A           V            
 

Edit Release Attributes    V (A if no attr. present)  A           A           V            
 

Edit Release Name          V (A if case change)       A           A           V            
 

Edit Release Event         V (A if no data present)   A           A           V            
 

Edit Artist Alias          V (A if case change)       A           A           V            
 

Edit Artist Name           V (A if case change)       A           A           V            
 

Edit Artist Sortname       V (A if case change)       A           A           V            
 

Edit Track Name            V (A if case change)       A           A           V            
 

Edit Track Number          V                          A           A           V            
 

Merge Releases             V                          V           V           V            
 

Merge Releases (VA)        V                          V           V           V            
 

Merge Artists              V                          V           V           V            
 

Move Release               V                          A           V           V            
 

Move Disc ID               V                          A           V           V            
 

Remove Release             V                          V           V           V            
 

Remove Releases            V                          V           V           V            
 

Remove Artist              V                          V           V           V            
 

Remove Artist Alias        V                          V           V           V            
 

Remove Disc ID             V                          V           V           V            
 

Remove TRM ID              V                          V           V           V            
 

Remove Track               V                          V           V           V            
 

Lock Track                 -                          A           A           -            
 

Lock Release               -                          A           A           -            
 

Lock Artist Name           -                          A           A           -            
 

Lock Artist Alias          -                          A           A           -            
 

Lock Attributes            -                          A           A           -            
 

Lock Release Event         -                          A           A           -            
 

Unlock Track               -                          A           -           V            
 

Unlock Release             -                          A           -           V            
 

Unlock Artist Name         -                          A           -           V            
 

Unlock Artist Alias        -                          A           -           V            
 

Unlock Attributes          -                          A           -           V            
 

Unlock Release Event       -                          A           -           V            
 

The Role of Automatic Moderators:

Automatic moderators would keep their current privileges, thus allowing them to edit ‘locked’ data automatically. They would also be allowed to ‘unlock’ data automatically.

The Benefits:

In general much less voting would be required, and voting will become more meaningful. Those parts of the database that are in bad shape could be easily improved by anyone, without requiring a lengthy voting process. On the other hand correct data is protected. If someone deems data to be correct they can lock it, and thus ensure that it remains correct. Voters will only have to deal with ‘real’ issues, and will be spared the laborious task of approving thousands of obviously correct edits. Overall, ‘bad’ data is less protected and can easily be corrected, while ‘good’ data is more protected (i.e. case changes are not allowed) and can only be altered with peer approval.

The Downsides:

The major difficulty with this model is the transition from the current system. Throwing open the entire database and then letting it gradually get locked would not be sensible, because large parts of the data are already ‘good’. A system of partial ‘unlocking’ along the lines of subscriptions to artist might be sensible. Data about artist that have no users subscribed to them could be thrown ‘open’, while those artists that do have subscribers remain ‘locked’. New data entered into the database should be ‘open’ until someone ‘locks’ it. In this way a gradual transition may be feasible. I am no expert in database programming, and I have very limited understanding of the structure of the MusicBrainz database. Changes as to whether an edit is automatically accepted or not have been made in the past, and so I hope that there isn’t too much difficulty in implementing this. The main challenge would probably be to attach a Boolean value to every track, release, artist name/sortname, etc…. I have no idea whether such a change is feasible, and how difficult it would be to implement. However, I do believe that the transition would be well worth any effort put into it, not only in terms of fewer votes per edit (and thus saved time), but also because the database would be more accessible, correct, and complete as a result.

---

CategoryProposal CategoryHistory