The blacklist / master issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The blacklist / master issue

Tom Carrick
This ticket was closed wontfix as requiring a discussion here.

David Smith mentioned this Tox issue stating it had been closed, but to me it seems like it hasn't been closed (maybe there's something I can't see) and apparently a PR would be accepted to add aliases at the least (this is more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading this ZDNet article - it seems like Google have already made moves in this direction and GitHub is also planning to. Usually Django is somewhere near the front for these types of changes.

I'm leaning towards renaming the master branch and wherever else we use that terminology, but I'm less sure about black/whitelist, though right now it seems more positive than negative. Most arguments against use some kind of etymological argument, but I don't think debates about historical terms are as interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms somewhat reluctantly. I do think Luke is correct that we should be concerned with our credibility if we wrongly change this, but I'm also worried about our credibility if we don't.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Adam Johnson-2
I was preparing a post on this Tom, it was sitting in my drafts awaiting a little more research, but here we go.

My summary:

This small language change has been suggested many times in the technology sphere for two reasons. First, the allow/deny terms avoid the potentially offensive assocation of white = accept and black = reject. Second, the allow and deny are clearer to those who don't know them, reducing comprehension time and potential bugs.

Making this change in Django's documentation was originally suggested in a PR by David Smith in April: https://github.com/django/django/pull/12755 . Carlton and I closed the PR due to lack of discussion at the time. Carlton also brought up the argument that it can be useful to keep our terminology in line with RFC's.

Current context

I've seen this change supported a few times on Twitter recently, most notably by Django co-creator Simon Willison. I therefore opened the aforementioned ticket to revive the change.

We'd be far from alone in making this change. Here are some projects with some association to Django that have made the change
(The Google Developer style guide page on inclusive documentation is worth reading and I think we could have our own similar page of guidelines: https://developers.google.com/style/inclusive-documentation .)

Django has a history of being an open source project that updates its documentation to use more inclusive language. Six years ago we changed master/slave (databases) to leader/follower in https://github.com/django/django/pull/2692 . We lead the way here and other notable projects have cited Django in their own changes, such as Drupal ( https://www.drupal.org/project/drupal/issues/2275877 ).

I like Flavio's response on the ticket:
 I think all the etymological and linguist discussion detracts from the actual issue that we are trying to solve.

I would argue that it does not matter where words come from, or how we, the privileged people, interpret them. The only questions we need to answer are:

    Do these words makes Black people less welcome?
    Would replacing them be an improvement for them?

Then we can evaluate how hard it would be to change, and compare it to how much we value their experience.

Instead of focusing on logic and prior knowledge, let's focus on future developer experience.

I am not a linguistic expert nor do I know if anyone has actually found the language off-putting. But I do think there's evidence it has, and we should be trying to make our documentation as inclusive as possible.

I don't think the argument to keep aligned with RFC's holds much weight. There's a draft RFC to change the language there. If there's a big concern the new terms will not be fluent for existing developers, we can follow the pattern recommended by the Google inclusvie guide of using a commonly known but insensitive term in parentheses:

This might require you to fence failed nodes (sometimes referred to as STONITH).

That said, "allow list" is clearer than"white list" so I don't think this is likely to be a problem.

The PR is quite a small change and pretty much ready to be merged ( https://github.com/django/django/pull/13031 ). I don't think we need a big debate but judging from the previous master/slave change, there will be a lot of reactions (that PR is probably the most commented on Django change, with 719 comments).

On Mon, 15 Jun 2020 at 17:27, Tom Carrick <[hidden email]> wrote:
This ticket was closed wontfix as requiring a discussion here.

David Smith mentioned this Tox issue stating it had been closed, but to me it seems like it hasn't been closed (maybe there's something I can't see) and apparently a PR would be accepted to add aliases at the least (this is more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading this ZDNet article - it seems like Google have already made moves in this direction and GitHub is also planning to. Usually Django is somewhere near the front for these types of changes.

I'm leaning towards renaming the master branch and wherever else we use that terminology, but I'm less sure about black/whitelist, though right now it seems more positive than negative. Most arguments against use some kind of etymological argument, but I don't think debates about historical terms are as interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms somewhat reluctantly. I do think Luke is correct that we should be concerned with our credibility if we wrongly change this, but I'm also worried about our credibility if we don't.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.com.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1F3dRC9xaWWr47zbCfwDLEmspaTK3u%2Bf0%3DmcoRQ5%2B%3Dvw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Carlton Gibson-3
My initial response on the original PR was, looking it up, that “blacklist” wasn’t a race-related term. I then said, unless there are additional uses...

It seems there are. 

In which case this seems a no-brainer. We should use better words. That’s an easy change. 

+1

On Mon, 15 Jun 2020 at 19:05, Adam Johnson <[hidden email]> wrote:
I was preparing a post on this Tom, it was sitting in my drafts awaiting a little more research, but here we go.

My summary:

This small language change has been suggested many times in the technology sphere for two reasons. First, the allow/deny terms avoid the potentially offensive assocation of white = accept and black = reject. Second, the allow and deny are clearer to those who don't know them, reducing comprehension time and potential bugs.

Making this change in Django's documentation was originally suggested in a PR by David Smith in April: https://github.com/django/django/pull/12755 . Carlton and I closed the PR due to lack of discussion at the time. Carlton also brought up the argument that it can be useful to keep our terminology in line with RFC's.

Current context

I've seen this change supported a few times on Twitter recently, most notably by Django co-creator Simon Willison. I therefore opened the aforementioned ticket to revive the change.

We'd be far from alone in making this change. Here are some projects with some association to Django that have made the change
(The Google Developer style guide page on inclusive documentation is worth reading and I think we could have our own similar page of guidelines: https://developers.google.com/style/inclusive-documentation .)

Django has a history of being an open source project that updates its documentation to use more inclusive language. Six years ago we changed master/slave (databases) to leader/follower in https://github.com/django/django/pull/2692 . We lead the way here and other notable projects have cited Django in their own changes, such as Drupal ( https://www.drupal.org/project/drupal/issues/2275877 ).

I like Flavio's response on the ticket:
 I think all the etymological and linguist discussion detracts from the actual issue that we are trying to solve.

I would argue that it does not matter where words come from, or how we, the privileged people, interpret them. The only questions we need to answer are:

    Do these words makes Black people less welcome?
    Would replacing them be an improvement for them?

Then we can evaluate how hard it would be to change, and compare it to how much we value their experience.

Instead of focusing on logic and prior knowledge, let's focus on future developer experience.

I am not a linguistic expert nor do I know if anyone has actually found the language off-putting. But I do think there's evidence it has, and we should be trying to make our documentation as inclusive as possible.

I don't think the argument to keep aligned with RFC's holds much weight. There's a draft RFC to change the language there. If there's a big concern the new terms will not be fluent for existing developers, we can follow the pattern recommended by the Google inclusvie guide of using a commonly known but insensitive term in parentheses:

This might require you to fence failed nodes (sometimes referred to as STONITH).

That said, "allow list" is clearer than"white list" so I don't think this is likely to be a problem.

The PR is quite a small change and pretty much ready to be merged ( https://github.com/django/django/pull/13031 ). I don't think we need a big debate but judging from the previous master/slave change, there will be a lot of reactions (that PR is probably the most commented on Django change, with 719 comments).

On Mon, 15 Jun 2020 at 17:27, Tom Carrick <[hidden email]> wrote:
This ticket was closed wontfix as requiring a discussion here.

David Smith mentioned this Tox issue stating it had been closed, but to me it seems like it hasn't been closed (maybe there's something I can't see) and apparently a PR would be accepted to add aliases at the least (this is more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading this ZDNet article - it seems like Google have already made moves in this direction and GitHub is also planning to. Usually Django is somewhere near the front for these types of changes.

I'm leaning towards renaming the master branch and wherever else we use that terminology, but I'm less sure about black/whitelist, though right now it seems more positive than negative. Most arguments against use some kind of etymological argument, but I don't think debates about historical terms are as interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms somewhat reluctantly. I do think Luke is correct that we should be concerned with our credibility if we wrongly change this, but I'm also worried about our credibility if we don't.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.com.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1F3dRC9xaWWr47zbCfwDLEmspaTK3u%2Bf0%3DmcoRQ5%2B%3Dvw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJwKpyQC9G%3Ddz2m2s5%3DooYhC65c_Zz6gwfLV29upNSW%3DPUaGLA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Kenneth Love
In reply to this post by Tom Carrick
I don't participate in this list much but this is a solid +1 from me. We should do our best to adopt neutral language. Etymology/history is important, yes, but much less important that current impact and usage.

On Monday, June 15, 2020 at 9:28:23 AM UTC-7, Tom Carrick wrote:
<a href="https://code.djangoproject.com/ticket/31670#ticket" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F31670%23ticket\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnF_lIHM-_zehMarFCEOsi0k6sLg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F31670%23ticket\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnF_lIHM-_zehMarFCEOsi0k6sLg&#39;;return true;">This ticket was closed wontfix as requiring a discussion here.

David Smith mentioned <a href="https://github.com/tox-dev/tox/issues/1491" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftox-dev%2Ftox%2Fissues%2F1491\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGmkPJOdkZcwHLnEA95NCUNGhJHBA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftox-dev%2Ftox%2Fissues%2F1491\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGmkPJOdkZcwHLnEA95NCUNGhJHBA&#39;;return true;">this Tox issue stating it had been closed, but to me it seems like it hasn't been closed (maybe there's something I can't see) and apparently a PR would be accepted to add aliases at the least (this is more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading <a href="https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.zdnet.com%2Farticle%2Fgithub-to-replace-master-with-alternative-term-to-avoid-slavery-references%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHN9IG6hm2roGUTvA1F-D2DFzil5Q&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.zdnet.com%2Farticle%2Fgithub-to-replace-master-with-alternative-term-to-avoid-slavery-references%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHN9IG6hm2roGUTvA1F-D2DFzil5Q&#39;;return true;">this ZDNet article - it seems like Google have already made moves in this direction and GitHub is also planning to. Usually Django is somewhere near the front for these types of changes.

I'm leaning towards renaming the master branch and wherever else we use that terminology, but I'm less sure about black/whitelist, though right now it seems more positive than negative. Most arguments against use some kind of etymological argument, but I don't think debates about historical terms are as interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms somewhat reluctantly. I do think Luke is correct that we should be concerned with our credibility if we wrongly change this, but I'm also worried about our credibility if we don't.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e953efe9-2d14-4256-ae8c-7bee4a0ac4c2o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

René Fleschenberg
In reply to this post by Tom Carrick
Hi,

just my 2 cents:

While I am generally critical of changing language to achieve social
progress, I see no harm in using "main", "develop" or something like
that instead of "master". There might be a tool or two out there that
treat "master" specially, but I can't think of anything that would
directly affect Django. If Github is going to settle for "main", it will
likely become the new convention, so maybe Django should pick that one?

allow_list / deny_list is a similar case. I see no advantage in keeping
the current names. To me, allow_list / deny_list is at least as clear as
white_list / black_list.

When Django directly references externally defined technical terms (e.g.
underlying APIs), I think more consideration is needed. For RFC 5782, I
think that is not the case.

Regards,
René

--
René Fleschenberg

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7d0f24b3-e042-0964-6be0-6689fc930af1%40fleschenberg.net.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Daniele Procida-3
In reply to this post by Tom Carrick
Tom Carrick wrote:

>I don't think there is an easy answer here, and I open this can of worms
>somewhat reluctantly. I do think Luke is correct that we should be
>concerned with our credibility if we wrongly change this, but I'm also
>worried about our credibility if we don't.

There are plenty of black-something terms in English that are both negative and have nothing whatsoever to do with race. The black and the dark are those things that are hidden and sinister, as contrasted with those that are in the light and open to scrutiny (black magic, dark arts, black legs, blackguards, blackmail, etc).

I think it would look pretty silly to confuse meanings that refer to what's shadowy and obscure with things that have racial overtones, and I think we should steer well clear of that. It's not at all like metaphors such as master/slave.

If we made such a change and tried to justify it on the grounds of a connection between race and the word "black" in those terms, we'd be rightly laughed at.

1000 neckbeards would immediately come out of the woodwork having done some basic web searches going 'neeer neeer neeer, the Django Software Foundation overflowing with snowflakes who think that "blacklist" means [etc etc etc]', and who has the stomach for that?

Even choosing to do it on the basis of the potential for offence seems to be a fairly flimsy argument.

On the other hand, we can do whatever the hell we like.

We don't have to justify anything to anyone. If we want to change words in *our* framework, it's absolutely nobody's business but our own.

If black members of the DSF or the community are disheartened that the word "black" gets to refer to so many negative things and are bothered when they see them in Django, then that alone is sufficient justification.

If we want a reason for changing "blacklist" (or whatever), it's that people in our community said they would feel better about it and asked to have it changed.

Acknowledging how someone feels about something and acting because you care about their feelings seems to be a respectful thing to do.

"We did it because we felt like it" is an utterly unanswerable justification.

The DSF has credibility because the software is first rate, the foundation is well-governed and the community is an international example of decency and kindness. Things like this become credible because the DSF chooses to do them - it's not the other way round.

Daniele

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Drew Winstel

On Monday, June 15, 2020 at 2:56:45 PM UTC-5, Daniele Procida wrote:
We don't have to justify anything to anyone. If we want to change words in *our* framework, it's absolutely nobody's business but our own.

If black members of the DSF or the community are disheartened that the word "black" gets to refer to so many negative things and are bothered when they see them in Django, then that alone is sufficient justification.

If we want a reason for changing "blacklist" (or whatever), it's that people in our community said they would feel better about it and asked to have it changed.

Acknowledging how someone feels about something and acting because you care about their feelings seems to be a respectful thing to do.

"We did it because we felt like it" is an utterly unanswerable justification.

The DSF has credibility because the software is first rate, the foundation is well-governed and the community is an international example of decency and kindness. Things like this become credible because the DSF chooses to do them - it's not the other way round.


Strong +1 to this. Very well put, Daniele. 

Drew

(2019 DjangoCon US Opportunity Grants Chair, for those who may not know me)

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4337e473-a20b-4067-b479-7420e5e504dao%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Markus Holtermann
In reply to this post by Daniele Procida-3
I'd be in favor of changing blacklist/whitelist into something that makes sense. In many cases, that's going to be context dependent, but often blocklist/allowlist will work.

With regards to "master" as the development branch on GitHub, I'd like to pick whatever GitHub eventually goes with as a "new default".

Cheers,

Markus

On Mon, Jun 15, 2020, at 9:56 PM, Daniele Procida wrote:

> Tom Carrick wrote:
>
> >I don't think there is an easy answer here, and I open this can of worms
> >somewhat reluctantly. I do think Luke is correct that we should be
> >concerned with our credibility if we wrongly change this, but I'm also
> >worried about our credibility if we don't.
>
> There are plenty of black-something terms in English that are both
> negative and have nothing whatsoever to do with race. The black and the
> dark are those things that are hidden and sinister, as contrasted with
> those that are in the light and open to scrutiny (black magic, dark
> arts, black legs, blackguards, blackmail, etc).
>
> I think it would look pretty silly to confuse meanings that refer to
> what's shadowy and obscure with things that have racial overtones, and
> I think we should steer well clear of that. It's not at all like
> metaphors such as master/slave.
>
> If we made such a change and tried to justify it on the grounds of a
> connection between race and the word "black" in those terms, we'd be
> rightly laughed at.
>
> 1000 neckbeards would immediately come out of the woodwork having done
> some basic web searches going 'neeer neeer neeer, the Django Software
> Foundation overflowing with snowflakes who think that "blacklist" means
> [etc etc etc]', and who has the stomach for that?
>
> Even choosing to do it on the basis of the potential for offence seems
> to be a fairly flimsy argument.
>
> On the other hand, we can do whatever the hell we like.
>
> We don't have to justify anything to anyone. If we want to change words
> in *our* framework, it's absolutely nobody's business but our own.
>
> If black members of the DSF or the community are disheartened that the
> word "black" gets to refer to so many negative things and are bothered
> when they see them in Django, then that alone is sufficient
> justification.
>
> If we want a reason for changing "blacklist" (or whatever), it's that
> people in our community said they would feel better about it and asked
> to have it changed.
>
> Acknowledging how someone feels about something and acting because you
> care about their feelings seems to be a respectful thing to do.
>
> "We did it because we felt like it" is an utterly unanswerable justification.
>
> The DSF has credibility because the software is first rate, the
> foundation is well-governed and the community is an international
> example of decency and kindness. Things like this become credible
> because the DSF chooses to do them - it's not the other way round.
>
> Daniele
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.
>

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/64e1b503-289c-4119-acfc-51fe6537addb%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Aymeric Augustin
In reply to this post by Daniele Procida-3
Hello,

In the context of access control, blacklist / whitelist makes sense only if the reader has a preconceived assumption that black = bad, illegal, forbidden / white = good, legal, authorized. You can probably see where I'm going.

Sure, blacklist / whitelist has nothing to do with race to start with, but I find the parallel with Apartheid sufficiently obvious to make it embarrassing, certainly because I'm not a native English speaker and I don't have enough background on what has racial overtones and what doesn't.

I mean, I had been living in the US for several months whet someone had to tell me the difference between "to screw" and "to screw up". (I'm grateful.) Do you really expect a guy like me to know that "blackface" has racial overtones but "blacklist" doesn't, and thus interpret the words correctly?

Besides, the connection didn't exist in the first place, but when people start making it, can we still pretend it doesn't exist? If I wanted to troll a linguist, I'd say it's akin to pretending that words people actually use don't exist until they're written in a dictionary ;-)

Lastly, another argument for the statu quo is that humans are good at interpreting words based on context, so "black" in "blacklist" isn't a problem. However, I counter that humans are even better at making connections and detecting patterns, even subconsciously and sometimes even when the pattern doesn't actually exist. That's quite likely to happen here.

I agree that this isn't as clear cut as master / slave. That must be why it took us six years to go from the master / slave discussion to the blacklist / whitelist discussion.

No one's gonna get confused on the meaning regardless of whether we make the change or not. This is "just" a political marker. It doesn't have one correct answer. It has several answers whose correctness vary over time.

I think we'll make the change at some point. Some progressives will hate us for taking so much time. Some conservatives will hate us for being snowflakes. Since we already started spending time on this discussion, we might just as well do the change while we're there, take some flak for a couple days, and move on.

Best regards,

-- 
Aymeric.

On 15 Jun 2020, at 21:56, Daniele Procida <[hidden email]> wrote:

Tom Carrick wrote:

I don't think there is an easy answer here, and I open this can of worms
somewhat reluctantly. I do think Luke is correct that we should be
concerned with our credibility if we wrongly change this, but I'm also
worried about our credibility if we don't.

There are plenty of black-something terms in English that are both negative and have nothing whatsoever to do with race. The black and the dark are those things that are hidden and sinister, as contrasted with those that are in the light and open to scrutiny (black magic, dark arts, black legs, blackguards, blackmail, etc).

I think it would look pretty silly to confuse meanings that refer to what's shadowy and obscure with things that have racial overtones, and I think we should steer well clear of that. It's not at all like metaphors such as master/slave.

If we made such a change and tried to justify it on the grounds of a connection between race and the word "black" in those terms, we'd be rightly laughed at.

1000 neckbeards would immediately come out of the woodwork having done some basic web searches going 'neeer neeer neeer, the Django Software Foundation overflowing with snowflakes who think that "blacklist" means [etc etc etc]', and who has the stomach for that?

Even choosing to do it on the basis of the potential for offence seems to be a fairly flimsy argument.

On the other hand, we can do whatever the hell we like.

We don't have to justify anything to anyone. If we want to change words in *our* framework, it's absolutely nobody's business but our own.

If black members of the DSF or the community are disheartened that the word "black" gets to refer to so many negative things and are bothered when they see them in Django, then that alone is sufficient justification.

If we want a reason for changing "blacklist" (or whatever), it's that people in our community said they would feel better about it and asked to have it changed.

Acknowledging how someone feels about something and acting because you care about their feelings seems to be a respectful thing to do.

"We did it because we felt like it" is an utterly unanswerable justification.

The DSF has credibility because the software is first rate, the foundation is well-governed and the community is an international example of decency and kindness. Things like this become credible because the DSF chooses to do them - it's not the other way round.

Daniele

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4FC8DDEB-2A3C-4B31-9265-D07F28D6CFCA%40polytechnique.org.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Ngazetungue Muheue-2
In reply to this post by Tom Carrick

The Django it is a community framework and we have to pay attention to that. History play a major role in our daily lives and we have to avoid any word that have racial connection. Django community is growing fast in Africa and we hate things that taking us back to Apartheid/Slave era since we believe in spirit of Ubuntu.


If the black community think certain words in English make them feel less welcome and they can justify that, please let’s change it or simply we can do whatever we like to our framework. We don't have to justify anything to anyone, we’re doing what we think it is best for our community and future Developers. Personally I think we should do our best to adopt neutral language that would be accepted by our community of black, white or whatsoever.


Words like Blacklist should be avoid at all cost. I would go for deny list or deny instead of Blacklist and Allow list or accept instead of White-list.


At beginning I was bothered by the word Blacklist until I get use to it, we don’t use it at the region where I came from because of the history. Let’s make the documentation more inclusive, and clearer. If there is something that needs to be changed let’s just do it while it is early.


--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/508a4a79-97d9-4cda-bcfe-9deaf430abc9o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Curtis Maloney-2
In reply to this post by Tom Carrick
Just my small contribution to the discussion...

Independent of "social" aspects to the choice of words, the move towards "self explanatory terminology" is preferable, IMHO.

As an example, it takes less mental effort or historical context to know what an "allow_list" is compared to a "whitelist".

Same argument was involved in changing the terminology we used for replicated databases. It made sense then, it makes sense now.

--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a4ce1855-8974-4eed-9121-99983e8cf742%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Jeff Triplett-2

Agreed. I thought DHH's argument was equally as compelling for making this change for rails: 

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.



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dcdbf5dd-edb9-443f-a24d-9cd0e05441d7o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Jorge Gimeno
In reply to this post by Tom Carrick
I would suggest that this a relatively small change that would provide the community with a large return in being more inclusive.

-Jorge

On Monday, June 15, 2020 at 9:28:23 AM UTC-7, Tom Carrick wrote:
<a href="https://code.djangoproject.com/ticket/31670#ticket" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F31670%23ticket\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnF_lIHM-_zehMarFCEOsi0k6sLg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F31670%23ticket\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnF_lIHM-_zehMarFCEOsi0k6sLg&#39;;return true;">This ticket was closed wontfix as requiring a discussion here.

David Smith mentioned <a href="https://github.com/tox-dev/tox/issues/1491" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftox-dev%2Ftox%2Fissues%2F1491\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGmkPJOdkZcwHLnEA95NCUNGhJHBA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftox-dev%2Ftox%2Fissues%2F1491\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGmkPJOdkZcwHLnEA95NCUNGhJHBA&#39;;return true;">this Tox issue stating it had been closed, but to me it seems like it hasn't been closed (maybe there's something I can't see) and apparently a PR would be accepted to add aliases at the least (this is more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading <a href="https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.zdnet.com%2Farticle%2Fgithub-to-replace-master-with-alternative-term-to-avoid-slavery-references%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHN9IG6hm2roGUTvA1F-D2DFzil5Q&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.zdnet.com%2Farticle%2Fgithub-to-replace-master-with-alternative-term-to-avoid-slavery-references%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHN9IG6hm2roGUTvA1F-D2DFzil5Q&#39;;return true;">this ZDNet article - it seems like Google have already made moves in this direction and GitHub is also planning to. Usually Django is somewhere near the front for these types of changes.

I'm leaning towards renaming the master branch and wherever else we use that terminology, but I'm less sure about black/whitelist, though right now it seems more positive than negative. Most arguments against use some kind of etymological argument, but I don't think debates about historical terms are as interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms somewhat reluctantly. I do think Luke is correct that we should be concerned with our credibility if we wrongly change this, but I'm also worried about our credibility if we don't.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ee566c2b-28c5-4845-ba94-9f9c4fe5c035o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Jure Erznožnik-2
In reply to this post by Aymeric Augustin

+1 on this discussion progression. I too struggled with certain expressions in my earlier English-learning days, but today the used expressions don't carry any unnecessary baggage for me as my understanding of them is purely technical. So, while I myself don't have a problem with them, I can see that others might.

I'd also dare to say there shouldn't be much flak to take anyway. The cause seems OK, but there is heightened pressure due to recent events. I would say this alone is the only thing that I see might be an issue: why exactly now?

LP,
Jure

On 15/06/2020 23:31, Aymeric Augustin wrote:
Hello,

In the context of access control, blacklist / whitelist makes sense only if the reader has a preconceived assumption that black = bad, illegal, forbidden / white = good, legal, authorized. You can probably see where I'm going.

Sure, blacklist / whitelist has nothing to do with race to start with, but I find the parallel with Apartheid sufficiently obvious to make it embarrassing, certainly because I'm not a native English speaker and I don't have enough background on what has racial overtones and what doesn't.

I mean, I had been living in the US for several months whet someone had to tell me the difference between "to screw" and "to screw up". (I'm grateful.) Do you really expect a guy like me to know that "blackface" has racial overtones but "blacklist" doesn't, and thus interpret the words correctly?

Besides, the connection didn't exist in the first place, but when people start making it, can we still pretend it doesn't exist? If I wanted to troll a linguist, I'd say it's akin to pretending that words people actually use don't exist until they're written in a dictionary ;-)

Lastly, another argument for the statu quo is that humans are good at interpreting words based on context, so "black" in "blacklist" isn't a problem. However, I counter that humans are even better at making connections and detecting patterns, even subconsciously and sometimes even when the pattern doesn't actually exist. That's quite likely to happen here.

I agree that this isn't as clear cut as master / slave. That must be why it took us six years to go from the master / slave discussion to the blacklist / whitelist discussion.

No one's gonna get confused on the meaning regardless of whether we make the change or not. This is "just" a political marker. It doesn't have one correct answer. It has several answers whose correctness vary over time.

I think we'll make the change at some point. Some progressives will hate us for taking so much time. Some conservatives will hate us for being snowflakes. Since we already started spending time on this discussion, we might just as well do the change while we're there, take some flak for a couple days, and move on.

Best regards,

-- 
Aymeric.

On 15 Jun 2020, at 21:56, Daniele Procida <[hidden email]> wrote:

Tom Carrick wrote:

I don't think there is an easy answer here, and I open this can of worms
somewhat reluctantly. I do think Luke is correct that we should be
concerned with our credibility if we wrongly change this, but I'm also
worried about our credibility if we don't.

There are plenty of black-something terms in English that are both negative and have nothing whatsoever to do with race. The black and the dark are those things that are hidden and sinister, as contrasted with those that are in the light and open to scrutiny (black magic, dark arts, black legs, blackguards, blackmail, etc).

I think it would look pretty silly to confuse meanings that refer to what's shadowy and obscure with things that have racial overtones, and I think we should steer well clear of that. It's not at all like metaphors such as master/slave.

If we made such a change and tried to justify it on the grounds of a connection between race and the word "black" in those terms, we'd be rightly laughed at.

1000 neckbeards would immediately come out of the woodwork having done some basic web searches going 'neeer neeer neeer, the Django Software Foundation overflowing with snowflakes who think that "blacklist" means [etc etc etc]', and who has the stomach for that?

Even choosing to do it on the basis of the potential for offence seems to be a fairly flimsy argument.

On the other hand, we can do whatever the hell we like.

We don't have to justify anything to anyone. If we want to change words in *our* framework, it's absolutely nobody's business but our own.

If black members of the DSF or the community are disheartened that the word "black" gets to refer to so many negative things and are bothered when they see them in Django, then that alone is sufficient justification.

If we want a reason for changing "blacklist" (or whatever), it's that people in our community said they would feel better about it and asked to have it changed.

Acknowledging how someone feels about something and acting because you care about their feelings seems to be a respectful thing to do.

"We did it because we felt like it" is an utterly unanswerable justification.

The DSF has credibility because the software is first rate, the foundation is well-governed and the community is an international example of decency and kindness. Things like this become credible because the DSF chooses to do them - it's not the other way round.

Daniele

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4FC8DDEB-2A3C-4B31-9265-D07F28D6CFCA%40polytechnique.org.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a78ec9c-4837-fb3b-6aa6-9497def4de65%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Claude Paroz
In reply to this post by Tom Carrick
Note that the term "blacklist" only appears twice in the Django tree and only in comments/docs, as shown by David's patch. The first one can be omitted while the second one can be replaced by "exclude". That is trivial to do and shouldn't even require a discussion.

About replacing "whitelist" par "allowlist", I'm not totally convinced but will accept any community decision. It has a very small impact change in code (in EmailValidator).

Changing git "master" branch names is really looking ridiculous to me, but I can understand that it might be linked to cultural sensibilities. This will generate many work overhead, for what gain? A "master" is a totally valid word in many contexts that have nothing to do with slavery.
We should primarily fight against racism by education and our own day-to-day behavior.

Claude

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d327c497-18f7-4b50-8b38-93b0c0bea330o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Sanskar Jaiswal
In reply to this post by Jure Erznožnik-2
Just my 2 cents on this discussion as a junior contributor. I am very fond of how inclusive and progressive the Django community is.
With that said, I believe that we shall definitely try to stop using the term blacklist for “bad/unwanted” things. If this change makes even only a few contributors, more comfortable, I think we should move forward with the same.

Thanks
Sanskar

On Tue, 16 Jun 2020 at 12:30, Jure Erznožnik <[hidden email]> wrote:

+1 on this discussion progression. I too struggled with certain expressions in my earlier English-learning days, but today the used expressions don't carry any unnecessary baggage for me as my understanding of them is purely technical. So, while I myself don't have a problem with them, I can see that others might.

I'd also dare to say there shouldn't be much flak to take anyway. The cause seems OK, but there is heightened pressure due to recent events. I would say this alone is the only thing that I see might be an issue: why exactly now?

LP,
Jure

On 15/06/2020 23:31, Aymeric Augustin wrote:
Hello,

In the context of access control, blacklist / whitelist makes sense only if the reader has a preconceived assumption that black = bad, illegal, forbidden / white = good, legal, authorized. You can probably see where I'm going.

Sure, blacklist / whitelist has nothing to do with race to start with, but I find the parallel with Apartheid sufficiently obvious to make it embarrassing, certainly because I'm not a native English speaker and I don't have enough background on what has racial overtones and what doesn't.

I mean, I had been living in the US for several months whet someone had to tell me the difference between "to screw" and "to screw up". (I'm grateful.) Do you really expect a guy like me to know that "blackface" has racial overtones but "blacklist" doesn't, and thus interpret the words correctly?

Besides, the connection didn't exist in the first place, but when people start making it, can we still pretend it doesn't exist? If I wanted to troll a linguist, I'd say it's akin to pretending that words people actually use don't exist until they're written in a dictionary ;-)

Lastly, another argument for the statu quo is that humans are good at interpreting words based on context, so "black" in "blacklist" isn't a problem. However, I counter that humans are even better at making connections and detecting patterns, even subconsciously and sometimes even when the pattern doesn't actually exist. That's quite likely to happen here.

I agree that this isn't as clear cut as master / slave. That must be why it took us six years to go from the master / slave discussion to the blacklist / whitelist discussion.

No one's gonna get confused on the meaning regardless of whether we make the change or not. This is "just" a political marker. It doesn't have one correct answer. It has several answers whose correctness vary over time.

I think we'll make the change at some point. Some progressives will hate us for taking so much time. Some conservatives will hate us for being snowflakes. Since we already started spending time on this discussion, we might just as well do the change while we're there, take some flak for a couple days, and move on.

Best regards,

-- 
Aymeric.

On 15 Jun 2020, at 21:56, Daniele Procida <[hidden email]> wrote:

Tom Carrick wrote:

I don't think there is an easy answer here, and I open this can of worms
somewhat reluctantly. I do think Luke is correct that we should be
concerned with our credibility if we wrongly change this, but I'm also
worried about our credibility if we don't.

There are plenty of black-something terms in English that are both negative and have nothing whatsoever to do with race. The black and the dark are those things that are hidden and sinister, as contrasted with those that are in the light and open to scrutiny (black magic, dark arts, black legs, blackguards, blackmail, etc).

I think it would look pretty silly to confuse meanings that refer to what's shadowy and obscure with things that have racial overtones, and I think we should steer well clear of that. It's not at all like metaphors such as master/slave.

If we made such a change and tried to justify it on the grounds of a connection between race and the word "black" in those terms, we'd be rightly laughed at.

1000 neckbeards would immediately come out of the woodwork having done some basic web searches going 'neeer neeer neeer, the Django Software Foundation overflowing with snowflakes who think that "blacklist" means [etc etc etc]', and who has the stomach for that?

Even choosing to do it on the basis of the potential for offence seems to be a fairly flimsy argument.

On the other hand, we can do whatever the hell we like.

We don't have to justify anything to anyone. If we want to change words in *our* framework, it's absolutely nobody's business but our own.

If black members of the DSF or the community are disheartened that the word "black" gets to refer to so many negative things and are bothered when they see them in Django, then that alone is sufficient justification.

If we want a reason for changing "blacklist" (or whatever), it's that people in our community said they would feel better about it and asked to have it changed.

Acknowledging how someone feels about something and acting because you care about their feelings seems to be a respectful thing to do.

"We did it because we felt like it" is an utterly unanswerable justification.

The DSF has credibility because the software is first rate, the foundation is well-governed and the community is an international example of decency and kindness. Things like this become credible because the DSF chooses to do them - it's not the other way round.

Daniele

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4FC8DDEB-2A3C-4B31-9265-D07F28D6CFCA%40polytechnique.org.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a78ec9c-4837-fb3b-6aa6-9497def4de65%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DFO56Vqy5TCqMw2DzC_0pV1LwfE%3D92umuGqnvks0wR90g%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Fran Hrženjak
Meaning "owner of slaves" is only one of many meanings of the word, and not its primary meaning:


Renaming the master branch would mean we agree that this one meaning is somehow more important and should be elevated above all other meanings. Even though some of those other meanings apply much more closely in the case of git branches:

> "having chief authority, dominant"
> "an original from which copies can be made"

To me this looks like a final revenge of the slavers. They are all long dead and gone, their social order destroyed and condemned as it should be, and yet here we are in 2020 giving up useful words as if only the savers' use was correct and the rest of us were wrong ever since.

Master/slave database, that is (was) a completely different argument. But please let's keep the master branch.

Even if the change is simple for Django and for its users, somebody made a great point recently (on another topic here) that we cannot change the internet. There are numerous references to "master" out there which will become obsolete and a tripping stone for newcomers.

-0 from me.

 * What about everyones' master's degrees?
 * If a dog can have a master, then surely git branches can have a master branch.
 * Rembrandt was a master painter.
 * Related words: masterpiece, masterful, mastery, remastered (movies), mistress...

-- 
Fran


On Tue, 16 Jun 2020 at 09:10, Sanskar Jaiswal <[hidden email]> wrote:
Just my 2 cents on this discussion as a junior contributor. I am very fond of how inclusive and progressive the Django community is.
With that said, I believe that we shall definitely try to stop using the term blacklist for “bad/unwanted” things. If this change makes even only a few contributors, more comfortable, I think we should move forward with the same.

Thanks
Sanskar

On Tue, 16 Jun 2020 at 12:30, Jure Erznožnik <[hidden email]> wrote:

+1 on this discussion progression. I too struggled with certain expressions in my earlier English-learning days, but today the used expressions don't carry any unnecessary baggage for me as my understanding of them is purely technical. So, while I myself don't have a problem with them, I can see that others might.

I'd also dare to say there shouldn't be much flak to take anyway. The cause seems OK, but there is heightened pressure due to recent events. I would say this alone is the only thing that I see might be an issue: why exactly now?

LP,
Jure

On 15/06/2020 23:31, Aymeric Augustin wrote:
Hello,

In the context of access control, blacklist / whitelist makes sense only if the reader has a preconceived assumption that black = bad, illegal, forbidden / white = good, legal, authorized. You can probably see where I'm going.

Sure, blacklist / whitelist has nothing to do with race to start with, but I find the parallel with Apartheid sufficiently obvious to make it embarrassing, certainly because I'm not a native English speaker and I don't have enough background on what has racial overtones and what doesn't.

I mean, I had been living in the US for several months whet someone had to tell me the difference between "to screw" and "to screw up". (I'm grateful.) Do you really expect a guy like me to know that "blackface" has racial overtones but "blacklist" doesn't, and thus interpret the words correctly?

Besides, the connection didn't exist in the first place, but when people start making it, can we still pretend it doesn't exist? If I wanted to troll a linguist, I'd say it's akin to pretending that words people actually use don't exist until they're written in a dictionary ;-)

Lastly, another argument for the statu quo is that humans are good at interpreting words based on context, so "black" in "blacklist" isn't a problem. However, I counter that humans are even better at making connections and detecting patterns, even subconsciously and sometimes even when the pattern doesn't actually exist. That's quite likely to happen here.

I agree that this isn't as clear cut as master / slave. That must be why it took us six years to go from the master / slave discussion to the blacklist / whitelist discussion.

No one's gonna get confused on the meaning regardless of whether we make the change or not. This is "just" a political marker. It doesn't have one correct answer. It has several answers whose correctness vary over time.

I think we'll make the change at some point. Some progressives will hate us for taking so much time. Some conservatives will hate us for being snowflakes. Since we already started spending time on this discussion, we might just as well do the change while we're there, take some flak for a couple days, and move on.

Best regards,

-- 
Aymeric.

On 15 Jun 2020, at 21:56, Daniele Procida <[hidden email]> wrote:

Tom Carrick wrote:

I don't think there is an easy answer here, and I open this can of worms
somewhat reluctantly. I do think Luke is correct that we should be
concerned with our credibility if we wrongly change this, but I'm also
worried about our credibility if we don't.

There are plenty of black-something terms in English that are both negative and have nothing whatsoever to do with race. The black and the dark are those things that are hidden and sinister, as contrasted with those that are in the light and open to scrutiny (black magic, dark arts, black legs, blackguards, blackmail, etc).

I think it would look pretty silly to confuse meanings that refer to what's shadowy and obscure with things that have racial overtones, and I think we should steer well clear of that. It's not at all like metaphors such as master/slave.

If we made such a change and tried to justify it on the grounds of a connection between race and the word "black" in those terms, we'd be rightly laughed at.

1000 neckbeards would immediately come out of the woodwork having done some basic web searches going 'neeer neeer neeer, the Django Software Foundation overflowing with snowflakes who think that "blacklist" means [etc etc etc]', and who has the stomach for that?

Even choosing to do it on the basis of the potential for offence seems to be a fairly flimsy argument.

On the other hand, we can do whatever the hell we like.

We don't have to justify anything to anyone. If we want to change words in *our* framework, it's absolutely nobody's business but our own.

If black members of the DSF or the community are disheartened that the word "black" gets to refer to so many negative things and are bothered when they see them in Django, then that alone is sufficient justification.

If we want a reason for changing "blacklist" (or whatever), it's that people in our community said they would feel better about it and asked to have it changed.

Acknowledging how someone feels about something and acting because you care about their feelings seems to be a respectful thing to do.

"We did it because we felt like it" is an utterly unanswerable justification.

The DSF has credibility because the software is first rate, the foundation is well-governed and the community is an international example of decency and kindness. Things like this become credible because the DSF chooses to do them - it's not the other way round.

Daniele

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4FC8DDEB-2A3C-4B31-9265-D07F28D6CFCA%40polytechnique.org.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a78ec9c-4837-fb3b-6aa6-9497def4de65%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DFO56Vqy5TCqMw2DzC_0pV1LwfE%3D92umuGqnvks0wR90g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAM2o%3DwNre_3k6fsWMiF6xdq5%2Bo2Pky5-g5a31Ye%3DOqn8XoBRFw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Kye Russell
Git’s default branch name is a bit of a misnomer, however it refers to a master-slave relationship: https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html

Kye


On 16 June 2020 at 4:24:32 pm, Fran Hrženjak ([hidden email]) wrote:

Meaning "owner of slaves" is only one of many meanings of the word, and not its primary meaning:


Renaming the master branch would mean we agree that this one meaning is somehow more important and should be elevated above all other meanings. Even though some of those other meanings apply much more closely in the case of git branches:

> "having chief authority, dominant"
> "an original from which copies can be made"

To me this looks like a final revenge of the slavers. They are all long dead and gone, their social order destroyed and condemned as it should be, and yet here we are in 2020 giving up useful words as if only the savers' use was correct and the rest of us were wrong ever since.

Master/slave database, that is (was) a completely different argument. But please let's keep the master branch.

Even if the change is simple for Django and for its users, somebody made a great point recently (on another topic here) that we cannot change the internet. There are numerous references to "master" out there which will become obsolete and a tripping stone for newcomers.

-0 from me.

 * What about everyones' master's degrees?
 * If a dog can have a master, then surely git branches can have a master branch.
 * Rembrandt was a master painter.
 * Related words: masterpiece, masterful, mastery, remastered (movies), mistress...

-- 
Fran


On Tue, 16 Jun 2020 at 09:10, Sanskar Jaiswal <[hidden email]> wrote:
Just my 2 cents on this discussion as a junior contributor. I am very fond of how inclusive and progressive the Django community is.
With that said, I believe that we shall definitely try to stop using the term blacklist for “bad/unwanted” things. If this change makes even only a few contributors, more comfortable, I think we should move forward with the same.

Thanks
Sanskar

On Tue, 16 Jun 2020 at 12:30, Jure Erznožnik <[hidden email]> wrote:

+1 on this discussion progression. I too struggled with certain expressions in my earlier English-learning days, but today the used expressions don't carry any unnecessary baggage for me as my understanding of them is purely technical. So, while I myself don't have a problem with them, I can see that others might.

I'd also dare to say there shouldn't be much flak to take anyway. The cause seems OK, but there is heightened pressure due to recent events. I would say this alone is the only thing that I see might be an issue: why exactly now?

LP,
Jure

On 15/06/2020 23:31, Aymeric Augustin wrote:
Hello,

In the context of access control, blacklist / whitelist makes sense only if the reader has a preconceived assumption that black = bad, illegal, forbidden / white = good, legal, authorized. You can probably see where I'm going.

Sure, blacklist / whitelist has nothing to do with race to start with, but I find the parallel with Apartheid sufficiently obvious to make it embarrassing, certainly because I'm not a native English speaker and I don't have enough background on what has racial overtones and what doesn't.

I mean, I had been living in the US for several months whet someone had to tell me the difference between "to screw" and "to screw up". (I'm grateful.) Do you really expect a guy like me to know that "blackface" has racial overtones but "blacklist" doesn't, and thus interpret the words correctly?

Besides, the connection didn't exist in the first place, but when people start making it, can we still pretend it doesn't exist? If I wanted to troll a linguist, I'd say it's akin to pretending that words people actually use don't exist until they're written in a dictionary ;-)

Lastly, another argument for the statu quo is that humans are good at interpreting words based on context, so "black" in "blacklist" isn't a problem. However, I counter that humans are even better at making connections and detecting patterns, even subconsciously and sometimes even when the pattern doesn't actually exist. That's quite likely to happen here.

I agree that this isn't as clear cut as master / slave. That must be why it took us six years to go from the master / slave discussion to the blacklist / whitelist discussion.

No one's gonna get confused on the meaning regardless of whether we make the change or not. This is "just" a political marker. It doesn't have one correct answer. It has several answers whose correctness vary over time.

I think we'll make the change at some point. Some progressives will hate us for taking so much time. Some conservatives will hate us for being snowflakes. Since we already started spending time on this discussion, we might just as well do the change while we're there, take some flak for a couple days, and move on.

Best regards,

-- 
Aymeric.

On 15 Jun 2020, at 21:56, Daniele Procida <[hidden email]> wrote:

Tom Carrick wrote:

I don't think there is an easy answer here, and I open this can of worms
somewhat reluctantly. I do think Luke is correct that we should be
concerned with our credibility if we wrongly change this, but I'm also
worried about our credibility if we don't.

There are plenty of black-something terms in English that are both negative and have nothing whatsoever to do with race. The black and the dark are those things that are hidden and sinister, as contrasted with those that are in the light and open to scrutiny (black magic, dark arts, black legs, blackguards, blackmail, etc).

I think it would look pretty silly to confuse meanings that refer to what's shadowy and obscure with things that have racial overtones, and I think we should steer well clear of that. It's not at all like metaphors such as master/slave.

If we made such a change and tried to justify it on the grounds of a connection between race and the word "black" in those terms, we'd be rightly laughed at.

1000 neckbeards would immediately come out of the woodwork having done some basic web searches going 'neeer neeer neeer, the Django Software Foundation overflowing with snowflakes who think that "blacklist" means [etc etc etc]', and who has the stomach for that?

Even choosing to do it on the basis of the potential for offence seems to be a fairly flimsy argument.

On the other hand, we can do whatever the hell we like.

We don't have to justify anything to anyone. If we want to change words in *our* framework, it's absolutely nobody's business but our own.

If black members of the DSF or the community are disheartened that the word "black" gets to refer to so many negative things and are bothered when they see them in Django, then that alone is sufficient justification.

If we want a reason for changing "blacklist" (or whatever), it's that people in our community said they would feel better about it and asked to have it changed.

Acknowledging how someone feels about something and acting because you care about their feelings seems to be a respectful thing to do.

"We did it because we felt like it" is an utterly unanswerable justification.

The DSF has credibility because the software is first rate, the foundation is well-governed and the community is an international example of decency and kindness. Things like this become credible because the DSF chooses to do them - it's not the other way round.

Daniele

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4FC8DDEB-2A3C-4B31-9265-D07F28D6CFCA%40polytechnique.org.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a78ec9c-4837-fb3b-6aa6-9497def4de65%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DFO56Vqy5TCqMw2DzC_0pV1LwfE%3D92umuGqnvks0wR90g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAM2o%3DwNre_3k6fsWMiF6xdq5%2Bo2Pky5-g5a31Ye%3DOqn8XoBRFw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-ykkGvysG_3X%2BBy11SSRQsN6fL28qv9sM2edZC1-uHLZEpQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

אורי
In reply to this post by Tom Carrick
I think master is the default branch name in any Git repository. It's not about Django and even not GitHub. Do you want to change the default branch name in Git?


On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick <[hidden email]> wrote:
This ticket was closed wontfix as requiring a discussion here.

David Smith mentioned this Tox issue stating it had been closed, but to me it seems like it hasn't been closed (maybe there's something I can't see) and apparently a PR would be accepted to add aliases at the least (this is more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading this ZDNet article - it seems like Google have already made moves in this direction and GitHub is also planning to. Usually Django is somewhere near the front for these types of changes.

I'm leaning towards renaming the master branch and wherever else we use that terminology, but I'm less sure about black/whitelist, though right now it seems more positive than negative. Most arguments against use some kind of etymological argument, but I don't think debates about historical terms are as interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms somewhat reluctantly. I do think Luke is correct that we should be concerned with our credibility if we wrongly change this, but I'm also worried about our credibility if we don't.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeH3ixuxTqBvB6FdLzimDbB4D5uGHKEawwjvqXVHU%3DcvKg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: The blacklist / master issue

Arvind Nedumaran
The "default" is name is just a convention. It can be other things and after a few days of "teething" issues, and everyone will be back to being as productive as they are right now.

Sent from Outlook Mobile


From: [hidden email] <[hidden email]> on behalf of אורי <[hidden email]>
Sent: Tuesday, June 16, 2020 7:05:19 PM
To: Django developers (Contributions to Django itself) <[hidden email]>
Subject: Re: The blacklist / master issue
 
I think master is the default branch name in any Git repository. It's not about Django and even not GitHub. Do you want to change the default branch name in Git?
אורי


On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick <[hidden email]> wrote:
This ticket was closed wontfix as requiring a discussion here.

David Smith mentioned this Tox issue stating it had been closed, but to me it seems like it hasn't been closed (maybe there's something I can't see) and apparently a PR would be accepted to add aliases at the least (this is more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading this ZDNet article - it seems like Google have already made moves in this direction and GitHub is also planning to. Usually Django is somewhere near the front for these types of changes.

I'm leaning towards renaming the master branch and wherever else we use that terminology, but I'm less sure about black/whitelist, though right now it seems more positive than negative. Most arguments against use some kind of etymological argument, but I don't think debates about historical terms are as interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms somewhat reluctantly. I do think Luke is correct that we should be concerned with our credibility if we wrongly change this, but I'm also worried about our credibility if we don't.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeH3ixuxTqBvB6FdLzimDbB4D5uGHKEawwjvqXVHU%3DcvKg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/BYAPR14MB2918D1D9008D787BC2AF1F95A39D0%40BYAPR14MB2918.namprd14.prod.outlook.com.
123