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