search

box / developer.box.com

Box Developer Documentation - Content & Configuration
https://developer.box.com
Apache License 2.0
25 stars 86 forks source link

Replace use of whitelist with allowlist and blacklist with denylist #124

Open HaysaRodrigues opened 4 years ago

HaysaRodrigues commented 4 years ago

I am reading and working with Box API and I have noticed that they refer to blocklist as blacklist and allowlist as whitelist.

Considering a lot of argumentations, besides that those words are racists and we can't even use it as a verb.

Some discussions: https://twitter.com/dhh/status/1032050325513940992.

I think that Box could also follow the good exemples and replace theses terms.

Also:

Regardless of origin, allow/deny are simply clearer terms that does not require tracing the history of black/white as representations of that meaning. We can simply use the meaning directly.

Originally posted by @dhh in https://github.com/rails/rails/issues/33677#issuecomment-414873738

cbetta commented 4 years ago

Hi @HaysaRodrigues thank you so much for bringing this up, I personally really appreciate it as these issues are close to my heart.

A bit of history

Late last year I actually added checks to our documentation to help us exclude a lot of insensitive language like this from our developer documentation. We used Alex JS for this, and you can see the changes here.

I was able to remove a lot of gendered, racist, sexist, and otherwise insensitive and inconsiderate writing from our docs, but a few exceptions had to be made. For example, we use a tool called Postman, and as much as I'd like to write Postal worker - that's not the name of the tool.

Similarly, we have a lot of places in our product (not the docs) where we used terms that were being flagged. This includes the terms whitelist and blacklist.

I actually removed these terms from our documentation where it did not directly reference an API product that was a called a whitelist/blacklist (see here for example). I decided to leave these words in-place in the instances where it referenced an actual product that used the insensitive word. For example. in this guide we talk about our API endpoint for creating collaboration whitelists. In this case the term whitelist is part of our API endpoint, our resource model, the web app, and many other places. Calling it something else would have just been confusing in this case.

Next steps

As I said though, this is definitely close to my heart and I'd love to help you get this on our product team's radar. As this is a wider product problem I don't think GitHub is the right place, instead we're better off posting this to http://pulse.box.com/. A community contribution will go a lot further than me making the listing on my own, though I will totally also be continuing to raise internal awareness.

Please feel free to DM me here, on twitter, or on email if you want me to help you find all the places where we use this text so that we can even make a better, stronger case together on Pulse.

cbetta commented 4 years ago

I wanted to provide a little update on this. A few months ago we've started an internal project to update our product to remove any insensitive language from the codebase, UI, and APIs. It's a work in progress but we're slowly moving forward, defining suitable and consistent replacement language and adding processes to make sure no new instances are beeing added back in. The APIs are probably one of the largest and final aspects to be changed, but the change is coming.