git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <derrickstolee@github.com>
To: Junio C Hamano <gitster@pobox.com>,
	Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, johannes.schindelin@gmx.de
Subject: Re: [PATCH 0/3] Use "allowlist" and "denylist" tree-wide
Date: Wed, 13 Jul 2022 14:33:05 -0400	[thread overview]
Message-ID: <647a4cf7-ef1f-284b-37e2-4dceb3cfae1d@github.com> (raw)
In-Reply-To: <xmqqk08hdm05.fsf@gitster.g>

On 7/13/2022 12:18 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> The terms "allowlist" and "denylist" are self-defining. One "allows" things
>> while the other "denies" things.
>>
>> These are better terms over "whitelist" and "blacklist" which require prior
>> knowledge of the terms or cultural expectations around what each color
>> "means".
> 
> Half Devil's advocate mode on, as I got up on the wrong side of the
> bed this morning.
> 
> I am very much for consistent uses of allow/deny and I think it is a
> good idea to review and apply this series.
> 
> But I'd prefer to see us more honest to ourselves.  Like it or not,
> the code comment and documentation are targetted toward those who
> can read English, and when you say something is whitelisted in
> English, you know exactly what it means, due to shared knowledge of
> historical use of the word.
> 
> We are doing this change in the name of inclusion.  I find it
> intellectually dishonest to avoid saying that true reason, and
> instead say the allow/deny pair is more "precise".  They are not
> more precise.  In fact, the fact why you have to choose between deny
> and block and defend deny over block shows that these words are less
> precise.  People who use white/black do not have to choose between
> black and other colors and say "white/red may be OK but we choose
> black because..." to defend the choice of their words.
> 
> The reason we do this change is because the project thinks that it
> is the right thing to encourage the adoption of these more inclusive
> words, together with other projects that did the same.
> 
> In addition, they are words more widely accepted in today's world,
> and new folks are more likely to be educated with these words.  As
> time goes by, the historical white/black will be less understood, so
> it makes it a future-proofing change, as well.
 
I like how you start by saying you are playing devil's advocate,
but then go on to add more reasons to support the work. It's good
feedback to make the case stronger.

Thanks,
-Stolee

  reply	other threads:[~2022-07-13 18:33 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13 13:20 [PATCH 0/3] Use "allowlist" and "denylist" tree-wide Derrick Stolee via GitGitGadget
2022-07-13 13:20 ` [PATCH 1/3] Documentation: use allowlist and denylist Derrick Stolee via GitGitGadget
2022-07-13 15:21   ` Jeff King
2022-07-13 18:34     ` Derrick Stolee
2022-07-13 20:20   ` Junio C Hamano
2022-07-13 13:20 ` [PATCH 2/3] t/*: use allowlist Derrick Stolee via GitGitGadget
2022-07-13 13:20 ` [PATCH 3/3] *: use allowlist and denylist Derrick Stolee via GitGitGadget
2022-07-13 13:27   ` Johannes Schindelin
2022-07-13 15:23   ` Jeff King
2022-07-13 13:29 ` [PATCH 0/3] Use "allowlist" and "denylist" tree-wide Johannes Schindelin
2022-07-13 16:18 ` Junio C Hamano
2022-07-13 18:33   ` Derrick Stolee [this message]
2022-07-13 20:32     ` Junio C Hamano
2022-07-13 19:42 ` Ævar Arnfjörð Bjarmason
2022-07-13 22:28   ` Junio C Hamano
2022-07-15  2:25     ` Derrick Stolee
2022-07-13 20:02 ` Ævar Arnfjörð Bjarmason
2022-07-15  2:38 ` [PATCH v2 0/3] Remove use of "whitelist" Derrick Stolee via GitGitGadget
2022-07-15  2:38   ` [PATCH v2 1/3] Documentation: remove use of whitelist Derrick Stolee via GitGitGadget
2022-07-15 10:47     ` Ævar Arnfjörð Bjarmason
2022-07-19 14:21       ` Derrick Stolee
2022-07-15  2:38   ` [PATCH v2 2/3] t/*: avoid "whitelist" Derrick Stolee via GitGitGadget
2022-07-15 11:02     ` Ævar Arnfjörð Bjarmason
2022-07-19 15:09       ` Derrick Stolee
2022-07-19 15:26         ` Ævar Arnfjörð Bjarmason
2022-07-19 15:42           ` Derrick Stolee
2022-07-19 19:44         ` Junio C Hamano
2022-07-15  2:38   ` [PATCH v2 3/3] *: " Derrick Stolee via GitGitGadget
2022-07-15 11:19     ` Ævar Arnfjörð Bjarmason
2022-07-15  6:30   ` [PATCH v2 0/3] Remove use of "whitelist" Junio C Hamano
2022-07-15 16:16     ` Phillip Wood
2022-07-19 18:32   ` [PATCH v3 0/5] " Derrick Stolee via GitGitGadget
2022-07-19 18:32     ` [PATCH v3 1/5] daemon: clarify directory arguments Derrick Stolee via GitGitGadget
2022-07-19 18:32     ` [PATCH v3 2/5] git-cvsserver: clarify directory list Derrick Stolee via GitGitGadget
2022-07-19 18:32     ` [PATCH v3 3/5] git.txt: remove redundant language Derrick Stolee via GitGitGadget
2022-07-31  0:35       ` Jeff King
2022-07-19 18:32     ` [PATCH v3 4/5] t: avoid "whitelist" Derrick Stolee via GitGitGadget
2022-07-19 18:32     ` [PATCH v3 5/5] transport.c: " Derrick Stolee via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=647a4cf7-ef1f-284b-37e2-4dceb3cfae1d@github.com \
    --to=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).