Consul: Promote inclusive behavior by removing whitelist/blacklist terminology

[cainejette]

Something my workplace has started focusing on is improving inclusive behaviors and language. We've started an audit of our codebase and are looking for ways of replacing exclusive language like whitelist/blacklist with more neutral terms like allowlist/denylist. It would be great if consul did the same, so our codebase were cleaner.

[banks]

Thanks for raising this @cainejette, we're certainly interested in ensuring our language is inclusive and will discuss across all products the right scope for changes here.

Would you be able to confirm where you've found this terminology? To my knowledge, we don't use those terms anywhere in our actual configuration syntax currently but do use them once each on the documentation page for our configuration. I've not yet grepped the whole codebase.

so our codebase were cleaner

To be clear, are you talking about the Consul code base or your application? If your app, how would changing Consul code or docs help you app codebase?

[cainejette]

Thanks for the response @banks

We vendor our go dependencies, and I see in vendor/github.com/hashicorp/consul/api/connect_intention.go comments that mention these terms.

Looks like that's here and here.

[banks]

For context several other HashiCorp products have already intentionally moved away from "white/black list" language so we should too.

There are a few examples in the docs and a handful in code comments that should be relatively simple to replace with something more neutral as suggested.

Auditing for any additional non-inclusive terms is something we'll undertake separately as we develop a more comprehensive organisation-wide policy on terms that we want to avoid to avoid scope creeping this too much!

[cainejette]

Happy to open a PR if you're accepting them.

[cainejette]

https://github.com/hashicorp/consul/pull/7969