Voting/Auto-editor Request Thread

Tags: #<Tag:0x00007f756fc3cd50> #<Tag:0x00007f756fc3cbc0> #<Tag:0x00007f756fc3ca30>

Is this how we are going to deal with duplicates now? Deleting them instead of merging to keep the editing history nice and pretty?

Another argument was that the MBID hasn’t “lived” long enough. As it stands that’s no longer true.


The editor created an entity then realised their mistake 4 minutes later and we should allow them to simply revert the way they see fit.
Indeed this entity had no use by anyone else.
And merging it will simply add its bogus edit history to a better entity that really doesn’t need that, I guess. :slightly_smiling_face:

1 Like

But witch release got the more bogus edit history? I just realize the original one was added with a link for another release in edit note (see edit #66460260) for example. So the initial mail-order relationship wasn’t right. While we have the right information IMO in the editing history for the one people would like to remove :-/


Have we added any notes to the bogus edits flagging them as such?

:poop: This is a bogus edit, please do not reference it! :poop:


As an editor who has successfully processed a “release delete” I firmly believe that redundant edit history or expedience should never be a reason to delete a release instead of processing a merge. I have had to merge a good number of releases I created only to find their earlier duplicate sometime later. Why I created those releases is a matter of debate, search engine “anomalies”, different title naming with lack of aliases, title or artist name change going from old vinyl to the CD re-release, marketing name changes, lack of morning coffee, late night editing, and the list goes on. The release I deleted was reported by Google the next day; I hung my head in shame knowing my totally bad data was out there for a while. We learn things from the edit history; it helps us to better understand why an edit was done. I suggest it be fixed if needed and then merged.


These two NO votes to relationships I have linked have puzzled me. They seem to be against the principle of linking related data in a database because a human can already read something on a page.

My question here:

Edits here:

Obviously, give me a sensible reply and I’ll go and remove my No votes. :slight_smile: Currently my believe is these edits both remove relevant relationships.

1 Like

for me Karlsruhe is just wrong. If a concert would take place at Munich Airport, Munich also would be the wrong place. Because the airport is located in the area of Freising. While I get your point, Karlsruhe is still in the release group and release, so it’s easy to find. From a geographer’s standpoint getting the link to the right area is an important thing :wink:

1 Like

I am sorry I picked the wrong example due to my lack of knowledge of Germany geography.

I have now totally stepped away from all of the Gabriel and recording locations it as it has been made clear to me that I know nothing about databases.

I’ve cleaned up a few of the N/A artists’ credits.

A bunch of DJ-mix RGs will have the compilation type removed. To my interpretation of the style guide and at least one other editor I can’t see why that should be done.

1 Like

Just a note to mention that a discussion on Chopin’s name in MB has broadened, as it seemed useful to clarify the guidelines to name composers in MB. It’s posted in the Classical section, as we have many issues naming classical composers (Chopin, Liszt, Tchaikovsky, …). It may also be of interest for other composers.

There is a vote opened to clarify guideline on composer naming. I thought that a note here would help to ensure that all concerned could vote or provide comments.

1 Like

All the credits were entered as aliases of [unknown]. I’ve fixed that.

Update: More edits have been added. :hot_face:


Can someone take a look at the edits on this release and make sure everything was done right / in a logical order? A space was missing in the release title, some artist credits were misspelled or in track titles instead of artist credits, and it looks like when it was first entered they had an auto-translator on, which was fixed in the tracklist but not in the individual release titles.

If there is a bored Auto-Editor around with a mass voting script it would be helpful to bulk approve these.

( Works written by Ozric Tentacles )
( Works written by Ed Wynne for the Ozrics )

I have cleaned up a mistake made on all the Ozric Tentacles Works. All but one of their tracks is just music without words. So they are all Work Type [blank] and Lyrics [No Lyrics].

Once these are all kicked through I can check for any that got missed.

Thanks :+1:

Korean singles marketed as OST. What should their primary type be: single, other or maybe something entirely new?

1 Like

A user has taken the “sour grapes” approach to voting.
For the most part, they are voting ‘no’ on my edits (out of spite for my no votes on theirs). If it was just that, I would point you to my open edit page. But they have also taken to voting the opposite as I have voted on a few edits.

Regardless of which, some of the edits are going to close in the next few hours, so I was hoping that anyone that looks at the vote history will start with those first, as they are the priority.

I assume you have hit the “Report this user for bad behaviour” link in that profile.

1 Like

Yes, I did. But at the time, there was 4 hours remaining on some of those edits.
I thought it might be more expedient to round up some votes.


Could I get some votes on this please?
[has been approved ]
Keen to correctly tag some files, thank you!!

edit: SO speedy, thank you @chaban!

Redundant info which is already stored in relationships is being removed from titles but there is an opposing view arguing that it’s worth keeping due to the UI.