Date
1 - 3 of 3
Inclusive Language RFC
|
Teng, Lynn L
Hello Sean,
toggle quoted message
Show quoted text
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@...>; 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, |
|
|
|
Sean
Content looks great except "Plan 4.1."
toggle quoted message
Show quoted text
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, |
|
|
|
Teng, Lynn L
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 |
|
|