[edk2-discuss] [edk2-rfc] Inclusive Language RFC
Teng, Lynn L
Hello Marvin,toggle quoted messageShow quoted text
Your concerns have been heard, but providing a list of every alternative for every scenario and how/when to use them would be unreasonable.
We would expect developers to use their understanding of each term and the context of how it is being used, and to find an appropriate alternative. The lists provided are by no means exhaustive, and are not definitive in how they are combined.
Similar to [the UEFI guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf), [the Linux community](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst), and [IEEE](https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf), our intent is simply to inform the community that we are going to be moving towards using Inclusive Language and are providing the list of words that are no longer permitted and possible alternatives for those words.
From: email@example.com <firstname.lastname@example.org> On Behalf Of Marvin Häuser
Sent: Wednesday, October 27, 2021 12:42 AM
To: email@example.com; Teng, Lynn L <lynn.l.teng@...>; firstname.lastname@example.org; email@example.com
Subject: Re: [edk2-discuss] [edk2-rfc] Inclusive Language RFC
On 25.10.21 20:47, Teng, Lynn L wrote:
Hello all,Some of these combinations sound very awkward because they are not
strictly or strongly related language-wise. Examples:
- In my opinion, a replica can very well be a main, it just cannot be an
- "Responder" is very generic - "slave" conveys work, not just any sort
- "Primary" and "secondary" are clearly related, "main" and "secondary"
The combination "leader"/"follower" could be interpreted politically if
you just try hard enough, who knows what language revision proposals may
look like in 10 years from now. Maybe drop it entirely. :)
Or similar descriptive terminologyI think this should be made stricter to "refused"/"permitted" and
"granted"/"denied" to stay consistent with common usage.
My biggest issues with such proposals is they tell me which words to not
use, but not which to use instead. Yes, there are plenty of alternatives
given, but when do I use which? E.g. "host" / "target" already is a very
common combination for debugging, but nobody would think of naming their
main git branch "host". If you deprecate widely conventional
terminology, in my opinion you should also provide clear and detailed
guidelines for which sub-areas they are deprecated by which exact
alternatives (e.g. "version control - main; debugging - host"). I don't
think a terminology zoo where everybody picks their preference by gut
feeling is in anyone's best interest.