Adopts blocklist/allowlist as suitable alternatives for the harmful terms blacklist/allowlist

[rthbound]

It's clear that this project has taken steps to correct usages of harmful terminology (as made evident by the deprecated usage of the "master/slave" metaphor).

This change would continue that effort by replacing the "blacklist/whitelist" metaphor with the more technically descriptive terminology of "blocklist/allowlist".

Quoting Terminology, Power and Offensive Language, a document from the Internet Engineering Task Force (IETF) which discusses both harmful metaphors:

The metaphorical use of white-black to connote good-evil is offensive. While master-slave might seem like a more egregious example of racism, white-black is arguably worse because it is more pervasive and therefore more insidious. While recent headlines have decried the technical community’s use of master-slave, there is far less discussion about white-black despite its importance. There is even a name for this pervasive language pitfall: the association of white with good and black with evil is known as the “bad is black effect” [Grewal].

Indeed, there is an entire book on the subject, written by renowned authority on race, Frantz Fanon. In his book “Black Skin, White Masks,” Fanon makes several persuasive arguments that standard language encodes subconscious in-group, out-group preferences [Fanon].

In the case of blacklist-whitelist in the technical documentation of the IETF/IRTF, it is entirely a term of art and an arbitrary metaphorical construct with no technical merit. There are scientific uses of black that are related to light– blackholes are black because light cannot escape them; a spectrographic blackbox is used as a metaphor for things that cannot be seen (e.g., blackbox is really a riff on the metaphor for light as visibility). Blacklist-whitelist is not a metaphor for lightness or darkness, it is a good-evil metaphor and therefore this trope has significant impact on how people are seen and treated. As we’ve seen with metaphors, its use is pervasive and, though not necessarily conscious, perceptions do get promulgated through culture and repetition.

As with master-slave, we save our technical argument for last, referencing and presenting first the reasons for the use of non-offensive, alternative terminology for the sake of our humanity. Indeed, our technical argument is incredibly succinct: Why use a metaphor when a direct description is both succinct and clear? There can be absolutely no ambiguity if one uses the terms, as suggested below, allow-block rather than white-black.

[rthbound]

I expect that maintainers (and users) will want this correction to be made through deprecations as was done for other harmful metaphors. I'll spend some time today on this.

[rthbound]

Is it necessary to provide some kind of backward compatible support for these old methods? I would have assumed "yes" because they are public methods, but the _ prefixes in the method names indicate to me that it is not intended for users to call or override these methods themselves.

[rthbound]

@mathieuripert, hi, I hope you are well. I'm tagging you here because I recognize your name from contributions to hostolab/covidliste and I thought that maybe you could help unlock some progress here.

This MR has been around for a little while now -- I'm wondering if these changes are something that Instacart's development team would be interested in merging. I see the originally reported issue (#310) has received some down thumbs, but I'm assuming (hoping) those aren't coming from maintainers of this project.

I'm happy to do more work on this if needed.

[jeremy]

Block/allow are nice and clear.

Do you have a plan for backward compatibility? Deprecating the error class names is the tough one IMO. Need to emit a deprecation warning when those are referenced, like Rails does.

Agree the underscore-prefixed methods are "library-private" public methods. Unless they state that they're meant to be overridden in the class they're included in, or subclassed, then it's fair game to change.

Out of an abundance of caution, the library could feature-detect whether it responds_to? the old methods, suggesting something was expecting to override them. IMO it's fine not to, though, and rely on the app doing the override to catch the regression with its own suite.