Inclusive Language RFC

Inclusive Language RFC

[Lynn.L.Teng]

Hello all,

Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05).  Thank you in advance for your contributions.


***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.   
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).


## Plan  
  
1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
2. Scrubbing of all comments, documentation, and Wiki pages  
3. Scrubbing all non-legacy code  
3.1. Integrate open-source commit hook that will warn submitter of violations  
4. Working with UEFI to scrub legacy code  
4.1. Update commit hook to block submissions with violations  
  
  
## Implementation Guidelines  
  
### Master/Slave to not be used together nor alone.  
Alternatives:  
Master | Slave
-------|-------
Main | Secondary, Subordinate  
Primary | Secondary, Replica
Host | Target  
Leader | Follower  
Orchestrator | Worker  
Initiator | Responder  

Or similar descriptive terminology  
  
### Blacklist/Whitelist to not be used together nor alone.  
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist  
Denylist | Allowlist  
Refused, Denied | Permitted  

Or similar descriptive terminology  

Re: [edk2-rfc] Inclusive Language RFC

[Marvin Häuser]

Hey,

On 25.10.21 20:47, Teng, Lynn L wrote:
> Hello all,
>
> Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05).  Thank you in advance for your contributions.
>
>
> ***
>
> ## Overview
>
> To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
> In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).
>
>
> ## Plan
>    
> 1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
> 2. Scrubbing of all comments, documentation, and Wiki pages
> 3. Scrubbing all non-legacy code
> 3.1. Integrate open-source commit hook that will warn submitter of violations
> 4. Working with UEFI to scrub legacy code
> 4.1. Update commit hook to block submissions with violations
>    
>    
> ## Implementation Guidelines
>    
> ### Master/Slave to not be used together nor alone.
> Alternatives:
> Master | Slave
> -------|-------
> Main | Secondary, Subordinate
> Primary | Secondary, Replica
> Host | Target
> Leader | Follower
> Orchestrator | Worker
> Initiator | Responder

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 
original.
- "Responder" is very generic - "slave" conveys work, not just any sort 
of reaction
- "Primary" and "secondary" are clearly related, "main" and "secondary" 
are not.
...

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 terminology
>    
> ### Blacklist/Whitelist to not be used together nor alone.
> Alternatives:
> Blacklist | Whitelist
> ----------|----------
> Blocklist | Passlist
> Denylist | Allowlist
> Refused, Denied | Permitted

I 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.

Thanks!

Best regards,
Marvin

>
> Or similar descriptive terminology
>
>
> 
>
>

Re: [edk2-discuss] [edk2-rfc] Inclusive Language RFC

[Teng, Lynn L]

Hello Marvin,

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.

Best regards,  
Lynn Teng

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Marvin Häuser
Sent: Wednesday, October 27, 2021 12:42 AM
To: rfc@edk2.groups.io; Teng, Lynn L <lynn.l.teng@intel.com>; devel@edk2.groups.io; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] [edk2-rfc] Inclusive Language RFC

Hey,

On 25.10.21 20:47, Teng, Lynn L wrote:
> Hello all,
>
> Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05).  Thank you in advance for your contributions.
>
>
> ***
>
> ## Overview
>
> To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
> In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).
>
>
> ## Plan
>    
> 1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
> 2. Scrubbing of all comments, documentation, and Wiki pages
> 3. Scrubbing all non-legacy code
> 3.1. Integrate open-source commit hook that will warn submitter of violations
> 4. Working with UEFI to scrub legacy code
> 4.1. Update commit hook to block submissions with violations
>    
>    
> ## Implementation Guidelines
>    
> ### Master/Slave to not be used together nor alone.
> Alternatives:
> Master | Slave
> -------|-------
> Main | Secondary, Subordinate
> Primary | Secondary, Replica
> Host | Target
> Leader | Follower
> Orchestrator | Worker
> Initiator | Responder

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 
original.
- "Responder" is very generic - "slave" conveys work, not just any sort 
of reaction
- "Primary" and "secondary" are clearly related, "main" and "secondary" 
are not.
...

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 terminology
>    
> ### Blacklist/Whitelist to not be used together nor alone.
> Alternatives:
> Blacklist | Whitelist
> ----------|----------
> Blocklist | Passlist
> Denylist | Allowlist
> Refused, Denied | Permitted

I 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.

Thanks!

Best regards,
Marvin

>
> Or similar descriptive terminology
>
>
> 
>
>

Re: [edk2-announce] Inclusive Language RFC

[Teng, Lynn L]

Hello Sean,

You make a good point.  

I will remove both steps 3.1 and 4.1 from the plan for now so we can focus on the main proposal.
We can open a discussion later on to determine how best to maintain inclusive language once the codebase has been updated. 

Here is the updated proposal:

 ***
 
 ## Overview
 
 To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
 In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on UEFI.org](https://uefi.org/).
 
 
 ## Plan
    
1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines  
2. Scrubbing of all comments, documentation, and Wiki pages  
3. Scrubbing of all non-legacy code
4. Working with UEFI to scrub legacy code 
    
    
 ## Implementation Guidelines
    
 ### Master/Slave to not be used together nor alone.
 Alternatives:
 Master | Slave
 -------|-------
 Main | Secondary, Subordinate
 Primary | Secondary, Replica
 Host | Target
 Leader | Follower
 Orchestrator | Worker
 Initiator | Responder
 
 Or similar descriptive terminology
    
 ### Blacklist/Whitelist to not be used together nor alone.
 Alternatives:
 Blacklist | Whitelist
 ----------|----------
 Blocklist | Passlist
 Denylist | Allowlist
 Refused, Denied | Permitted
 
 Or similar descriptive terminology

-----Original Message-----
From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of Sean
Sent: Monday, November 1, 2021 1:16 PM
To: Teng, Lynn L <lynn.l.teng@intel.com>; announce@edk2.groups.io
Subject: Re: [edk2-announce] Inclusive Language RFC

Content looks great except "Plan 4.1."
I don't see a commit hook as a solution that works for this community. 
I would think the plan would leverage pr-gate/ci to enforce this? 
Otherwise, it is yet another rule and place to cause code-review and contribution friction.

Thanks
Sean




On 10/25/2021 11:57 AM, Teng, Lynn L wrote:
> Hello all,
> 
> Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05).  Thank you in advance for your contributions.
> 
> 
> ***
> 
> ## Overview
> 
> To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
> In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).
> 
> 
> ## Plan
>    
> 1. Announcement of intent, and all check-ins from here onwards will 
> need to abide by Inclusive Language Implementation Guidelines 2. 
> Scrubbing of all comments, documentation, and Wiki pages 3. Scrubbing 
> all non-legacy code 3.1. Integrate open-source commit hook that will 
> warn submitter of violations 4. Working with UEFI to scrub legacy code 
> 4.1. Update commit hook to block submissions with violations
>    
>    
> ## Implementation Guidelines
>    
> ### Master/Slave to not be used together nor alone.
> Alternatives:
> Master | Slave
> -------|-------
> Main | Secondary, Subordinate
> Primary | Secondary, Replica
> Host | Target
> Leader | Follower
> Orchestrator | Worker
> Initiator | Responder
> 
> Or similar descriptive terminology
>    
> ### Blacklist/Whitelist to not be used together nor alone.
> Alternatives:
> Blacklist | Whitelist
> ----------|----------
> Blocklist | Passlist
> Denylist | Allowlist
> Refused, Denied | Permitted
> 
> Or similar descriptive terminology
> 
> 
> 
> 
>