Handling name of transgender artist

I don’t know if you noticed but not everyone agrees it’s dangerous (ignorance? idk). Unwanted yes, which is why we need to hide it, but not erase it (in my opinion, unless you can change it respectfully), in which case my solution would be alright once we figure out a way to hide it. [edit: I said erase it accidentally. I insist, we shouldn’t erase it.]

Either way I consider deadnaming about as dangerous as outing yourself as trans in public, which Patricia did, and this is documented in her YouTube channel.

If the artist didn’t want the info to be public and never made it public, or tried to erase the traces left on the internet, then it’s clear, we shouldn’t store their old name, in order to protect not artist intent, but privacy.

This is not the case here though.

1 Like

Except it’s harmful in other ways, like mentally and emotionally, and the fact that someone might be willing to discuss their deadname on their own terms doesn’t mean others can go around spreading it about willy-nilly. :confused:

4 Likes

We’re clear on that.

So we should go case-by-case then? Patricia has not spoken about this. (Has anyone tried to contact her?)

Anyways, we’re not spreading it. We’re archiving and indexing it. I do agree that it should be hidden in the UI behind some element. But I don’t believe in erasing it from the database (is that what you want? please elaborate) if the artist was public about the topic, unless they declare otherwise.

I do not believe in storing such info if it’s private and the artist never declared it in public, but in this case she’s spoken publicly about it, so what do we do? I say we store it, but declare the old name as not current somehow so that tagging software uses the actual name.

3 Likes

Yay, we’re totally on the same page :raised_hands:

This is about how it impacts the artist - and it may totally not, in which case the db can currently handle it. Adding a new release with the updated info and updating the release group and the works/recording, and leaving the old release, is a clear way of showing the shift and having both old/new data. I don’t see how doing the same + adding some kind of new ‘withdrawn’ flag is quicker, but I might be missing something (e.g. setting an alias with a date range would be nice - but honestly, anything requiring new code usually takes years/never).

The question is, if the artist doesn’t wish to be deadnamed, or doesn’t want to be outed, can we respect that on a case-by-case basis.

Is this a correct assessment @jonny7 ?

3 Likes

THE KIWI AGREES.

Here it gets weird. I don’t mind the old name being erased from the database if it’s for the artist’s privacy (not even talking about her being trans. object blue wants to be known under her stage name only and MusicBrainz followed through). Patricia is too far gone for that, though, in the sense that she spent more than a year (is that right?) working using her old name and she had already become somewhat known. If she really wanted to, though, should we go through and erase it? Not everyone here agrees. I do. But as she’s stayed quiet (again, has anybody consulted her?), I say we default to keeping it as a search hint at the very least.

After all, such is the price for artists who want to be known by their public name. Their history gets recorded and attributed to them. She’s lucky she’s an indie artist, if she had signed to a label and had become famous this would be far more tilted to this side. As in, there’d be no chance to erase her old name, at all, and we probably wouldn’t bother.

Honest question:

If an artist released a song when he was 17 yrs old, the lyrics containing ‘horrible’ and ‘offensive’ content.
(anyone fill in what they consider horrible or offensive themselves, I won’t be the judge on that)

In his thirties he is still a performing artist, but he isn’t the same person as he was when he recorded those songs. He regrets them, and he now completely disowns the message of those songs, and completely distances himself from the state of mind he was in at that time.

But to this day, he gets bugged, challenged, misunderstood and attacked over the songs he sung some 20 years ago.
He then requests websites, companies, stores, database owners to remove that old content.

He also requests MusicBrainz to remove references to that old content.

What to do?

Can you solidify and prove any of the three statements that you made here?

Nothing. I’m cold like that, sorry.
EDIT: I suppose I could elaborate. Might take me a while to think about my response though.

3 Likes

this is a case where the “withdrawn” status makes the most sense to me

if we remove releases, they’ll just pop back up. the best we can do is provide proper context, linking public statements of apology etc.

a withdrawn status could enable flexibility in how/where the release is presented

i don’t think a withdrawn flag makes sense for trans artist credit changes, as the release isn’t being withdrawn, the credits are being updated to reflect reality. in order to provide proper context around that, I think something like

artist credit display options

would do a better job

neither of these changes seem huge, they’re still not defined enough to turn into code, but i wouldn’t expect any data migration or api issues

if we can nail down exit criteria i’m down to get a dev env set up and try to get a pr out

2 Likes

This was the downside to my idea. You’d probably have to give the alias an MBID. But I still think we need a way to handle these changes automatically, or at least in batches. The number of edits would still be messy.

actually good idea, props

Taylor Swift would enjoy that

My question: Is this really solving the problem at hand? Has someone called for deadnaming to require an extra click in the UI?

I’m not against the principle, it just seems to be adding complexity to the db when imo all this needs is a guideline.

i have

Please elaborate

e.g.
“In situations where a trans artist does not wish to be deadnamed, please do not revert release credits to the deadname.”

As a guideline would directly address the edits/case in point (I’m sure that there is more detail that could be added ofc, not every situation will be as simple as this one, but that’s a different bridge imo)

Seems straightforward to me. As mentioned this has already been acknowledged as a agreeable path forward by the MB style leader.

1 Like

Seems fair to me. But again, how do we establish such a case? And what do we do when it is not the case?

Sorry for arguing, i want to have the cake and eat it too

so if i change a physical release away from using a deadname the policy would be to keep it inconsistent with the printed name?

i think that idea has gotten some pushback

1 Like

Yes that would be the policy, and yes it has not (and most likely will not) found agreement.

So, a call needs to be made, because a good DB needs consistency and clear guidelines. I would hope that everyone would abide by whatever guideline is decided upon.

Eat away :yum: edit: And also… keep it?? :exploding_head:

Guidelines are just guides, and the voting and edit note system are there to help editors navigate the fuzzy lines together. So I don’t think it would need more elaboration personally, people can use their noggins figure out (or debate about and then vote on) what “when an artist does not wish to be deadnamed” means. Edge cases may need digging into (e.g. do we remove cover art? Personally I think not without a removal request from the artist… already we’re in a different can of worms), but anything is a step forward.

1 Like

That’s… not how it works.

I… don’t know? So far I’ve argued exclusively for releases that are digital, which can change in credit over time. I don’t know that physical releases can get the same treatment. We need a search hint for these at the very least.

We need to establish where the line is. The truth is, neither side knows where to stop.

But keep it respectful. I know it has been for a while, but it warrants repeating. So far all disrespectful comments seem to have been ignored, so do yourself a favor and cool down before you reply.

1 Like

a good DB needs to be structured in a way that allows accurate recording and respectful presentation of information

returning to the juno example

we’ve found an area in which accurate data in the db leads to deadnames being presented without context

the only guidelines i can think of involve putting inaccurate data in fields in certain cases to ensure respectful presentation, such as

if that policy does not find agreement, then the policy will stay the status quo of “accurate to what was printed”

i can’t think of any guidelines that would find agreement that can solve this, but i have thought of technical solutions that could be agreeable

if there’s a guideline that works i’m all ears, but i think this is a problem of tools, not rules

1 Like

OK with changing download release but in this example, a CD, Ellen is printed on the back cover of a physical release.
In this case, we cannot change the reality.

3 Likes

which is why i keep proposing technical changes to how “credited as” is handled

right now, “credited as” completely replaces the artist name with the credited name, there’s no room for nuance or context

imdb provides context in their listings, “a credited as b”

as editors, we should have the ability to present credited names with proper context

if we don’t we’re publishing pages that refer to people by deadname only and that’s just not a good look

2 Likes