We are going to be making some big changes to the Discogs moderation system. A new, more open, graduated voting system will be put in place, with votes that range from “Complete And Correct” to “Entirely Incorrect”, in five stages. Then votes will be averaged and displayed on the release pages. Releases and edits that are rated poor quality will be removed from the database or reverted. Releases and updates with no votes will be marked as such, in the same way as unmoderated releases are marked today. The comments and general voting layout will remain similar to what we have now, with the added voting choices. Database functions will be affected in different ways by this new system, see the list below for details. And the ability to vote will be opened up to a much greater section of the Discogs user base; this will replace the current moderation based system. [b]These changes will go live on March 10, 2008[/b].[b]Why Are We Making These Changes?[/b] As Discogs has grown, the submission system and user requirements have created ever more detailed and complicated submissions. With over 10,000 active submitters and less than 500 moderators, the task of moderating has become harder and more involved than before. By moving the voting to a greater percentage of the Discogs user base, and enabling a graduated voting system, we will give more people, especially those who own the release, the ability to register their opinion on the quality of the data entered into the site. [b]Moderators and Editors[/b] The progression from a moderation based system to this new system is not an indication that any of the mods or eds themselves have failed or were not making good decisions regarding the data – on the contrary, this group of dedicated users have made the site what it is today. However, the system was having problems scaling to the size of the site. The mods and eds contribution since 2001 has obviously been huge and extremely positive, and it is hoped that the individuals involved will remain as active voters, continue to help and look after submitters and the data as before, and continue to be involved in improving the site overall. [b]The Evolution of Discogs[/b] The Discogs submission and moderation system has gone through many big changes over the years in order to handle the growing user base and their submissions. This coming change is another step in that evolution. Here’s some history about how things have changed:
2000-2001 – All submissions were entered into a loosely structured form which did not support credits or remix credits. Then I would use a more complicated “editing form” to copy/paste remixers into the appropriate fields and fix any typos and capitalization errors.
2001 – I gave about 10 users access to this form so they could approve submissions as well. Since there was so much editing involved in approving a submission this group became known as the Editors.
2001 – I rewrote the submission form so that the it could accept data in the same format it would need to be in when approved. All I had to do was switch a flag from Pending to Accepted to let the submission through. Then about 50 of the top contributors were given access to the approval form, featuring Yes/No/Skip buttons. This was the beginning of the Moderators group. Then the Editors were given access to approve merge and rename requests since Moderators were now handling release approvals.
2002 – More users were made moderators, we tried out various selection methods.
2004 – I rewrote the whole system for V2. The major change here was that the underlying release data structure was much more flexible, immediately allowing multiple artists and labels per release, multiple artists per track, multiple credits per track, and release-wide credits. ANV and the upcoming label improvements would not be possible without V2. It was also possible now to leave comments on submissions, instead of the Yes/No limitations of before.
2004 – The history functionality was put in place, allowing everyone to see the previous updates on submissions.
2005 – Pending submissions were made viewable directly in the artist and label pages, highlighted in yellow. All users were allowed to leave comments on submissions.
2006 – AJAX-based release submission form, copy to draft function, editing releases while they are pending.[b]Changes to the Current Update Functions[/b] Add Release – The release will go into the database similar to the “unmoderated” status of today. Users will be allowed to vote on the quality. If the quality rating is too low, the release will be removed from the database. In order to edit a newly submitted release, the user will first have to cast a vote on it, then edit it.
Edit Release – This will affect the release right away. Users will then be able to vote on the quality of the change. If the quality rating is too low, the release will be reverted to the last known good edit.
Edit Artist and Edit Label – will be handled in the same way as Edit Release.
Merge Releases – We will leave this operation out for a while but it will come back in a new form, possibly allowing members who have it in their collection to vote on the merge.
Merge Artist, Merge Label, Convert Artist to ANV – will be disabled. These operations can cause problems because they can’t be undone, and we’ve found that they typically only affect 2 or 3 releases. So under this new system the individual releases should be edited instead.
Rename Artist and Rename Label – These functions will be disabled as again they cause problems because they can’t be undone. Also, we have moved to a much more definite “as on release” data entry method, especially since the Artist Name Variation function came online. So updates should be done on a release-by-release basis now, with reference to what is printed on the release itself.
Images – all image update functions will be handled by a new Image Update form. The new form will allow you to make changes immediately, set images in the correct order, etc.[b]Voting[/b] Users will be allowed to vote once they meet certain undisclosed requirements. Users will be free to apply votes to any release or edit at any time, no matter the number of votes that have been cast. These votes will be tallied and allow other users to gauge the validity of the data, and in extreme cases remove or revert the data. Users will see the average vote on their submissions in their profile. Users who receive too many poor votes that show they are unable to reach a reasonable standard will be limited or even blocked from interacting with the database. Voters will be checked in several ways for any abuse of the system, and blocked from voting if necessary. Submitters will not be allowed to vote on their own submissions.
– Complete and Correct
– Needs Minor Changes
– Needs Major Changes
– Entirely Incorrect
The votes will be tallied and displayed on release pages.[b]Viewing the Information[/b] New release submissions will be highlighted in yellow, the same as “unmoderated” releases are displayed today. This can be considered as “Needs Review”. Edits will now be viewable as soon as they are applied, and the release marked as “Needs Review” in a different way from a new release. As soon as a vote is cast the “Needs Review” flag will be removed and voting can continue indefinitely. The votes will be added up and averaged as they come in. The average vote will be displayed on the release page. Users will be encouraged to improve releases that “Need Minor Changes” and “Need Major Changes”.
[b]UPDATE 3-Mar-08[/b] – We’ve just decided on a few design changes for the voting interface, and that requires a little more development time. So I’m rescheduling this update for 10-Mar-08, next Monday.