Replace racially charged language "whitelist/blacklist" #1569
7 participants
I've opened graphite-project/carbon#567 for the Carbon PR, but I'd like the main discussion to be here. The graphite-web PR will be linked against this Issue.
I agree with updating antiquated terms, but I am curious: Are safelist / blocklist clear enough in this context? Could we use simpler language such as Allow and Deny?
To clarify: whitelist/blacklist are etymologically not racist terms but if there's modern connotations, then the etymology doesn't particularly matter and I am comfortable considering them antiquated. However, they do have clear meanings, so we should make sure to try and preserve the value of the specific terms by replacing them with at-least-as-clear language, to which I think safelist is particularly unclear. blocklist is closer, but that's why I am suggesting allow or perhaps AllowOnly.
Heh, I'd been thinking about those terms, too. :-)
I think allow/deny makes a lot more sense. What is thought of allowed_metrics.conf and denied_metrics.conf
I'm block over deny but I don't have any strong argument for it. I just think blocked_metrics.conf sounds better than denied_metrics.conf.
Yes, I have no intention of ripping the carpet out from anyone. The idea is that the old files will still be allowed, but perhaps throw a deprecation message out to the logs?
I intend for the docs to reflect the change. Whitelist/Blacklist will be listed as pending deprecation (something to that effect), and directing people to use the new names.
Does allowed_metrics.conf + blocked_metrics.conf make sense?
Cool, yeah a startup message to the logs would be good.
Yes, those names make sense to me.
For reference, I'm replacing the general term (env vars, etc) USE_WHITELIST with USE_METRICSLIST.
It feels a little clunky, but I think it implies what we're going for. I'm open to a better name.
What uses the lists that graphite-web is able to add/remove from in graphite.whitelist?
I don't find anything that interacts with them besides the add/remove urls in composer. I find mentions of the whitelist lists in carbon, but didn't find where carbon uses the data (USE_WHITELIST and whitelist.conf and blacklist.conf are there, but different from what I can see)
Besides that, I don't believe the code in master works. The load_whitelist() method calls unpickle.load on a file handle. The unpickle class has no load method and the only method it does have is loads and that don't take a file handle as an argument.
Do we need the whitelist endpoint in graphite-web?
@cbowman0 I honestly wasn't sure if I was missing something, whether features I hadn't used or noticed, or that there was some by-convention references / magic.
I had wanted to play around with them while testing at home, but limited available time was exacerbated by a sysadmin yak-shave.
Could you clarify, @DaxDupont?
...Seriously?
Doesn't convey much other than you might be incredulous about something...
@DaxDupont Let's keep the conversation focused on the objective bits. Whether this should or shouldn't change isn't up for discussion.
The term "blacklist" is not racial at all but come from book bounded in black used by Henry VIII to listing monasteries to be dissolved.
@jpscaletti It doesn't matter what the original intent was. People do have a negative reaction to these terms. There is no justification for keeping it. Let's keep the discussion focused to the objective merits of the pull request.
I limited conversation here to collaborators. Is it OK, @obfuscurity ?
I didn't even know you could do that. Perfect.
I'd like to deprecate the "whitelist/blacklist" language in Graphite, replacing them with "safelist/blocklist". (Not a new or original idea; saw this at kickstarter/rack-attack#181.)
graphite-web and carbon are impacted.
I'm thinking that the internals could be incorporated immediately, the safe/block method interfaces become the implementation, where the white/black names log a deprecation warning (to be removed at a later date), and we read from both sets of files.
I'm guessing that the worst part will be reading in both white/black and safe/block lists and deduping them.
What do the other contributors think about this? I certainly don't own Graphite, and don't consider this a personal crusade, but I do see this as an opportunity to be more inclusive / less exclusionary.