Handling name of transgender artist

It’s all here.

2 Likes

i’m sorry.

i already went through this thread and I’m vexed enough as it is.

i might not care about you disregarding my opinion, but i do care about not subjecting myself to reading annoying controversial threads about political-correctness again.

i’ll pass.

When chaban started the thread, they referenced an edit to a specific artist’s works – but along the 100+ posts in this thread, the discussion has broadened considerably and with that broadening has come some self-righteous hostility.

One can take the view on the specific issue of crediting past release of a trans artist that the name change of a trans artist is not sufficiently special to warrant an across-the-board change in MusicBrainz procedures – without, e.g., “displaying a lower-level of appreciation of the everyday dross rained upon” trans people or being a “reactionary transphobe who cannot deal with a modern worldview”.

To put a finer point on it, I think it’s important to seek out and listen to older and non-North-American trans voices before making a policy change. I believe not of them will, for example, regard their past names as “dead”.

5 Likes

I actually think that’s smart. As an LGBT person I hate the USA way of approaching gender and sexuality politics, where… well i don’t wanna derail the thread. thing is, I feel extremely alienated from LGBT communities because of it. ANYWAYS

this. deadnames seem like an USA construct. USA is not the whole world.

3 Likes

from a data perspective, we’re looking at

artist, artist credit, artist credit name, artist_alias_type, artist_alias, and possibly artist_annotation and gender

the problems:

  • gender options are male/female at the moment, that only represents a reductionist understanding of gender and does not represent all artists
  • artist_credit/artist_credit_name are fairly limited in scope, and aren’t adequate to handle the context needed for
    • digital releases with updated artist credits, digital media isn’t set in stone, keeping only the first or most recent time slices on changing releases doesn’t paint the whole picture
    • presenting deadnames without deadnaming

the good things:

  • artist and artist_alias support name changes over time quite well

possible technical solutions

  • add artist credit display options
    • add columns to artist_credit/artist_credit_name to manage how the credit should be presented (replace/“credited as”/hidden)
    • update web presentation layer to use the new column
    • update picard? not sure what this might touch there
  • support “living” releases (digital releases that change over time)
    • lots of ways this could work
      • add release<->release relationship of “obsoletes”
      • add date ranges on all credits/track names
      • implement alternative tracklists, add historical as a type of alternative
  • combine artist_alias with artist_credit/artist_credit_name
    • this seems like it could be a bunch of work, but could help prevent/reduce duplicated data/functionality

i think the artist credit display options would be the quickest technical solution for presenting deadname credits without deadnaming. the digital release time slice issue seems more complex, and the aliases part is really just a nice to have

3 Likes

What about an assignable, dynamic alias with different values for different time ranges? Is that possible? That would fix issues with other artists’s releases as well, regardless of transgender issues.

Would make it automatic as well, you modify the alias once and then MusicBrainz knows what to display.

LOONA

I mentioned LOONA before, which used to have the stylized name LOOΠΔ. Some platforms changed it, some didn’t because of their own search hints implementation (Deezer must have one, searching for LOONA returns LOOΠΔ). That makes it harder to track though because one release is shared across multiple platforms with their own spellings.

An assignable alias with start and end dates for different spellings for digital releases on platforms that group everything together under spellings that change over time.

Is that possible? Am I coming across fine? i don’t know what I’m writing

that seems doable on a per-release basis, but if we want to

then we’d be painting ourselves into an “artists can only have one alias at a time” corner

1 Like

You’d assign the alias per release.

So we’d have the timeline LOOΠΔ >> LOONA for Spotify releases and then all releases with the alias for Spotify would update upon modifying that timeline. But the other releases with a regular alias would stay the same.

Yes, let’s just discredit a whole concept by claiming its a 'murican thing. :roll_eyes:

For the record, I’m from a former pit village in NE England, marra, and this never gets any less tiresome.

5 Likes

Seems the conversation here has calmed down a bit - let’s please try to keep it that way. Hopefully we can have disagreements on how to deal with what is a complicated data topic while still remaining civil and respecting other people’s views.

6 Likes

Now, on the topic of the conversation in question: it seems at least for music re-released under a changed name, some of the suggestions made here seem like good starting points: using the current name on release groups and recordings, and marking the old releases as superseded in some way.

The proposed “withdrawn” status seems like an option, and would probably work fine, although it would need defining clearly what qualifies as “withdrawn”, including in the specific transgender artist situation (if the artist had put out physical releases, would we want to consider those withdrawn too?).

A second option would be to have a “X was superseded by Y” relationship, kinda like what we do with pseudo-releases. That would have the benefit of letting data users know not only that the old release was withdrawn but what to replace it with if they so want - but the drawback that the release would be linked from the newer version with the new name, which I guess would make the old data more visible. It seems to currently link them without the artist credit, at least, though. It should only be used in a 1:1 equivalence situation, I guess, so “this is literally the same release, but with a change” - while a new release with a different barcode or whatnot should probably not use such a relationship.

Other than those changes, I’m right now not sure what could be future, larger changes that would combine all the needs of our users + artists. I think it’s likely MusicBrainz will never be able to fully avoid deadnaming (even if just because, as mentioned earlier in the thread, some people will have an old version of a release that they will probably expect to be able to find under the name they have), but we should probably try and follow artist intent better in the way we present the information and make it clear that it is not considered current (which will also allow those people who have the old version to make the change that follows the artist intent if they so decide). Having a specific alias type or artist credit mechanism for this could help and it is probably doable from the technical point of view, although it might be argued that it helps make the whole issue more visible, rather than less so.

A last situation (this time guideline- rather than schema-related) that would need to be looked into is how to ensure we are following artist intent, once it is possible - I guess the main idea would be “if the artist specifically replaces the old releases with the new name, then we assume they want to get rid of the old name, if not, we assume they do not unless expressed elsewhere”, but I’m not familiar enough with how transition usually goes to be sure :slight_smile:

11 Likes

Most of the people here that care about its visibility seem to want the previous alias to not be stored in the database anymore, at all. This is an unattainable goal.

FWIW, I care about its visibility. A way to hide away the name until explicit user action would be handy. But erasing it from the database, I disagree with.

@reosarevok themselves have previously said they are happy to do this, on a case-by-case basis. It’s not particularly difficult or complicated, particularly in regards to the digital releases in this case. The edit that sparked this fiasco was changing digital releases to the deadname fwiw, after they were imported with the artists actual name.

See:

note: I’m not particularly in favour of some complicated new alias/withdrawn system. Either MB recognises that deadnames sometimes are harmful and there’s no positive value in storing and sharing them (against someone’s wishes, case-by-case), or it doesn’t. And this is a rare occasion where I don’t think the community should be tasked with the decision.

3 Likes

One technical thing we could do to make the entry exist in the database but not quite as visible is to use the Status flag on releases.

To deal with bootleg releases there is a quality flag and this can be either: Official, Promotion, Bootleg and Pseudo-release.
If we make a new status type of “withdrawn” or some other label it will still be in the database but be less visible.
If there is then a relationship on releases that marks this release as being superseded by a new version of the release your music tagger look for this relationship and follow this to get the new info and offer new metadata to be saved.

1 Like

The new alias system is not meant to handle just transgender artists. It’s meant to handle any case where the alias changes over time, like digital stores and streaming services. Otherwise we get:

  1. old releases with the old spelling and new releases with the new spelling. this is not accurate.
  2. all releases with the new spelling. this is not accurate.
  3. a mismatch with what was the correct spelling at the time and the data entered in the future. this is already happening.

What do you propose? Changing each release in a case-by-case basis? Nobody is gonna do that, which means we’d have to use bots to do the work instead.

ghhhggghgghhhhh

Please don’t even consider prioritizing external input over the users who maintain the database. This website is kept alive by its community. I’d consider that a betrayal.

I do think we need the opinion of transgender artists and their fans. But the way this thread has gone, all my energy to listen has gone away. We need respect to be enforced here and the mods are asleep…

I wanna listen, I really do. But no matter which side you’re on, if you don’t act respectfully, I’m not gonna listen.

So here’s an excercise for you: Gather a group of transgender people and ask them for their opinion, without showing bias in the question, on this front. Do not pick and choose the people. Do not pick anybody you know. Do not pick anybody from any kind of social circle that is biased your way.

Can you do that? Of course not. That’s silly. OP did that on the edit and that’s against the rules of MusicBrainz too.

So we’re stuck with this thread.

if this became the standard I would scream from all the work that’d come from it.

Here’s a thought: I don’t like editing.

I like all metadata being in it’s place. But I don’t like putting it in there. And yet, I do, because otherwise it’s gonna be a mess.

Please don’t make the work harder… I’m already tired from the thought. We really need the database software to handle digital alias history.

I don’t know what this has to do with the situation?

We currently handle these cases by adding new releases with the updated information, with the date (if known) that the change took place. We’ve been doing it for yonks and it hasn’t caused any particular trouble. I’ve done it for at least hundreds of digital release groups where there’s been track or credit updates.

If you’re not proposing something that directly deals with the issue of deadnaming being unwanted/dangerous for some parties then it’s quite unrelated to the issue surrounding the edits this thread is referring to. The current standard is to add the edited reissue as its own release in the group, there’s just disagreement re. what this does in a transgender context.

I’m talking about admins (or even the board) needing to make a call.
edit: and I would expect this call to take into account any community discussion

4 Likes

Actually no, I have seen nobody arguing for completely removing the old name from the database. This seems to be the fear people opposing the change to the new name have, but as far as the discussion went this is a myth.

The exact degree of visibility for sure is a matter of debate, though. The point is that currently the old name is very visible, and in places where the old credits are used there is no clear indication of the artist’s current name.

11 Likes

@ApeKattQuest_MonkeyPython and myself had some exchange of our opinions on the topic on IRC. As CatQuest currently has unfortunately no access to the forums for technical reasons I share the discussion here:

https://chatlogs.metabrainz.org/libera/musicbrainz/2021-06-30/?msg=4828265&page=1

And I was asked to apologize for their spelling (I don’t think there is a need to apologize, though :smiley: )

4 Likes

That sounds like a lot of added complexity…

Artists often have hundreds of releases under their name. If we make a new release for every spelling change… actually, you have no problem with doing it. But the guidelines propose nothing if I’m not mistaken, so I’m not sure that’s right.

Ah yes, you’re right.
I’d expect those in charge to make the right decision and I’d trust them to do so if it came to that.