"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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.
