CMV: all edits should require votes

I think it is very frustrating to see edits automatically applied that are wrong info, and then have to go in and undo them.

Besides the initial release, I think all edits should require votes. What are the downsides? Having to wait 7 days for edits? If it’s that urgent, and people aren’t voting, then go out and advertise to get some people or an auto-editor to vote.

Edit: to clarify:

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.

2 Likes

More voting would be good, but there are way more edits than votes (I’m guilty as well, I barely spend time to vote, but also very little to edit these days). So if everything has to be voted on, many important things will get missed by the few voters. Limiting the voting requirement to destructive edits means that there is a higher chance that those are spotted and looked at. A changed capitalisation can easily be reverted later.

4 Likes

If it’s an issue of visibility, then maybe the ability to sort your edit queue by destructive edits would fix that.

1 Like

I cannot be online watching for edits 24h/24 so I browse past edits of my collection, and usually autoedits show enough info to be reverted.

I think only destructive edits are open.
Current situation may already be good in this regard… :thinking:

By the way, what do you mean by CMV?

2 Likes

Change My View

1 Like

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