Proposal: whitelist/blacklist alternatives

[Celeste Horgan]

Hey all,

This is a proposal to remove whitelist/blacklist terminology from our repositories. I would be particularly interested in hearing from the group their preferred alternative term.

What follows is a copy-paste from a google doc I put together around the time of the WG's inception. That said, I'd still like to give a chance for the group to discuss this proposal, raise concerns, and otherwise so please take this opportunity to do so.

Cheers,

Celeste

-----

Definition: 

Lists which permit or deny a set of nouns, or select enabled features.

Proposed alternative:

• allowlist/denylist, allowedNouns/deniedNouns

Reasoning:

The underlying assumption of the whitelist/blacklist metaphor is that white = good and black = bad. Because colors in and of themselves have no predetermined meaning, any meaning we assign to them is cultural: for example, the color red in many Southeast Asian countries is lucky, and is often associated with events like marriages, whereas the color white carries the same connotations in many European countries. In the case of whitelist/blacklist, the terms originate in the publishing industry – one dominated by America 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 would enhance understanding. Allowlist/denylist, or simply using allowed/denied as an entity prefix has the added benefit of being easily translatable to other human languages,

Recommendation: Adopt immediately

Supporting research and precedents:

• “Blacklists” and “whitelists”: a salutary warning concerning the prevalence of racist language in discussions of predatory publishing

• IETF Network Working Group: Terminology, Power and Oppressive Language

• Android issue

• Openssl PR

• cURL PR

[Celeste Horgan]

If there are no objections, I propose acceptance by lazy consensus (or lack thereof) by EOD Friday, August 28th, 2020.

Celeste

[Stephen Augustus]

+1 to proceeding with this recommendation.

-- Stephen

--
You received this message because you are subscribed to the Google Groups "Kubernetes WG Naming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-na...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/132aa05b-b963-4d9e-9640-5c91fba73591n%40googlegroups.com.

[Jaice Singer DuMars]

Also +1

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/CAOqU-DRLndioEorug%2BYMy5c86Ze7rbJAfCMHyuHR41A8BvVjTQ%40mail.gmail.com.

[Jenny Warnke]

+1

remark: I'd prefer either allowlist/denylist (might be easier to get integrated by community as it contains list as well) or allowed/denied (short and meaningful).

Wouldn't prefer allowedNouns/deniedNouns as `list` is more precise for me than `noun`

-- Jenny

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/CAJHHSLxqqu8BnmtbtYcPVdwgtg%2B_4UdnZpWfARaRDdP4GJ3buQ%40mail.gmail.com.

[Aaron Crickenberger]

If we're encouraging blanket search/replace and there can only be one, then I think these are acceptable terms.  One other pattern I have encountered a few times is ExemptNouns, for cases where either "allowlist" or "denylist" ends up meaning "things for which a policy is not enforced."

- aaron

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/CANYE4J%2BdJL8KQe62HuPXX7aiy9sM%2BqBuS70yt7GFNL6tCFKfPQ%40mail.gmail.com.

[Celeste Horgan]

Hi Aaron,

Thanks for your recommendation. I don't think we have to encourage just one option, but let's discuss that at the next meeting.

To move this discussion along a little: I sat down with Hound and did a keyword search through our repositories for blacklist to see the scale of the change we'd have to make, particularly on a code level. You can see the full results here.

Some conclusions from this exercise: 

1. There are 561 mentions of the word 'blacklist'. Of those, 55 repositories use it at a code level (for either variable/struct names, method names, flags, or otherwise).
   
2. Of the 55 repositories which use it at a code level, most only returned results for their /vendor directory.
   
3. Most of our mentions of blacklist (and whitelist) come from imported go/vendor libraries rather than being introduced in our own code. The most prolific of these libraries is BinaryLog, which is used in nearly ever repository that returned a result for 'blacklist'.
   
4. Of the 55 repositories mentioned, approximately 13 of them introduce blacklist outside of /vendor. Of those 13:
   1. Only one uses blacklist(/whitelist) in .go file names – kubernetes-sigs / alibaba-cloud-csi-driver.
   2. Nine have fairly minor uses of the word (as in, used in less than 10 files)
   3. The remaining three have over 40 hits for the word each: kubernetes/autoscaler, kubernetes/kops, kubernetes/kubernetes.

I didn't do 'whitelist', because it had 2000+ mentions and I got tired :)

I don't mean for anyone to draw any conclusions from these. But if I were to draw conclusions, I'd say that ignoring vendor libraries this is a relatively quick win.

Celeste

[Celeste Horgan]

Per our discussions last meeting, here's an ADR for replacing blacklist/whitelist with allowlist/denylist:

https://github.com/kubernetes/community/pull/5341

Please comment!

Celeste