Why are edits removing unnecessary references to racially charged terms being rejected?

Question

The terms "master" and "slave" have been widely used within electronics, but we need to recognise that these terms are racially charged. There are plenty of alternative words that can be used, and thus avoid unnecessary references to slavery. For example, the term "master" can become "controller" or "host", and "slave" can become "client" or "peripheral".

I have recently made a few edits replacing instances of these words with alternatives. These have been rejected. The only comment I receive from these rejections is that "The edit does not improve the quality of the post. Changes to the content are unnecessary or make the post more confusing." There doesn't seem to be a mechanism for responding to a rejection itself, so I think the only avenue I have is to ask about it here.

The code of conduct for this StackExchange community reads:

No bigotry. We don’t tolerate any language likely to offend or alienate people based on race, gender, sexual orientation, or religion — and those are just a few examples. Use stated pronouns (when known). When in doubt, don't use language that might offend or alienate.

The terms that these edits are replacing clearly fall within the category of language that is "likely to offend or alienate people based on race". Why are these edits being refused?

Is the Electronics StackExchange community going to acknowledge that these terms need to be replaced so that it can take a step towards inclusivity?

Answer 1

"we need to recognise that these terms are racially charged", "likely to offend or alienate people based on race".

Perhaps in a small part of the world, and only if you anthropomorphize your disk drive controller. If you think a "slave" is only of a certain race, it tells more about your inclusivity.

Since it makes perfect sense for a machine to have a master, and for one machine to treat another as a slave that does its bidding, there is little to be upset about.

Answer 2

I just did a search on the word "slave" at EESE. There are many, many posts that use master/slave terminology in the context of SPI and I2C bus communications. It is not at all clear to me that it will be beneficial to go back and change all those terms. For one thing, the terminology is baked into many datasheets and standards documents. The SS pin on SPI devices is an abbreviation of "slave select." Some I2C host controllers support "multi-master" mode. So that is the simple utility argument. If we purge all those terms, some people when searching will not find what they are looking for.

And, quite frankly, I think it is very possible that people who are offended by the terminology may simply be mistaken. I rarely say that. If you are offended you are offended. It is not for someone else to say that you are not offended. But this may be a case where any offense taken is simply due to being misinformed about the meaning of the words.

If you search with a search engine on the terms "slave select" or "I2C bus master" you will find so many hits in technical literature that you will quickly realize the futility and in-utility and counter-productivity of changing it all. So that is another argument. It is just so much non-productive work to fix it.

Answer 3

Since I was a rejecter on the linked question, and Rob was looking for some feedback, here's my reasoning.

I think that Rob should have left a comment, and left it to the original author to consider that point of view. It's a random person on the internet who you'll never meet, so assume good intentions as a starting point for conversation.

The post in question is from 2019 and not by Rob. I don't support going back and altering other peoples' responses from the past based on what is currently considered acceptable. It is not up to us, now, to decide that what someone wrote some time ago could be considered offensive to some people and should be changed unilaterally. If the original author would like to change it, then it is up to them if they feel it is appropriate in the context of the what they've written.

As Scott mentioned in his answer, there is also the fact the datasheets, assumed knowledge etc, do rely on the phrases that were edited out so the edits do not make an improvement to the originals. If a new specification comes out that uses a different terminology than master/slave then it would be wrong to use those - the question/answer should use the specification's terminology.

Especially in cases where master/slave doesn't actually really capture the relationship properly and is just a lazy reuse, then it's a good thing. Changing how we describe things now is very easy to do, and if that helps everyone engage, then all the better. I guarantee if you start writing your codebase using host/client no one will bat an eyelid, and eventually it will just become the standard practice.

I agree with Scott that things evolve, and if you want to be involved in this then his answer has the details. Do bear in mind that the "community" you refer isn't homogenous: plenty of people do not find this language offensive, plenty of people simply do not care, and plenty of people do find it offensive. Balance has to be found and I believe (as I mentioned) that assuming good intent first of all produces better results for all parties. Declaring your view the One True Way puts people on the defensive straight away, and that is not a productive place to start a discussion from.

NB: I don't know why people downvoted this question on Meta, it's a very valid question and if people are having problems with the site then they should raise them and find out why. +1 from me.

Hope that helps :)

Answer 4

This is an issue, certainly, but it must be weighed against clarity and the potential to generate errors. There are decades of data sheets, textbooks, and engineers trained in a certain way. All of these things need to remain understandable, and systems need to remain error-free. This may seem ludicrous to you, but we've had a spacecraft crash because of failures in metric/english system conversions.

What you're suggesting is that we adopt a new standard of terminology. Perhaps Master/Slave terminology isn't an official standard, but I'll hold that it's a de facto standard.

When one doesn't like a standard, they can certainly throw it out and choose their own. It's an old joke that "the nice thing about standards is that there are so many to choose from"! Well, unless we all land in the same place, that will lead to confusion, which can lead to errors, which can lead to product recalls, computers failing, planes falling out of the sky, .... You really won't get much support for precipitous change when dealing with engineers. Engineering errors kill people.

Engineers just don't "do" things because we want to. We put effort into developing, accepting, and distributing standards. We look at all of our options, the pluses, minuses, and ramifications of each, and we make a careful decision. This is what needs to happen here. It needs to go to our professional societies and standards organizations, who will certainly examine the ramifications of a terminology change, and probably come up with a best practice for avoiding errors.

My recommendation would be to keep fighting the fight. Join and write editorials to the professional societies, join standards organizations, vote with your wallet and buy new chipsets from companies that use terminology you prefer. Communicate in discussion groups like you're doing here.

Perhaps, when the profession approaches consensus, the edits you suggest may happen. If you want to keep making edits, and getting them rejected, as part of your social approach, do so, though there may be SE ramifications for numerous turned down edits. Personally, I think such edits hurt clarity, so if you really want to do this, I suggest strikethrough to promote clarity, but you may still get rejected edits

Answer 5

On 1 October 2021, NXP released version 7 of its I2C protocol, in part, to comply with its inclusive language policy where master/slave have been replaced with controller/target:

Updated the terms "master/slave" to "controller/target" throughout to align with MIPI I3C specification and NXP's Inclusive Language Project

When I was learning electronics in college in the early 1990s, the lecturer began to teach us about master and slave flip-flops. I baulked and considered leaving the course, and asked the lecturer about the origins of these words and how they made their way into the electronics field.

This started a lively debate amongst the others in the lecture, so the lecturer asked us to invent new terms. We discussed father and son flip-flops that mirrored the terms motherboard and daughterboard; and master/servant. I suggested senior and junior flip-flops like a in a legal practise where you typically have senior and junior partners working in consensual harmony.

This has been a frequent topic of discussion amongst students for decades when they are confronted with the abhorrent dyad of "master/slave" for the first time in the classroom or lecture theatre.

The abhorrent dyad of "master/slave" is being deprecated from the field of electronics.