Difference between revisions of "History:New Voting Proposal"

From MusicBrainz Wiki
m (5 revision(s))
m (removed author(s))
Line 43: Line 43:
 
** The limit is capped to be at most 5–10; this prevents clogging the database with lots of adds (rarely one needs to add so many at a time). Also, making mistakes after many mods is still felt this way.  
 
** The limit is capped to be at most 5–10; this prevents clogging the database with lots of adds (rarely one needs to add so many at a time). Also, making mistakes after many mods is still felt this way.  
 
** The superior cap may go up with votes, but that's delicate, because this could lead to a lot of random voting. We should be very careful to have everyone that votes be interested in voting carefuly. This should therefore activate only after the user has been here for a while (100 successful mods? Perhaps even an autoedit review might be nice; how many new voters do we have per week?).   
 
** The superior cap may go up with votes, but that's delicate, because this could lead to a lot of random voting. We should be very careful to have everyone that votes be interested in voting carefuly. This should therefore activate only after the user has been here for a while (100 successful mods? Perhaps even an autoedit review might be nice; how many new voters do we have per week?).   
--bogdanb  
+
--[[User:bogdanb|bogdanb]]
* By the way, all this is quite useless and even counter-productive (through frustration) if we don't add lots of help for the editors. This includes checking for likely errors and warnings before 'suspect' additions—especially freedb imports—so that new users can do a correct import without trying to read through the whole wiki, with its countless exceptions and obsolete pages.  
+
* By the way, all this is quite useless and even counter-productive (through frustration) if we don't add lots of help for the editors. This includes checking for likely errors and warnings before 'suspect' additions—especially freedb imports—so that new users can do a correct import without trying to read through the whole wiki, with its countless exceptions and obsolete pages.
  
----
 
 
Author: [[User:Gecks|Gecks]]
 
 
[[Category:To Be Reviewed]] [[Category:Proposal]] [[Category:History]]
 
[[Category:To Be Reviewed]] [[Category:Proposal]] [[Category:History]]

Revision as of 12:31, 19 March 2009

Status: This Page is Glorious History!

The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.

Attention.png Status: this proposal had interesting ideas and tried to address a still actual problem. Though, it's apparently not supported, and it's not clear if it will be in the foreseeable future in its present form. A complete redesign of the voting system might indeed be a very good idea, and such a proposal may very well source ideas from here. For now, this document is history, until someone pick on this huge and noble task... -- dmppanda 14:58, 20 February 2008 (UTC)



This is my proposal of a new voting system, that hopefully would sort out some of the issues with the current one.

The Problems With The Current System

  • After 7 days, unseen edits will pass.
  • 'Abstain' is as good as a 'Yes' vote, as undisputed edits will pass after 7 days.
  • There is no motivation to make accurate or complete edits. eg, new album additions are available to tag against straight away, so if a user isn't bothered about the site as a resource for others, they won't be bothered if their album is voted in anyway, as it's there's no consequence for them.
  • There is no consequence of not voting on others edits.

The Proposed System

  • Edits will not pass until they achieve 3 yes votes (Q: what to do when there is a dispute?)
  • As before, edits with 3 no votes will fail.
  • Undisputed edits, or those with no votes at all, will not pass/fail, but remain in the system until the above is satisfied.
  • Reasoning: Now only edits that have been voted for will pass.
  • Users will be permitted a limited number of edits (Q: what should this start at?), which will increase as their number of passed edits increases (Q: what should be the formula?).
  • Reasoning: Since users will naturally want a larger edit queue than they have, it will be in their interest to make their edits correct, and well documented, so they get accepted sooner. Also, they may be motivated to vote on other user's edits, as this will decrease the queue, so their edits have more chance of being acted on. Also, someone who has built up a large edit limit for themselves, will have had a large number of edits accepted, so they will be proven to be a 'quality' submitter, and their increased quantity open of edits will take less time to go through the system.

Problems

  • The queue will increase, as everything needs to be voted on, and nothing will pass automatically (apart from what is currently deemed an 'autoedit' - I see no reason to change this behavior.
  • Solution: Tweaking the number of permitted edits per user, and the way in which this number increases, should hopefully find a sweet spot.
  • Restricting users in this way is a bit negative, compared to our current 'anything goes' system. We don't want Musicbrainz to be a source of frustration!

Discussion

  • We need to be smart about the mods. For example, if someone (say, a newbie) enters a mod, then tries to fix it, the system mustn't prevent him from doing that fix, even if it involves a large number of mods (which could be ~100, I saw examples). --bogdanb
  • I suggest that the most important problem is with adding albums, not general mods (there are lots of general mods, but they tend to be easier to check, more often commented, and if we get rid of bad insertions the fixes will get fewer too).
    • So, new users should be allowed to have only two or three album additions in effect. Rationale: they have to be tested to see if they know the rules and respect them.
    • Each time an 'album add' passes, the limit gets increased by one, each time it fails, the limit is decreased. Rationale: we need to discourage undisciplined users (who would try to add trash to fix their tracks) but quickly attract disciplined ones (they will probably read the rules, so their adds go through quickly, and will probably add slowly at first anyway, to get a feel for the process). The limit is decreased to quickly stop those who got it right by chance.
    • The limit is capped to be at least 1; we might allow the limit to go to 0 for a while (a week or so) as a kind of 'punishment/ban'—I am against this, I'm sure it will annoy people who don't mean bad.
    • The limit is capped to be at most 5–10; this prevents clogging the database with lots of adds (rarely one needs to add so many at a time). Also, making mistakes after many mods is still felt this way.
    • The superior cap may go up with votes, but that's delicate, because this could lead to a lot of random voting. We should be very careful to have everyone that votes be interested in voting carefuly. This should therefore activate only after the user has been here for a while (100 successful mods? Perhaps even an autoedit review might be nice; how many new voters do we have per week?).

--bogdanb

  • By the way, all this is quite useless and even counter-productive (through frustration) if we don't add lots of help for the editors. This includes checking for likely errors and warnings before 'suspect' additions—especially freedb imports—so that new users can do a correct import without trying to read through the whole wiki, with its countless exceptions and obsolete pages.