Jetpack: Remove problematic language

[kraftbj]

We should remove historically problematic language from Jetpack:

• [x] Grandfathering (done in #16050).
• [ ] Blacklist & whitelist (#16109, #16166, #16192)
• [ ] Use of core WordPress functions now deprecated, such as wp_blacklist_check in modules/contact-form/grunion-contact-form.php (https://core.trac.wordpress.org/changeset/48121) -- https://make.wordpress.org/core/2020/07/23/codebase-language-improvements-in-5-5/ #16568 #16569
• [ ] Master & slave, etc
• [ ] Switch from the use of the master branch as the default branch to trunk. Related discussion: p4TIVU-9rA-p2
• [ ] "Sharedaddy" as the underlying technical name to the Sharing module.
• [ ] "Masterbar" as the underlying technical name to the WordPress.com toolbar module.

"Blacklist" and "Whitelist" are used in a lot of places within Jetpack, so we should open separate PRs to address in chunks.

[kraftbj]

We have no reference to "slave" in the codebase. I haven't reviewed every instance of master, but it seems all to refer to "primary" so far.

[kraftbj]

Hi @blacklistisnotracist and welcome to Jetpack.

I do agree that terms like allowlist/blocklist may be better just because they are more descriptive.

I'm glad we have a common point of agreement that whitelist/blacklist can be better described with other language.

That being said, calling blacklist or whitelist a racist word is simply wrong.

I didn't say it was racist. Defining something as "racist" is harsh and, while others may use it more freely, I use that term as a last resort when it is obvious the subject is trying to treat someone(s) differently by their ethic background or race.

The wording is problematic. White vs black implies one is better than the other. Why do we not call it a bluelist and a yellowlist? Why does whitelist mean allow and blacklist mean blocked? Why does blacklist, black sheep, black market all refer to things that are seen as a negative?

Let's stop calling a group of people black first. Let's start from there. Color comes first. Race came later. Colors are tied to images, which can't be changed. We shouldn't be tying a race with a color in the first place.

Out of scope for the Jetpack repo and not within the my purview. In either case, it is not up to me to decide what a community wishes to be called.

Let's stop the hypocrisy and focus on something that has real impacts.

Language is important. By updating our codebase to use more descriptive language helps everyone—those who English is not their primary language for example. By reducing or eliminating areas that promote known forms of implicit bias, there is no negative to doing that. We can show that we care enough about investigating and acting on areas that support implicit bias to put resources into it (e.g. my time).

Just as I'm continually learning how to challenge myself in my assumptions about the world, I'm likewise open to conversation about issues like this. The Github issue, however, is not the best venue for it. If you have a blog post you've written about the subject, I'm happy to continue this conversation in your comment box.

[sarayourfriend]

@kraftbj I noticed a couple places in wp-calypso where we reference some Jetpack things that use whitelist/blacklist:

https://github.com/Automattic/wp-calypso/blob/854e1338289d2f7427e4f013fe2cfe885e0e3280/client/jetpack-connect/connection-notice-types.js#L29

https://github.com/Automattic/wp-calypso/blob/854e1338289d2f7427e4f013fe2cfe885e0e3280/client/state/jetpack/settings/utils.js#L25

Any ideas if it will be possible to change these and what kind of coordination would be required if so?

[sarayourfriend]

Also, with respect to sharedaddy, will the work y'all are doing also update the language referring to it in Calypso (aside from the to-be-deprecated classnames)?

[kraftbj]

Automattic/wp-calypso:client/jetpack-connect/connection-notice-types.js@854e133#L29

I'm not seeing anywhere those values are used on the Jetpack-side. I think it may be all within Calypso, so I would think okay to change.

Automattic/wp-calypso:client/state/jetpack/settings/utils.js@854e133#L25

This one is harder to change and require coordination. Since it is a setting on the local end, any changes need to be both in concert with Jetpack and support old versions of Jetpack. So, even if we update the option name and transition it to a new one, we won't be able to just rename it in Calypso without either forcing a particular version of Jetpack—which would be a huge bump from what we require now—or normalizing it based on what version of Jetpack remains.

I'm undecided on how to address this yet.

Also, with respect to sharedaddy, will the work y'all are doing also update the language referring to it in Calypso (aside from the to-be-deprecated classnames)?

Haven't explored at all what changing it would involve. It would also be pretty gnarly since it would also need to be changed on WP.com at the same time. May fall into a similar situation where some instances may need to be retained. But, haven't looked into it at all yet.