CMV: all edits should require votes

It should be pointed out that MB used to have voting for most edits, but this was reduced over time to give more voting focus for destructive edits.

There should be some past discussions about this.

9 Likes

I still believe this is a presentation problem. Just show the voter destructive votes in their queues over non-destructive votes, but don’t just take out non-destructive voting entirely.

I tried searching, but came up short. I would be grateful if you could link a few.

Here are some more reasons why we made most edits automatic:

  • To discourage sockpuppetry. Back when all edits by normal editors required votes, some resorted to voting using sockpuppet accounts to get their edits to pass faster. This still happens occasionally, but the incentive is not as strong as it once was.
  • To disincentivize bad-faith votes (trolls, retaliation and the like). It used to be possible to swoop in with a No vote at the last minute (between the time when an edit’s voting period expires and when it is applied), causing the edit to fail with no chance to challenge the vote and stop the edit from failing. We mitigated this by automatically adding 2 days to the voting period when someone votes No when there is 2 days or less remaining, but it is still possible for a bad-faith voter to succeed if their vote is not countered in that period.
  • To make it easier to make changes. If all edits are left open, it becomes risky for anyone to attempt to make changes to any data that may have mistakes or holes because if something crucial to the original edit is changed, the initial edit may fail. When you factor in the time it takes for edits to apply (right now it’s 1 week; it used to be 2 weeks) this makes it difficult to get anything done.
5 Likes

It was just here in June that I found an entry with entries for 4 different artists of the same name. Plus, the “original intent” artist needed to be merged because the artist was already in the db.
It took a month because I would wait until edits went though before trying to see “what did I miss”.

But could you imagine if I had to first create and populate those new artist entries before I could start moving things.

1 Like

@HibiscusKazeneko thank you for addressing real potential issues with more open edits. I’ll try to address some of the points you made.

This seems like a genuine concern, and I don’t doubt it would increase with more open edits. It seems like there are attempts enroute to mitigate this as well. If sockpuppeting is detected or suspected, that user should be reported.

Could you provide an example for this? Unless I’m mistaking you, this seems like something that wouldn’t happen often.

I think the above two issues could also be mitigated by more procedures to accelerate edits or shorten the wait time. For example, if there is a step in between auto-editor and normal person, or if they’ve shown some experience on the site like x amount of edits & days as a member, maybe their edits only last 3 days instead of 7.

If you suspect a bad-faith vote, report the user and try again. I would also try going public to the forums in this case for support votes.

I’m curious to know the actual ratio of edits that experience bad-faith voting or abuse.

I admit my title is a bit exaggerated and not clear. I don’t believe any edits that create a new entity e.g. artist, release, recording, etc. should require votes.

I did some research, the initial decision on this was mostly discussed on the 2015 MB summit and the changes had been released in November 2015.

This is the release announcement, including some controversial discussion in the comments:

Some background on the meeting:

https://opensource.googleblog.com/2015/12/musicbrainz-gelato-summit-2015.html

AFAIK more autoedits where introduced in later releases, but others would know better. There might be more discussions on e.g. IRC. Maybe some got lost with the old forum.

5 Likes

This is one example. It’s most often a result of two editors making the same or similar edits to an entity in a short span of time. IME, few people think to check the “open edits” page before editing, regardless of privilege level. Before I became an auto-editor, I would routinely have edits of mine fail because an auto-editor would go in and make their own changes without checking to see why that entity was highlighted in yellow.

3 Likes

Ah, so it’s an auto-editor related issue. Maybe an extra warning before committing an edit if that field has an open edit?

Not necessarily. The same can happen with two normal edits, if one passes before the other (because it was entered first or received more votes).

2 Likes

If an edit received more votes, then it seems like a feature that the other edit changing the same field gets denied. I’d rather the correct edit be the one to actually get in.

I’ll reiterate my suggestion that a warning could pop-up if you are trying to edit something that has an open-edit (and maybe even link the related edit!). If the original is incorrect, downvote and continue to make your edit.

There already is such a warning, but it only shows up in the “edit relationships” interface.

If the warning is sufficient, then I fail to see the problem. If the warning is insufficient at achieving it’s intention, then maybe the warning needs to be revamped or other measures need to be considered.

I don’t think conflicting edits have been the main motivation making more edits auto-edits.

Rather this was a response to an ever growing voting queue with not enough voters. That meant (destructive) edits mostly going through without voting and long waiting times for the editors. To put more attention on the destructive edits more edits that can be easily reverted where changed to autoedits.

4 Likes

I agree with @outsidecontext that edits that can be reverted were removed from citing queues in order to make destructive edits more visible and hopefully more reviewed.

But as you mention it:

I made a proposal that if some editor would try to queue a duplicate edit, it would cover this edit action to a yes vote action on original edit (or approve, if the duplicate edit would have been autoedit):

1 Like

Having been an editor for a few years now I definitely understand the move towards making as much as possible auto edits, even though I was against it at first - not only is it better for most editors, but there also just aren’t enough people voting for it to really matter.

Can you explain your reasoning a bit better? Do you come across this problem often? It doesn’t look like you have many subscriptions that you vote on.

2 Likes

No, you were clear in your text.
But, in that specific instance, I had information to add which was not included on the jumbled entry.
Data which would make it clear that each person was a separate person.

I get ModBot notifications all the time. Failed dependency - when my edit was based on data that was changed before my edit went through.

what happened in this edit
https://musicbrainz.org/edit/59430357
was: because I added an IPI and an ISNI at the same time that I added disambiguation and a location, it became an open edit.

5 days into my 7 day wait period, this edit
https://musicbrainz.org/edit/59555027
happened, which caused my edit to fail. The 2nd edit didn’t add the IPI or ISNI, which meant the disambiguation and location were added immediately.

We both added the same ‘area’. We both added the same gender. He added a birth place, I did not. He did not add IPI or ISNI. But we did both add disambiguation.
But my entire edit failed because he added information “first”.

So, it then took another 7 days to get the IPI and ISNI added.

2 Likes

https://musicbrainz.org/edit/58542114

I can’t even tell you what happened here, other than the fact that the artist disappeared (probably merged) while my edit waited. So, it isn’t like I could simply go re-add it. I had to hunt down where he went.

Later artist merge edit applied earlier https://musicbrainz.org/edit/58563800

It happens because destructive edits, like merges or removals, are more reviewed, thus more voted, and may apply faster.

FTR, I found out by clicking Raw edit data for this edit in the sidebar to find the related artist then browsed the artist edit history.

1 Like

In an ideal world destructive edits should not pass unreviewed yet they do en masse
(Since recording merges are the most common type see what it looks like when excluding them)

2 Likes