AIUI French privacy law recognises “the right to be forgotten”.
So if MB wishes to abide by French law then the db has to forget some things when requested.
I don’t agree that it’s inflamatory. It’s just my opinion and you aren’t arguing against it, you just say it’s wrong and it seems like we’re just supposed to believe you. (EDIT: I thought about it. I can see how it could seem inflamatory. I meant it literally though)
I feel like it is relevant though. If an artist outs itself as trans, records the fact, and doesn’t do anything to erase his old name off the internet, I feel like we aren’t doing anything wrong.
This is a colossal underestimation of the near-impossibility of scrubbing all trace on one’s past from the internet, though, especially in a country like the UK, where name changes have to be public record.
And also a very choice of pronouns (“their” was right there).
Look, if I was talking about Patricia, fine. But I was talking about an hypothetical artist with no gender, because they are imaginary. (Also, nouns have gender in Spanish. I was thinking “el artista”. That’s why I messed up.)
Please don’t make this harder for me. This thread is already extremely difficult to stay in. I only want to fix Patricia’s page, and I’m not talking about leaving the old half under her birth name.
Because as you surely remember, I don’t want that.
This also confirms that she does take issue to being called that, of course, but it doesn’t confirm that she’d be opposed to keeping a search hint; be it UI hidden, user privilege-walled, whatever.
Also, I’m not going back to Twitter. That was a one time deal. I’m not going to search for anything there, you can’t make me
I would be very strongly opposed to this policy for physical releases.
(But in fact, I think it’s a dangerous policy even for digital-only releases.) It would require MetaBrainz to maintain lists of which artists have rejected their past names and which have not, and to make these lists accessible by editors, so editors would know whether a revert was appropriate or not. And I’d be a LOT more creeped out knowing that MetaBrainz was tracking trans and non-binary people in this way, than if I knew that it was indiscriminately transcribing the back of the jackets of records you could find in any number of flea markets.
Our guidelines regularly reference artist intent, and we don’t have any need to compile and maintain ‘lists’. The voting and edit note system does fine. It’s not about getting 100% certainty in every situation - the guidelines are there to guide editors and help make a call when there would otherwise be endless friction between two different use-cases/preferences.
A similar argument was made against adding the ‘other’ gender field option, and that turned out fine. No Orwellian surveillance techniques have emerged (that I know of… Dunn Dunn Dunn)
Your justification for comparing the dangers of coming out and being deadnamed fails.
There was clearly no need for you to include your opinion about the relative dangers on this thread.
By including it and then defending it on the basis that it is your opinion you made this thread more unfriendly to trans people. And made divisive dialogue on this thread more likely.
This is a highly emotional and widely politicised topic we are dealing with.
I suggest staying sharply focussed on the issues being worked on. And not sharing your opinions about very distantly related matters that have no bearing on the issues being worked on.
The more left-wing folks seem to prefer that. (There’s lots of those in this thread)
However I think we should go case by case; we should figure out whether each artist would prefer the old name to be forgotten.
Anyways, we’re never gonna reach a consensus here, so unless a MB authority comes here and decides for us we’re gonna be here forever. And, at this point I don’t care, please do.
I feel like keeping a list of names like that would actually run in violation of the right to be forgotten, unfortunately.
Possibly a far safer option might be the option to “lock” an artist’s name and have users request temporary unlocks should the need legitimately arise? That would likely add more work for staff by having them check and handle such requests, though.
The challenge with “locked name” is that the deadname can be used by an unsuspecting editor to create another Artistdeadname.
This would be spotted for active Artists probably.
But a very low activity Artist is easily not going to have a knowledgable editor checking that Artistdeadname doesn’t get made.
Which would leave the Artist themself to be constantly checking that Artistdeadname has not been created.
One way would be to offer Artists who want data forgotten to go on a list. And if that is not to their liking make it clear that MB will have no way to recognise when/if Artistdeadname is re-created in the db.
There is also the issue of the security of such a list.
It would have to be available to check new Artists against - this would appear to make it vulnerable, even more vulnerable than our email addresses needed to be.
At least one of the people subscribed to the artist knows that name X should not be used. If someone wants to edit name X in, they get notified and can explain in the comments. Not perfect, but the best we can do IMO.
I don’t know why this is getting made more complicated. This entire database is based off information that we confirm via edit notes and voting. We don’t lock fields, we don’t maintain lists, for anything. People discuss it, refer to the guidelines, and it works. A guideline re. deadnaming isn’t some kind of strange unicorn that can’t be integrated without some technical wizardry. There’s stuff we deal with that’s much more complicated! I just don’t get it to be honest
Here is my subscribed Artists list https://musicbrainz.org/user/mmirG/subscriptions/artist
About 170 of the 172 get no edits from one year to the next. I’ll stop editing eventually and then no one will pay them any attention. The idea of lists, either in MB or kept by individual editors, no longer makes sense to me.
aerozol please put forward what you think a useful guideline around this would look like.