Blocking Editors Reported for Bad Behavior

Because of the recent rash of bogus edits and “No” votes cast by the editor when @HibiscusKazeneko tried to clean them up (see message Voting/Auto-editor Request Thread), I have entered Ticket MBS-10323 with a suggestion to help prevent the continued problems after an editor has been reported.

This proposal is that an editor will be immediately blocked from entering any new edits or voting if they are reported for bad behavior by two or more autoeditors. The thinking is to stop the continued abuse and damage to the MusicBrainz database quickly, until the reports can be investigated by the appropriate MusicBrainz staff member.

In order to try to avoid this from being abused, the proposal requires that an editor be reported by two or more autoeditors before being blocked. The actual required number is open to debate (perhaps it should be three, similar to voting), but should definitely be more than one. Editors can still be reported by anyone, but would not necessarily be immediately blocked.

EDIT: Perhaps they should also be blocked from adding any edit notes as well.


Agreed! I attached this to one of @HK’s edits.>> Maybe MB could add a second classification to the Report Editor selection. Something like “Report Editor for destructive edit”. Pressing that button could bring a complete stop to the “editor of interests” ability to make any further edits until that editor was promptly investigated. It [Report Editor for destructive edit] could only be accessed by Auto-eds and above.

EDIT: Obviously this type of reporting should ONLY be used for serious infractions and the reporting editor must substantiate. While I realize there is additional safety by having two or more editors who concur, by the time additional eds have signed on, even more damage might be done. Could a rogue auto ed pick on someone? Sure, but look at the price they would pay after peer review. If an auto ed or “above” is not certain of the reportable infraction they can still choose to use the standard “Report Editor”.


I would say this ought to be a separate thing. While I could imagine there would be circumstances where a user should be blocked from posting edit notes (posting racist or otherwise offensive comments, for example), I’m not aware of any incidents that so clearly merited such a draconian response. Garden-variety whining about being persecuted by musicbrainz and the like – it’s not really all that harmful to musicbrainz – and it’s probably not good to go overboard on anything that could be called “censorship”.


I agree, and in addition edit notes are probably the best way for the editor in question to explain themselves, so blocking that ability would be counterproductive.


Good point.

Either that or a way for the reported editor to dig themselves into an even deeper hole. The one that prompted my proposal seems to be taking the opportunity to do exactly that. :wink:


The ideal outcome is that a damaging editor gets educated and starts making (lots and lots) of good edits.

Ways this can be achieved need to be developed.

In part because the “block fence” is not very wide.
And can be circumvented.
Even WP who seems to have most IP addresses in the world blocked still has people finding ways in to do damage.
It seems like entering into an arms race.

But it might be the best available response to allow blocking by multiple autoeditors.


Relatedly, is there a flag for an editor’s account to have all edits go to vote (i.e. no auto-edits)?

Could go a step further and have a flag so that the editor’s edits won’t go through unless someone votes yes.


This would be the key to me: If an editor is reported, then their auto-edits should change to being vote-able. At least to slow down the damage until someone can get in to look. Slow the edits into the 7 day queue when controversy kicks off.

I’ve had a couple of run ins with destructive editors like this. It is demoralising as it can take hours \ days to correct the damage that someone like this has done. Damage that could easily have been halted. And even when trying to repair that damage I’ve been lectured at for saying the wrong thing.

It can be horrific when one spends hours on improving the data here at MB and then events like this kick off and there is no system to slow the damage. Just the assumption that “someone will clean it up

Don’t block their ability to enter edit notes. The rogue editor should always be allowed to talk and respond to accusations, but their ability to damage should be slowed into a “needs moderation” queue.


The gist of this thread is that something needs to be done now. Several methods to address the situation have merit. Can someone in the hierarchy step in and propose/do something now? As @IvanDobsky and others have stated, it is demoralizing to see your time and effort wasted by a few that are PURPOSEFULLY/REPEDITIVELY malicious. Creating a means for the Auto-Eds to somehow immediately stop the alleged offender and at least have the ability to put them into a seven day queue really makes sense.

1 Like

There are many many occasions like this where an editor just plain refuses to follow the guidelines. There are loads of threads like this already in the forum. Some of those occasions the editor was stopped, but the damage never cleared up.

The more that current editors attempt to steer these confused editors onto the correct line, the more entrenched the argument becomes. Meanwhile hundreds if not thousands of auto-edits go into place. Especially if it is the weekend.

This example editor is adding legit releases alongside the fantasy bootlegs but the number of errors and just plain weirdness in their edit history shows that they need some help in a calm way. The more MB editors try and wade in and solve the issues, the more confused it gets. The more angry it all is.

There needs to be a welcoming team. A re-education team. Someone who has people skills who can take these kinds of dramas aside into a quieter area and stop the damage.


In fact I tend to agree to put on things little more automatised like in Discourse because it is very harsh indeed, automatised stuff, it is very bothersome like in stackoverflow where you cannot do anything but let’s be realistic, we can never manage these properly ourselves, there is no time and there will be so many loopholes anyway, I mean we cannot spot more than 5% bad edits.

Something must be happening out of sight. The user now has two “anonymous users” watching their edits and the new edits have stopped. Would be nice to get some feed back here for those who tried to fight the dramas.


There are times when I wish the Secret Cigar Lounge for Cabalist Editors feature of Discourse was enabled.
Then we could gather in the smokey darkness and learn of the Hidden Workings. smoke-filled-room-02

1 Like

Clearly nothing was happening out of sight. I see he’s back and no change of attitude.


Could non-stable Editor’s have their edits sandboxed?


We had some discussion somewhat related to this during last night’s weekly meeting. You can read the discussion yourselves here:

One issue with the proposed “solution” in the OP is that MusicBrainz currently does not track at all whether editors have been reported or not. The report is a quite simple mail form that just sends an e‐mail to the list of MusicBrainz account administrators.

That’s not to say this couldn’t change, but it’d be more convoluted than just adding an if‐clause.



Perhaps this could be set when an editor is reported by an autoeditor?


After reading that discussion it is a little surprising how trusting this website it. Setting that flag at least gives the site admins time to think. Even if it is still a manual action done by the admins who are reading the report emails.

Ideally let it be set if maybe three reports appear. That avoids the petty arguments? That at least gives other users time to slow down any chaos that starts. Sending the chaos to votes then allows the users to really help the admins.


Except if I understood @Freso correctly, the system doesn’t currently have any mechanism available to track or count the number of times an editor has been reported. If and when that functionality is available, then this becomes a viable option (along with possibly blocking the reported editor from voting).

I prefer to have the reports include at least one by an autoeditor before any automated actions are taken, in order to prevent the use of sock puppets to abuse the functionality.


Small up to find out where are the discussion since last summer?
Dealing with a squad of sockpuppet actually, it reminded me this proposal of @rdswift :slight_smile: