Removal of offensive terms from the codebase

[Holzhaus]

In June 2020, we committed to remove offensive terms from our codebase for the 2.4 release. Unfortunately, we did not follow through. Although we did remove some occurrences (e.g., the leader sync rename), we did not really fulfill that promise.

We need to discuss how we want to proceed now.
One one hand, our announcement might be seen as performative if we don't actually remove these terms for 2.4.
On the other hand I think it's a bit late now to refactor so much code before 2.4 beta, so we might consider postponing it to 2.5.

For the actual renaming, we need to discuss what we want as a replacement. Here's my initial proposal:

Click here to show proposal. (Content Warning: Contains offensive terms associated with slavery)

Term used	Course of Action
[AuxiliaryN],master CO	Add alias [AuxiliaryN],main_mix
[MicrophoneN],master CO	Add alias [MicrophoneN],main_mix
[Master] CO group	Add group alias [Main]
EngineMaster object	Rename to EngineMixer
MicMonitorMode::MASTER enum member	Rename to MicMonitorMode::Main
MicMonitorMode::MASTER_AND_BOOTH enum member	Rename to MicMonitorMode::MainAndBooth

[Swiftb0y]

Proposal LGTM, only issue I see is that creating a group alias might be difficult.

Also, monitoring the DJ community as a whole, it doesn't seem like the term "Master" fell out of fashion (which is admittedly sad). I still think we should pull through with the renaming, but I'm concerned of how much we loose by deciding against using the established domain language.

[daschuer]

Right, .. another 2.4 task. The advantage to do it in 2.4 is that we wont have merge conflicts if we merge 2.4 to 2.5 regularly.
But we will have a lot initially due to the "EngineMaster" -> "EngineMixer" This applies to the change at any time.

The other issue is that we have an annoying long list of 2.4 regressions:
https://github.com/mixxxdj/mixxx/issues?q=is%3Aopen+is%3Aissue+label%3Aregression+milestone%3A2.4.0
And we are past due by one month.

We need to decide at one point to release anyway.

[ronso0]

but I'm concerned of how much we loose by deciding against using the established domain language.

What do you mean exactly?

[Holzhaus]

I'm concerned of how much we loose by deciding against using the established domain language.

To be honest, I don't think this any of the new terms are less descriptive than the old ones.

IMHO EngineMixer (or maybe EngineMainMix ?) communicates better way this class does than the previous term. The old name was a bit ambiguous and could also indicate that it is related to Sync.

For the Aux/Mic COs, main_mix is also more descriptive than the old term without _mix. And I suppose everyone can deduce what the "main output" is (the old term is also pretty clear for experienced DJs, but may need explanation for absolute newbies that are unfamiliar with audio technobabble).

[Swiftb0y]

but I'm concerned of how much we loose by deciding against using the established domain language.

What do you mean exactly?

Well, in order to communicate efficiently and clearly in a certain domain (could be music, finance, whatever really) it's important to use the language of the domain. I'm worried that we might introduce confusion among users when they use different terms interchangeably, especially when not all parties know both terms.
The issue is rather philosophical and applies to basically everything where language is evolving, so this is not a topic we really need to discuss here. We're programmers, not an ethics committee...

[ronso0]

Okay, understood. So IIUC your concerns are basically Master -> Main, right?
We already changed to Main in the GUI and as long as we use the term consistently for all user-facing aspects I think there won't be any issues

To be honest, I don't think this any of the new terms are less descriptive than the old ones.

And I suppose everyone can deduce what the "main output" is (the old term is also pretty clear for experienced DJs, but may need explanation for absolute newbies that are unfamiliar with audio technobabble).

I agree.

[JoergAtGithub]

Also, monitoring the DJ community as a whole, it doesn't seem like the term "Master" fell out of fashion

I think we should put the word into the context. As many words in the English language, "Master" has two different meanings: leader/dominant person (German:"Herr") and sombody who is very good skilled in a disciplin (German:"Meister"). The second meaning has nothing to do with master/slave-relationship, it has a very positive meaning.
In the Audio world we use the later meaning for Audio-Mastering/Tonmeister etc., - steps done on the Main output, and therefore it's labeled as output for the master.

[Holzhaus]

I'd rather not restart that debate at this point, for two reasons:

1. We announced that we're going to remove the term from our codebase in our announcement from 2020.
2. We already started to transition away from "Master" for the main output in the GUI. In many case, this just performs the rename in the code and therefore improves consistency.

[ywwg]

I am glad that we've made great progress towards making these changes, and it's unfortunate that we haven't finished it yet. These changes have proven to be difficult to make and cause regressions in controller configs, so they are high-risk changes. I think if we apologize for missing the 2.4 milestone for removal, people will understand that we are making progress and have a good track record of following through. But for now, I don't think this should block 2.4

[ywwg]

Changing milestone