blacklist/whitelist master/slave に関する情報集め
blacklist/whitelist、master/slave という単語は相応しくないという意見に OSS がどの様に対応すべきかを自身で考える為の情報集めです。見つけ次第、逐次更新していきます。
僕(mattn) 自身は black lives matter に同意をしています。blacklist/whitelist、master/slave という単語を廃止する事が、歴史的背景を持たない文化圏では特定の意味を持たなかった為、個人的には若干思う所はありますが、廃止自身に反対するつもりはありません。
昔から、主副を表す物には master/slave という単語が使われてきました。ハードディスクの IDE、仮想端末(pty)、色々あります。またネットワークの IP フィルタリングに関しては blacklist/whitelist と表記した物が今でも沢山あります。
我々日本人が意識せずに使っていた blacklist/whitelist、master/slave という単語が、人々にどの様に影響しうるのか、今後 OSS としてどの様に関わっていけば良いかを理解する上で、自分なりの情報集めをしたいと思っています。
この Gist で個人的な偏りを出すつもりはありません。ただ、1つだけ言っておきたいです。これらの単語が過去に特定の文化圏で差別的な意味を持っていたのを知らずに使った他の文化圏の人達や、その前提知識を得ずに議論に参加しょうとする人達に対して無知だ無関心だ素人だと攻撃する様な事は建設的ではないと思っています。決してそれらを招く為の情報集めではない事をご理解下さい。
master/slave の意味は不適切で難解である。それに加えて master と slave の比喩は技術的にも歴史的にも不正確である。例えば、DNSでは「スレーブ」はゾーン転送を拒否することもできる。
- primary/second (DNS)
A blacklist can list people to be discriminated against and cannot be employed. As a verb, blacklist can mean to put an individual or entity on such a list.
言ってはいけない！ 現代アメリカのタブーな英語 3 | 研究社 WEB マガジン Lingua リンガ
各 OSS での議論
replaced occurrences of master/slave terminology with leader/follower (2014-05-21)
The docs and some tests contain references to a master/slave db configuration. While this terminology has been used for a long time, those terms may carry racially charged meanings to users. This patch replaces all occurrences of master and slave with 'leader' and 'follower'
Replace "master" and "slave" terminology (2014-05-26)
Inspired by the comments on this PR:
slave are racially charged terms, and it would be good to avoid them. Django have gone for
replica. But we also have to deal with what we now call multi-master setups. I propose "peer to peer" as a replacement, or just "peer" if you're describing one node.
As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after.
Replace "master/slave" terminology with "primary/replica" (2014-05-28)
Replace master/slave with primary/secondary. The reasons include:
- This change has also already been evaluated and made by the Django community,
- The word "slave" has negative connotations (although this might or might not be relevant in the naming of a technical term) including multi-century history of slavery to benefit European colonial powers, prison laborers today forced to work in conditions at times resembling that slavery, young girls sold into sex slavery in many parts of the world today
- Somehow even this has a sexist angle: in the Django issue a devops person (presumedly female) complains about others making dominatrix jokes at her because of master/slave terminology
Replace "master" and "slave" terms in Redis (2016-04-21)
Inspired by django/django/pull/2692, Redis should replace its "master" and "slave" terminology.
The summary is: master and slave have racial meanings (especially in North America, but also more generally) and it would be good to avoid them. Django went for primary and replica. I am not sure what makes the most sense for Redis.
Replace use of whitelist with allowlist and blacklist with denylist (2018-08-22)
Per https://twitter.com/dhh/status/1032050325513940992, I'd like for Rails to set a good example and tone by using better terminology when we can. An easy fix would be to replace our use of whitelist with allowlist and blacklist with denylist.
We can even just use them as verbs directly, as we do with the former terms. So something is allowlisted or denylisted.
I took a quick look and it seems like this change is mostly about docs. We only have one piece of the code that I could find on a search that uses the term whitelist with enforce_raw_sql_whitelist. Need to consider whether we need an alias and a deprecation for that.
change all instances of blacklist and whitelist to denylist and whitelist (2018-08-22)
ほか Ruby 関連だとここに多くまとまっている。
Avoid master/slave terminology (2018-09-07)
For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.
For more context, see:
Issue 842296: Avoid the racially-charged terms "blacklist" and "whitelist". (2017-05-12)
Chromium's source code uses "blacklist" and "whitelist" a lot. Ideally we wouldn't do that since it unnecessarily reinforces the notion that black==bad and white==good. https://mcwriting11.blogspot.com/2014/06/that-word-black-by-langston-hughes.html illustrates this problem in a lighthearted, if somewhat pointed way.
These terms can usually be replaced by "blocklist" and "allowlist" without changing their meanings, but particular instances may need other replacements. (Defining an exhaustive set of replacements is not within the scope of this bug - let's focus on improving instead of perfection.)
Places that are visible to users affect more people and so are higher priority than instances internal to the code, but both should be fixed eventually. New code should definitely not use the terms.
Cleanup of potentially offensive terms in codebase (2019-07-04)
This will be the parent issue for all the potential words we find in the codebase.
The effort here would be just putting up small CLs grouped by area/directory (for reviewer's sake). Hopefully uncontroversial to land quickly.
For anything with potential non-trivial compact impact (command line parameter names, enterprise policy keys, etc), the suggestion would be doing them in one-offs (or very small related groups) so we can ask experts on a case-by-case basis whether some mitigation is necessary.
Rename classes in components/blacklist to use more inclusive names. (2016-06-09)
Rename classes in components/blacklist to use more inclusive names.
This is the first of 2 changes to rename components/blacklist to components/blocklist. This contains all the class/method/member/variable renaming. There should be no functional differences here. This patch will be followed by another patch that renames the directory/files and updates the necessary build system rules. The vast majority of the changes here are simply replacing an 'a' with an 'o'.
- Replaced blacklist references with blocklist in components/blacklist
- Replaced whitelist references with allowlist in components/blacklist
- Updated all code that depends on components/blacklist to use new names and updated the names of any callers that may have been influenced by the original names.
- Filed bugs and left TODOs for code that interacts with backend services that may depend on the old name.
- Replaced some empty method bodies with '= default;' and added default member assignments to make ClangTidy happy. These should not cause any behavior changes.
all: replace usages of whitelist/blacklist and master/slave (2020-06-08)
There's been plenty of discussion on the usage of these terms in tech. I'm not trying to have yet another debate. It's clear that there are people who are hurt by them and who are made to feel unwelcome by their use due not to technical reasons but to their historical and social context. That's simply enough reason to replace them.
Anyway, allowlist and blocklist are more self-explanatory than whitelist
and blacklist, so this change has negative cost.
master/slave terminology is offensive and should be replaced with something more appropriate, such as primary/replica.
Didn't change vendored, bundled, and minified files. Nearly all changes are tests or comments, with a couple renames in cmd/link and cmd/oldlink which are extremely safe. This should be fine to land during the freeze without even asking for an exception.
master/slave terminology is offensive and should be replaced with something more appropriate, such as primary/replica. (2020-06-08)
Some technology vendors have already done so. See wikipedia page here: https://en.wikipedia.org/wiki/Master/slave_(technology)
How to repeat: View any documentation page about replication in general, for example: https://dev.mysql.com/doc/refman/8.0/en/replication-options-slave.html
Or, view documentation for command line operations, ie. 'start slave', etc: https://dev.mysql.com/doc/refman/5.7/en/replication-administration-pausing.html#:~:text=mysql%3E%20START%20SLAVE%3B,a%20backup%20or%20other%20task
Suggested fix: I would suggest starting with changing documentation such that 'master' is replaced with 'primary' and 'slave' is replaced with 'replica'.
sql commands and configuration settings should be changed accordingly. ie. 'start slave' should be replaced with 'start replica', etc. existing variables, commands, etc can continue to be honored for backward compatibility to facilitate migration to the new terminology over time.
(Properly) fix potentially inconsiderate naming (2015-12-05)
So I don't mind master/slave terminology, but if you're going to fix it, at least end up with something others chose too. See django which ended up with Primary/Replica (after first adopting Leader/Follower in django/django#2692) in django/django#2694 (which was just closed, but still changed in django/django@beec056 )
The only thing I personally have against Leader/Follower is that it is a bit odd as a german (and seems I'm not alone in that feeling). Though I wouldn't mind that had it not already been changed from master/slave anyway. Just want it changed "properly" if it gets changed at all. It also seems to be used in literature already from what I was told.
Replace all whitelist/blacklist with allowlist/blocklist (2020-06-08)
The change was inspired by https://go-review.googlesource.com/c/go/+/236857/ and replaces all occurrences of whitelist/blacklist with allowlist/blocklist.
Most of the changes are internal only with two exceptions for which this patch requires RFC:
- opcache.blacklist_filename INI directive
- opcache_get_configuration()["blacklist"] key in returned array value
Above INI directive and value returned by opcache_get_configuration() will be marked as deprecated and superseded by (respectively):
- opcache.blocklist_filename INI directive
- opcache_get_configuration()["blocklist"] key in returned array value
Old INI directive and value returned by opcache_get_configuration() will remain the same for BC purposes till next minor version for removal.
→ issue はオーバーヒートし過ぎて lock されている。
cli (GitHub CLI client)
Change the default branch from "master" to something else (2020-05-25)
Our team would prefer to change our default branch name away from "master", since "master" is a generally problematic term due to its association with slavery in some contexts. (We are aware that "master" as used in git does not necessarily have that connotation, but we do not want to nitpick about etymology here.)
We are considering one of these names for the default branch name: trunk, development, or main.
- check our scripts/automation for whether master is hardcoded anywhere
- run the branch migration script (below)
- move branch protections from master to new branch
- modify docs to reference the new branch instead of master
- delete master branch
- instruct devs to update their local clones:
git fetch origin --prune git checkout trunk git remote set-head origin trunk git branch -D master
→ デフォルトブランチが trunk に変更された
Change non-inclusive naming (2020-06-08)
A thread on the Git mailing list made the cautious attempt at bringing this issue to attention: enough names in Git are non-inclusive to cause unintended consequences. Most prominently, the default name of the default branch.
I create this ticket to track the progress of fixing this.
While I want to fix it rather sooner than later, I want to abide by the saying "If you want to go fast, go alone, if you want to go far, go together". I want to go far on this.
Any constructive comments are welcome!
Better words (2020-06-8)
Remove some offensive/archaic terminology from OpenSSL.
Small update in our internal terminology (2020-06-07)
I would like us to use the term "blocklist" instead of "blacklist". I've updated all the internal uses I could find. There are no BC breaks.
We still use some "blacklist" when we relate to