Requests for Votes Thread

Instrument performers were added in an awkward way. That mistake has been corrected but the old relationships still need to be removed. Let’s speed that up.

1 Like

Hello all you nice AE’s and brainy MB people who have a good understanding of the guidelines.

What is your opinion on scrappy data? Old 2007 era entries in the database? Should they be deleted? If data can’t be trusted, and no references available, should it be removed?

1 Like

Hello, I need some votes on edits to fix a mess I caused. I mistakently resubmitted a release I already had earlier (in my defence, it’s a long and complex series), so I was to delete my new submission, and make a few minor corrections to the original one (which caused me to miss my earlier submission).

https://musicbrainz.org/edit/67122455
https://musicbrainz.org/release/b2550e53-7c0e-4e09-936e-247f770da632/open_edits

Thanks in advance!

1 Like

isn’t that done? I checked it looks good

Yes, thanks. The edits to Louis Armstrong Plays W.C. Handy have been voted through and I have added disambiguation comments to the new recordings.

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.

3 Likes

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 :-/

3 Likes

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:

2 Likes

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.

10 Likes

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:
https://musicbrainz.org/edit/67153245
https://musicbrainz.org/edit/67158069

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:

2 Likes

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. https://musicbrainz.org/release/40c860d4-8fb4-431c-a87c-3cd1f75b5d1e/edits

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