User:LordSputnik/BookBrainz Voting Vote

From MusicBrainz Wiki

This page is for voting whether to include voting in BookBrainz or not.

Why not vote?

Voting is a good system where there are many voters voting on few issues. In these cases, voters are able to properly consider the issues, and vote carefully. Since many votes are cast, the outcome is fair and democratic. Unfortunately, the situation in MusicBrainz is the exact opposite of this - there are few voters, and many edits to vote on. Even with the edit system improvements in BookBrainz, voting will still likely be an activity performed by relatively few users. So, an alternative might be beneficial.

The Four Types of Edits

According to Rob, there are four categories of edits made to MusicBrainz:

  • Edits that makes things better (perfect or not)
  • Edits makes things different (but neither are better)
  • Edits that contain some correct things and some incorrect things
  • Edits that are outright wrong (existing data is better)

Category #1 is likely to cover the vast majority of edits, which do not need voting on - they are either made by experienced users who know what they're doing, and frequently edit the database, or by bots, who (should) behave in a fixed, predictable way. I expect that #1 is also the category which receives most votes (though this is just a guesstimate).

BookBrainz Edit System

BES is based very closely on NES (read: NES + relationship support). Editors create edits, which are collections of changes, called revisions. Each revision represents changes to a single entity or relationship. Editors assign newly created revisions to one of their open edits. When they've collected a series of related revisions, they can close the edit. At this point, either the voting system or alternative comes into play to decide what happens to the closed edit.

Alternative #1

Editors have the option to "approve" of the latest/master revision of an entity or relationship. As soon as an editor closes an edit, it is applied to the entity or relationship, and made the new master revision. All editors who approved of the previous master revision are notified that the entity has been modified, and can comment on the new edit. If these editors don't like the edit, they can either ask the author to revert the edit, or create new edits to fix problems. Note, that since most edits make things better, there aren't likely to be many cases where a revert is required.

Conflict Resolution

If editors reach an impasse, then editors should attempt to politely resolve the problem using the editing guidelines, and hopefully a clear path forward will be found. If this is not the case, one of the editors should contact a BB moderator, who will come to the edit, and made a decision on how the conflict should be resolved. If one user is clearly being destructive, the moderator will explain why their behaviour isn't acceptable, and outline potential consequences if the destructive behaviour continues to threaten the integrity of the database.

Benefits

This alternative has several key benefits:

  • Editors are only expected to review edits they have previously approved
  • It's easier for an editor to monitor changes to entities they're really interested in
  • Editors are encouraged to be polite to each other, and collaborate, since there is no way to "veto" edits
  • Editors no longer receive horrifying "Someone voted no on your edit" emails!

Alternative #2

No voting at all.

Wikipedia has it right -- let people make edits as much as they want as long as you:

  1. Allow any/every change to be easily reverted
  2. Give people a clear view who who changed what/when

Peer review by voting sucks -- if you need to have a complicated diagram to explain how voting works, you're doing it wrong:

  https://musicbrainz.org/doc/Introduction_to_Voting

(And yes, I am the one who originally came up with the existing system. Now I wish I'd gone wiki, not voting)

(added by ruaok)

Votes

Existing MusicBrainz Voting System

- pankkake. Reverting is Wikipedia nonsense (the bureaucratic nightmare that loses contributors every year and has admins "owning" articles all over the place). It also applies easily to text, but not to complex entities. A system without votes and subscriptions would count me out as a contributor. I would also add that the presentation of each system is heavily biased and does not reflect the reality.

  • Does it really lose more contributors than having a huge tracklist edit open and seeing it fail dependency because of some other change, making you start all over again? --Reosarevok (talk) 19:34, 7 February 2015 (UTC)

Alternative #1

- LordSputnik

- Sc-content (talk) 08:08, 4 February 2015 (UTC)

Alternative #2

--Reosarevok (talk) 19:33, 7 February 2015 (UTC) The current MB system is confusing to a degree that it's basically impossible for a new editor to know whether his edit will apply instantly or not and whether it will show instantly or not, and hard for anyone, new or not, to know whether an edit will cause another to fail or not. Its complexity also makes it more likely to have bugs. Not only I think we should have an automatic edit option with revert in BB, but I'm pretty sure it's towards what MB proper should move too.

Something Else (please add above)

- kuno