Replace racially charged language "whitelist/blacklist"

[gwaldo]

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 rack/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.

[gwaldo]

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.

[bmhatfield]

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.

[gwaldo]

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

[obfuscurity]

I'm 💯 on this although the PR should aim to be backwards compatible with the old naming, at least as far as the code (not docs). As far as the new names, I prefer 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. 😝

[gwaldo]

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?

[obfuscurity]

Cool, yeah a startup message to the logs would be good.

Yes, those names make sense to me.

[gwaldo]

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.

[obfuscurity]

USE_METRIC_FILTERS ?

Jason Dixon
Sent from my iPhone

On Jul 2, 2016, at 5:27 PM, gwaldo [email protected] wrote:

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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[gwaldo]

That's better. Thanks, @obfuscurity.

[cbowman0]

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?

[gwaldo]

@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.

[DaxDupont]

...Seriously?

[gwaldo]

Could you clarify, @DaxDupont?

...Seriously?

Doesn't convey much other than you might be incredulous about something...

[obfuscurity]

@DaxDupont Let's keep the conversation focused on the objective bits. Whether this should or shouldn't change isn't up for discussion.

[ghost]

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.

[obfuscurity]

@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.

[obfuscurity]

As explained previously, please refrain to objective commentary on the proposed changes.

Jason Dixon
Sent from my iPhone

On Aug 3, 2016, at 6:40 PM, Juan-Pablo Scaletti [email protected] wrote:

"People"? Who are these people? Are they contributors or users of the project? How many people must have a negative reaction to a word (any word) to merit a change?

Also, if whether this shouldn't change isn't up for discussion... Why the issue is still open?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[deniszh]

I limited conversation here to collaborators. Is it OK, @obfuscurity ?

[obfuscurity]

I didn't even know you could do that. Perfect. 👍