Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: better suggestions for blacklist / whitelist #45

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions content/faqs.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,9 +38,11 @@ Newspeak involved multiple changes but the most essential were:

Everything in the conscious language initiative is *the exact opposite* of that.

For example, "Denylist" is both more precise and more accurate than "blacklist";

"Primary" is both more precise and more accurate than "master" in projects that have made the switch.
For example, "Primary" is both more precise and more accurate than "master" in
projects that have made the switch. Some project choose to use "main" as an
alternative for brevity. On the other side of this paradigm, projects have
elected to use terminology pertaining to "secondary" for instances of the
primary branch - for example, "indev", "clone", "staging", and others.

The goal of this project is to use more precise words, in order to avoid
unintended connotations that some common words and phrases have. Not
Expand All @@ -59,9 +61,10 @@ Here are some resources on the topic:
* [Broken Metaphor: The Master-Slave Analogy in Technical Literature (2007)](https://www.jstor.org/stable/40061475?seq=1) - article in JSTOR, requires free membership to read
* [Terminology, Power and Oppressive Language](https://tools.ietf.org/id/draft-knodel-terminology-00.html) - article with recommendations by Mallory Knodel and Niels ten Oever
* [Why "master" matters](https://twitter.com/mislav/status/1270388510684598272) - A twitter thread.
* Point 3 of "A Framework for Analysis" in [Kludge Cyber Systems' "TERMINOLOGY" Statement](https://github.com/kludge-cs/transparency/blob/master/open-statements/2021-04-04--TERMINOLOGY.md#a-framework-for-analysis)

## How do I get my organization involved?

* Join our [mailing list](https://groups.google.com/g/inclusivenaming) to receive project updates and invitations to community meetings.
* Join our [mailing list](https://groups.google.com/g/inclusivenaming) to receive project updates and invitations to community meetings.
* Identify key people in your organization who can represent this effort in an ongoing fashion
* Read our Implementation Guide and other resources to start making effective changes
7 changes: 4 additions & 3 deletions content/language/word-list.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,8 @@ Lists which permit or deny a set of nouns, or select enabled features.

**Proposed alternative:**

* allowlist/denylist
* allowedNouns/deniedNouns
* `whitelist` -> exception list, inclusion list, list of allowed X / allowed X list
* `blacklist` -> exclusion list, prohibition list, list of unauthorized X / unauthorized X list
quaid marked this conversation as resolved.
Show resolved Hide resolved

**Reasoning:**

Expand All @@ -20,7 +20,7 @@ Because colors in and of themselves have no predetermined meaning, any meaning w
In the case of whitelist/blacklist, the terms originate in the publishing industry – one dominated by the USA and England, two countries which participated in slavery and which grapple with their racist legacies to this day.

From a technical communication perspective, using whitelist/blacklist as a naming convention applies metaphor (and, in turn, unintended meaning) when it isn’t needed.
More directly descriptive words like allowlist/denylist enhances understanding. Allowlist/denylist, or simply using allowed/denied as an entity prefix has the added benefit of being easily translatable to other human languages.
More directly descriptive alternatives such as the ones proposed above both avoid these connotations and also provide the additional benefit of being accessible to readers from other linguistic backgrounds. Other proposed alternatives such as `allowlist`, `denylist`, `grantlist`, `blocklist`, et cetera, do more harm than good when dealing with languages other than English, so they should not be used.

**Recommendation:** Adopt immediately

Expand All @@ -30,6 +30,7 @@ More directly descriptive words like allowlist/denylist enhances understanding.
* [IETF Network Working Group: Terminology, Power and Oppressive Language](https://tools.ietf.org/id/draft-knodel-terminology-00.html)
* [Android PR](https://9to5google.com/wp-content/uploads/sites/4/2020/06/android-aosp-allowlist-explanation.png)
* [cURL PR](https://github.com/curl/curl/pull/5546)
* ["Inclusive Language", a statement by Kludge Cyber Systems](https://github.com/kludge-cs/transparency/blob/master/open-statements/2021-04-04--TERMINOLOGY.md)

## Master, slave

Expand Down