mattn · February 25, 2025 15:03 · Jun 14, 2020 · Jun 10, 2020 · Jun 10, 2020 · Jun 10, 2020
diff --git a/README.md b/README.md
@@ -263,6 +263,8 @@ The only thing I personally have against Leader/Follower is that it is a bit odd
 
 ### Replace all whitelist/blacklist with allowlist/blocklist (2020-06-08)
 
+https://github.com/php/php-src/pull/5685
+
 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:

diff --git a/README.md b/README.md
@@ -318,3 +318,21 @@ 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!
+
+## OpenSSL
+
+### Better words (2020-06-8)
+
+https://github.com/openssl/openssl/pull/12089
+
+Remove some offensive/archaic terminology from OpenSSL.
+
+## Symfony 
+
+### Small update in our internal terminology (2020-06-07)
+
+https://github.com/symfony/symfony/pull/37128
+
+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 `PHPUnit\Util\Blacklist`
diff --git a/README.md b/README.md
@@ -278,3 +278,43 @@ Above INI directive and value returned by opcache_get_configuration() will be ma
 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)
+
+https://github.com/cli/cli/issues/929
+
+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 に変更された
+
+## Git (git-for-windows)
+
+### Change non-inclusive naming (2020-06-08)
+
+https://github.com/git-for-windows/git/issues/2674
+
+[A thread on the Git mailing list](https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/) 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!
diff --git a/README.md b/README.md
@@ -258,3 +258,23 @@ https://github.com/apple/swift/pull/218
 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.
+
+## PHP
+
+### 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 されている。
diff --git a/README.md b/README.md
@@ -182,6 +182,30 @@ The effort here would be just putting up small CLs grouped by area/directory (fo
 
 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)
+
+https://chromium-review.googlesource.com/c/chromium/src/+/2234793
+
+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.
+
 ## Go
 
 ### all: replace usages of whitelist/blacklist and master/slave (2020-06-08)

diff --git a/README.md b/README.md
@@ -135,6 +135,14 @@ We can even just use them as verbs directly, as we do with the former terms. So
 
 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)
+
+https://github.com/rails/rails/pull/33681
+
+ほか Ruby 関連だとここに多くまとまっている。
+
+https://github.com/ruby/psych/pull/378
+
 ## Python
 
 ### Avoid master/slave terminology (2018-09-07)

diff --git a/README.md b/README.md
@@ -69,6 +69,10 @@ Google は代替を用意せず、文脈から正しい単語を選ぶ事を推
 
 https://developers.google.com/style/word-list#blacklist
 
+### 英国家サイバーセキュリティセンター、用語「whitelist」「blacklist」を使用中止へ
+
+https://security.srad.jp/story/20/05/04/067221/
+
 # 各 OSS での議論
 
 ## Django

diff --git a/README.md b/README.md
@@ -81,7 +81,7 @@ 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'
 
-## CrunchDB
+## CouchDB
 
 ### Replace "master" and "slave" terminology (2014-05-26)
 

diff --git a/README.md b/README.md
@@ -65,6 +65,10 @@ http://www.kenkyusha.co.jp/uploads/lingua/prt/18/gendai1806.html
 
 https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.2.1
 
+Google は代替を用意せず、文脈から正しい単語を選ぶ事を推奨している。
+
+https://developers.google.com/style/word-list#blacklist
+
 # 各 OSS での議論
 
 ## Django

diff --git a/README.md b/README.md
@@ -67,21 +67,21 @@ https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.2.1
 
 # 各 OSS での議論
 
-## Django (2014-05-21)
+## Django
 
-https://github.com/django/django/pull/2692
+### replaced occurrences of master/slave terminology with leader/follower (2014-05-21)
 
-### replaced occurrences of master/slave terminology with leader/follower
+https://github.com/django/django/pull/2692
 
 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'
 
-## CrunchDB (2014-05-26)
+## CrunchDB
 
-https://issues.apache.org/jira/browse/COUCHDB-2248
+### Replace "master" and "slave" terminology (2014-05-26)
 
-### Replace "master" and "slave" terminology
+https://issues.apache.org/jira/browse/COUCHDB-2248
 
 Inspired by the comments on this PR:
 
@@ -91,47 +91,47 @@ Summary is: `master` and `slave` are racially charged terms, and it would be goo
 
 As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after.
 
-## Drupal (2014-05-28)
+## Drupal
 
-https://www.drupal.org/node/2275877
+### Replace "master/slave" terminology with "primary/replica" (2014-05-28)
 
-### Replace "master/slave" terminology with "primary/replica"
+https://www.drupal.org/node/2275877
 
 Replace master/slave with primary/secondary. The reasons include:
 
 1. This change has also already been evaluated and made by the Django community,
 2. 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
 3. 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
 
-## Redis (2016-04-21)
+## Redis
 
-https://github.com/antirez/redis/issues/3185
+### Replace "master" and "slave" terms in Redis (2016-04-21)
 
-### Replace "master" and "slave" terms in Redis
+https://github.com/antirez/redis/issues/3185
 
 Inspired by [django/django/pull/2692](https://github.com/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.
 
 Worth noting, [CouchDB made a similar change](https://issues.apache.org/jira/browse/COUCHDB-2248). [As did Drupal](https://www.drupal.org/node/2275877).
 
-## Rails (2018-08-22)
+## Rails
 
-https://github.com/rails/rails/issues/33677
+### Replace use of whitelist with allowlist and blacklist with denylist (2018-08-22)
 
-### Replace use of whitelist with allowlist and blacklist with denylist
+https://github.com/rails/rails/issues/33677
 
 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.
 
-## Python (2018-09-07)
+## Python
 
-https://bugs.python.org/issue34605
+### Avoid master/slave terminology (2018-09-07)
 
-### Avoid master/slave terminology
+https://bugs.python.org/issue34605
 
 For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.
 
@@ -144,23 +144,33 @@ For more context, see:
 
 https://developers.srad.jp/story/18/09/14/0935201/
 
-## Chromium (2019-07-04)
+## Chromium
 
-https://bugs.chromium.org/p/chromium/issues/detail?id=981129
+### Issue 842296: Avoid the racially-charged terms "blacklist" and "whitelist". (2017-05-12)
 
-### Cleanup of potentially offensive terms in codebase
+https://bugs.chromium.org/p/chromium/issues/detail?id=842296
+
+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)
+
+https://bugs.chromium.org/p/chromium/issues/detail?id=981129
 
 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.
 
-## Go (2020-06-08)
+## Go
 
-https://go-review.googlesource.com/c/go/+/236857/
+### all: replace usages of whitelist/blacklist and master/slave (2020-06-08)
 
-all: replace usages of whitelist/blacklist and master/slave
+https://go-review.googlesource.com/c/go/+/236857/
 
 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
@@ -180,9 +190,9 @@ https://news.ycombinator.com/item?id=23445987
 
 https://www.reddit.com/r/golang/comments/gy9ylr/go_has_removed_all_uses_of_blacklistwhitelist_and/
 
-## MySQL (2020-06-08)
+## MySQL
 
-master/slave terminology is offensive and should be replaced with something more appropriate, such as primary/replica.
+### 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)
@@ -197,4 +207,14 @@ https://dev.mysql.com/doc/refman/5.7/en/replication-administration-pausing.html#
 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.
+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.
+
+## Swift
+
+### (Properly) fix potentially inconsiderate naming (2015-12-05)
+
+https://github.com/apple/swift/pull/218
+
+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.
diff --git a/README.md b/README.md
@@ -30,6 +30,7 @@ master/slave の意味は不適切で難解である。それに加えて master
 * builder/worker
 * leader/replica
 * primary/replica
+* primary/second (DNS)
 
 https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1
 

diff --git a/README.md b/README.md
@@ -169,7 +169,7 @@ 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
@@ -179,3 +179,21 @@ https://news.ycombinator.com/item?id=23445987
 
 https://www.reddit.com/r/golang/comments/gy9ylr/go_has_removed_all_uses_of_blacklistwhitelist_and/
 
+## MySQL (2020-06-08)
+
+master/slave terminology is offensive and should be replaced with something more appropriate, such as primary/replica.
+
+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.
diff --git a/README.md b/README.md
@@ -47,6 +47,12 @@ https://en.wikipedia.org/wiki/Hollywood_blacklist
 
 初めてブラックリストに登録されたとされる「ハリウッド・テン」というグループについて。エンタテインメント業界で流通したレッドチャネルと呼ばれる雇用拒否リストがあった。
 
+http://www.kenkyusha.co.jp/uploads/lingua/prt/18/gendai1806.html
+
+言ってはいけない！　現代アメリカのタブーな英語 3 | 研究社 WEB マガジン Lingua リンガ
+
+
+
 ## 代替案
 
 * blocklist/allowlist

diff --git a/README.md b/README.md
@@ -20,6 +20,10 @@ https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%82%B9%E3%8
 > 
 > 一方で、こうした論争を避けるため、データベースの分野ではマスタースレーブの代替語として「プライマリー」や「レプリカ」といった語句を採用するケースもある。2018年には、プログラミング言語Pythonが論争の末、マスタースレーブを「ペアレント」や「ワーカー」「ヘルパー」といった語句に置き換えている。
 
+https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1
+
+master/slave の意味は不適切で難解である。それに加えて master と slave の比喩は技術的にも歴史的にも不正確である。例えば、DNSでは「スレーブ」はゾーン転送を拒否することもできる。
+
 ## 代替案
 
 * leader/follower

diff --git a/README.md b/README.md
@@ -27,6 +27,8 @@ https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%82%B9%E3%8
 * leader/replica
 * primary/replica
 
+https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1
+
 # blacklist/whitelist の歴史的背景
 
 https://en.wikipedia.org/wiki/Blacklisting
@@ -50,6 +52,8 @@ https://en.wikipedia.org/wiki/Hollywood_blacklist
 * stoplist/golist
 * redlist/greenlist
 
+https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.2.1
+
 # 各 OSS での議論
 
 ## Django (2014-05-21)

diff --git a/README.md b/README.md
@@ -25,6 +25,7 @@ https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%82%B9%E3%8
 * leader/follower
 * builder/worker
 * leader/replica
+* primary/replica
 
 # blacklist/whitelist の歴史的背景
 

diff --git a/README.md b/README.md
@@ -45,6 +45,7 @@ https://en.wikipedia.org/wiki/Hollywood_blacklist
 * blocklist/allowlist
 * blocklist/safelist
 * blocklist/passlist
+* denylist/allowlist
 * stoplist/golist
 * redlist/greenlist
 

diff --git a/README.md b/README.md
@@ -98,6 +98,17 @@ The summary is: master and slave have racial meanings (especially in North Ameri
 
 Worth noting, [CouchDB made a similar change](https://issues.apache.org/jira/browse/COUCHDB-2248). [As did Drupal](https://www.drupal.org/node/2275877).
 
+## Rails (2018-08-22)
+
+https://github.com/rails/rails/issues/33677
+
+### Replace use of whitelist with allowlist and blacklist with denylist
+
+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.
 
 ## Python (2018-09-07)
 

diff --git a/README.md b/README.md
@@ -34,8 +34,12 @@ https://en.wikipedia.org/wiki/Blacklisting
 
 https://en.wikipedia.org/wiki/Blacklist_(employment)
 
+各国や地域で行われた雇用拒否のリスト化
+
 https://en.wikipedia.org/wiki/Hollywood_blacklist
 
+初めてブラックリストに登録されたとされる「ハリウッド・テン」というグループについて。エンタテインメント業界で流通したレッドチャネルと呼ばれる雇用拒否リストがあった。
+
 ## 代替案
 
 * blocklist/allowlist

diff --git a/README.md b/README.md
@@ -34,7 +34,7 @@ https://en.wikipedia.org/wiki/Blacklisting
 
 https://en.wikipedia.org/wiki/Blacklist_(employment)
 
-
+https://en.wikipedia.org/wiki/Hollywood_blacklist
 
 ## 代替案
 

diff --git a/README.md b/README.md
@@ -32,7 +32,9 @@ https://en.wikipedia.org/wiki/Blacklisting
 
 > 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.
 
-https://en.wikipedia.org/wiki/Blacklist_(computing)
+https://en.wikipedia.org/wiki/Blacklist_(employment)
+
+
 
 ## 代替案
 

diff --git a/README.md b/README.md
@@ -24,6 +24,7 @@ https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%82%B9%E3%8
 
 * leader/follower
 * builder/worker
+* leader/replica
 
 # blacklist/whitelist の歴史的背景
 
@@ -37,6 +38,9 @@ https://en.wikipedia.org/wiki/Blacklist_(computing)
 
 * blocklist/allowlist
 * blocklist/safelist
+* blocklist/passlist
+* stoplist/golist
+* redlist/greenlist
 
 # 各 OSS での議論
 

diff --git a/README.md b/README.md
@@ -23,6 +23,7 @@ https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%82%B9%E3%8
 ## 代替案
 
 * leader/follower
+* builder/worker
 
 # blacklist/whitelist の歴史的背景
 
@@ -35,6 +36,7 @@ https://en.wikipedia.org/wiki/Blacklist_(computing)
 ## 代替案
 
 * blocklist/allowlist
+* blocklist/safelist
 
 # 各 OSS での議論
 

diff --git a/README.md b/README.md
@@ -91,16 +91,51 @@ Worth noting, [CouchDB made a similar change](https://issues.apache.org/jira/bro
 
 https://bugs.python.org/issue34605
 
+### Avoid master/slave terminology
+
+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:
+
+* https://github.com/antirez/redis/issues/3185
+* https://www.drupal.org/node/2275877
+* https://issues.apache.org/jira/browse/COUCHDB-2248
+* https://github.com/django/django/pull/2692
+
 https://developers.srad.jp/story/18/09/14/0935201/
 
 ## Chromium (2019-07-04)
 
 https://bugs.chromium.org/p/chromium/issues/detail?id=981129
 
+### Cleanup of potentially offensive terms in codebase
+
+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.
+
 ## Go (2020-06-08)
 
 https://go-review.googlesource.com/c/go/+/236857/
 
+all: replace usages of whitelist/blacklist and master/slave
+
+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.
+
+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.
+
 https://news.ycombinator.com/item?id=23445987
 
 https://www.reddit.com/r/golang/comments/gy9ylr/go_has_removed_all_uses_of_blacklistwhitelist_and/

diff --git a/README.md b/README.md
@@ -80,7 +80,7 @@ https://github.com/antirez/redis/issues/3185
 
 ### Replace "master" and "slave" terms in Redis
 
-Inspired by django/django/pull/2692, Redis should replace its "master" and "slave" terminology.
+Inspired by [django/django/pull/2692](https://github.com/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.
 

diff --git a/README.md b/README.md
@@ -42,30 +42,34 @@ https://en.wikipedia.org/wiki/Blacklist_(computing)
 
 https://github.com/django/django/pull/2692
 
-> 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'
+### replaced occurrences of master/slave terminology with leader/follower
+
+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'
 
 ## CrunchDB (2014-05-26)
 
 https://issues.apache.org/jira/browse/COUCHDB-2248
 
-> Inspired by the comments on this PR:
-> 
-> https://github.com/django/django/pull/2692
-> 
-> Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `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" and "slave" terminology
+
+Inspired by the comments on this PR:
+
+https://github.com/django/django/pull/2692
+
+Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `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.
 
 ## Drupal (2014-05-28)
 
 https://www.drupal.org/node/2275877
 
 ### Replace "master/slave" terminology with "primary/replica"
 
-> Replace master/slave with primary/secondary. The reasons include:
-> 
+Replace master/slave with primary/secondary. The reasons include:
+
 1. This change has also already been evaluated and made by the Django community,
 2. 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
 3. 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
@@ -74,6 +78,15 @@ https://www.drupal.org/node/2275877
 
 https://github.com/antirez/redis/issues/3185
 
+### Replace "master" and "slave" terms in Redis
+
+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.
+
+Worth noting, [CouchDB made a similar change](https://issues.apache.org/jira/browse/COUCHDB-2248). [As did Drupal](https://www.drupal.org/node/2275877).
+
+
 ## Python (2018-09-07)
 
 https://bugs.python.org/issue34605

diff --git a/README.md b/README.md
@@ -62,6 +62,14 @@ https://issues.apache.org/jira/browse/COUCHDB-2248
 
 https://www.drupal.org/node/2275877
 
+### Replace "master/slave" terminology with "primary/replica"
+
+> Replace master/slave with primary/secondary. The reasons include:
+> 
+1. This change has also already been evaluated and made by the Django community,
+2. 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
+3. 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
+
 ## Redis (2016-04-21)
 
 https://github.com/antirez/redis/issues/3185

diff --git a/README.md b/README.md
@@ -50,10 +50,10 @@ https://github.com/django/django/pull/2692
 
 https://issues.apache.org/jira/browse/COUCHDB-2248
 
-Inspired by the comments on this PR:
-
-https://github.com/django/django/pull/2692
-
+> Inspired by the comments on this PR:
+> 
+> https://github.com/django/django/pull/2692
+> 
 > Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `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.

diff --git a/README.md b/README.md
@@ -50,6 +50,14 @@ https://github.com/django/django/pull/2692
 
 https://issues.apache.org/jira/browse/COUCHDB-2248
 
+Inspired by the comments on this PR:
+
+https://github.com/django/django/pull/2692
+
+> Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `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.
+
 ## Drupal (2014-05-28)
 
 https://www.drupal.org/node/2275877
No results found