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.

[Adam Johnson]

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

• Apache Web server (2018): https://twitter.com/rbowen/status/1269346035652005890
• IETF draft RFC (2018): https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.2 (Thi
  
• Google Developer Style guide: https://developers.google.com/style/word-list#blacklist (and by extension, Go Lang in https://go-review.googlesource.com/c/go/+/236857/ and Chromium in https://www.theregister.com/2019/09/03/chromium_microsoft_offensive/ )
• Ruby on Rails (2018): https://github.com/rails/rails/issues/33677
• UK National Cyber Security Centre (2020): https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white

(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).

--
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 django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.com.

--

Adam

[Carlton Gibson]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1F3dRC9xaWWr47zbCfwDLEmspaTK3u%2Bf0%3DmcoRQ5%2B%3Dvw%40mail.gmail.com.

[René Fleschenberg]

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

[Kenneth Love]

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.

[Daniele Procida]

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

[Markus Holtermann]

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

> --
> 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 django-develop...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.
>

[Aymeric Augustin]

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.

[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)

[Curtis Maloney]

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

[Jeff Triplett]

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.

https://github.com/rails/rails/issues/33677#issuecomment-414873738

[Ngazetungue Muheue]

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.

[Jure Erznožnik]

+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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4FC8DDEB-2A3C-4B31-9265-D07F28D6CFCA%40polytechnique.org.

[Claude Paroz]

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

[Sanskar Jaiswal]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a78ec9c-4837-fb3b-6aa6-9497def4de65%40gmail.com.

[Fran Hrženjak]

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

https://dictionary.cambridge.org/dictionary/english/master

https://www.merriam-webster.com/dictionary/master

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACzaa%3DFO56Vqy5TCqMw2DzC_0pV1LwfE%3D92umuGqnvks0wR90g%40mail.gmail.com.

[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

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.

[Jorge Gimeno]

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:

[אורי‎]

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?

אורי

u...@speedy.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 django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.com.

[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: django-d...@googlegroups.com <django-d...@googlegroups.com> on behalf of אורי <u...@speedy.net>
Sent: Tuesday, June 16, 2020 7:05:19 PM
To: Django developers (Contributions to Django itself) <django-d...@googlegroups.com>
Subject: Re: The blacklist / master issue

 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeH3ixuxTqBvB6FdLzimDbB4D5uGHKEawwjvqXVHU%3DcvKg%40mail.gmail.com.

[Roger Gammans]

Funny you should say that but the git developers mailing list in is awash with patches and shouting about just this at the moment.

It looks likely the patches will go in too - so that's not much of an arguement against.

[Tom Carrick]

On moving away from the master branch, it would be a lot of effort (not just in the repo, but docs, Trac, etc.), but I think it's worth doing regardless. I think there is often some reluctance to do something time-consuming because it takes someone's time away from technical issues. I don't think this is necessarily true. Although we could always use more contributors, this is something that's fairly easy for a newcomer (talking specifically about the changes to docs). There's no requirement to know about ORM internals, async implementation, or anything else. Just some time and thoroughness. I'd be happy to put the time in, and I'm sure there are many other (potential) contributors willing to do so, and It doesn't stop the more technical people working on the issues they want to. I think all that is really required - if/when a decision is made, would be to review the PR, change the branch in Github, migrate Trac. Of course I don't know what else is affected, so maybe I'm being optimistic here.

This does have some precedent also, there was a move from trunk to master when moving from SVN to git. That was part of a bigger change to a new VCS system, admittedly, but I think this is also important. With that said, I do think we should wait and see what naming convention git / GitHub / GitLab etc. decide on. It seems like "main" has the most traction, which seems fine to me, and, as has been mentioned, is less of a misnomer anyway.

One argument I've seen against both of these that I don't think has been addressed in this thread is that this will set off a trend of renaming more things, mastery, masters degrees, and so on. In case it needs to be addressed, this strikes me as a slippery slope fallacy. Just because we do one thing, doesn't mean we must necessarily do another vaguely related thing. I don't see (or foresee) any interest in this, and I think as is always the case in these things, we go where the consensus is. For example, trolls aside, I don't see any criticism of e.g. Frontend Masters.

Just some further thoughts.

Tom

--

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 django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1b47e74f1811390add42c91dab4ccea104b89fcf.camel%40gammascience.co.uk.

[Adam Johnson]

On the branch rename, right now I'd rather wait to see what GitHub builds that could help with this. It might allow aliasing master->main so that existing PR's don't need targeting, local clones don't need updating, etc. It also seems Git will make a change and it might be worth waiting to see what that looks like.

On the blacklist/whitelist rename, I've reopened the ticket and Tim Graham already reopened the PR.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZ9P4ONPbGegRwTnuebyMT5PjbEjHN-38rG18K20u6gTQ%40mail.gmail.com.

--

Adam

[Andrew Godwin]

I've definitely in favour of fixing all of the problematic word usage - after all, we eliminated master/slave from the database documentation years ago, we've just been a bit negligent at fixing the others.

Agreed with Adam, though, about seeing what GitHub builds - they announced they're working on something, and if it allows seamless migration, that'd be great. That said, if they take more than a month or two, we should just change it and get it over with.

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3mu_bUh3%2Bc-uJv8Nq6vWLMPrk%2B9Yno8-%3Dq60-xQGrxow%40mail.gmail.com.

[Alexander Lyabah]

Django in international framework, not US-framework. You should not change variable names just because meaning of some words have been changed in US recently. Those words have been used in source-code for years, and nobody put racism in those word when this framework was founded and nobody puts any racism in when one is using for creation something big and meaningful.

What I'm encourage you to do, is to thing farther than what is going on right now.

If Django Foundation really want to help in this revolution - add a banner on that landing page. Feel free to choose

https://eji.org/

https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/

And this kind of contribution will work much better.

Thank you, for this opportunity to share my opinion.

[Tom Forbes]

As an international framework I think we should make our interface as language and culturally agnostic as possible. ‘Allow’ and ‘Deny’ are simply semantically clearer than ‘white’ and ‘black’. That alone is a convincing argument for me.

On 19 Jun 2020, at 13:55, Alexander Lyabah <a.ly...@checkio.org> wrote:



--

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 django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1c9178a3-cb80-428c-bacb-e8904695f6b6o%40googlegroups.com.

[Ahmad A. Hussein]

I'd argue that since Django is an international framework, we should strive to set an international standard. If a certain word is off-putting or problematic to individuals in our community, and if it does not convey an accurate and least astonishing meaning to a non-native English speaker, then we should definitely change it.

--

[Alexander Lyabah]

Ahmad,

> we should strive to set an international standard

No, we shouldn't we are here for creating framework, just treat your child well and it is enough to changing the world for the best.

> If a certain word is off-putting or problematic to individuals in our community

We can always find words that "off-putting or problematic to individuals in our community", the only difference between those words is that not all of them are on news-channel, but it should be a reason for changing anything.

> if it does not convey an accurate and least astonishing meaning to a non-native English speaker

Well, bases on this very week statement, we can change a lot of words in django source code. And it will not make Django community better, as well the world better.

On Friday, June 19, 2020 at 4:18:52 PM UTC+3, Ahmad A. Hussein wrote:

I'd argue that since Django is an international framework, we should strive to set an international standard. If a certain word is off-putting or problematic to individuals in our community, and if it does not convey an accurate and least astonishing meaning to a non-native English speaker, then we should definitely change it.

On Fri, Jun 19, 2020 at 2:54 PM Alexander Lyabah <a.l...@checkio.org> wrote:

Django in international framework, not US-framework. You should not change variable names just because meaning of some words have been changed in US recently. Those words have been used in source-code for years, and nobody put racism in those word when this framework was founded and nobody puts any racism in when one is using for creation something big and meaningful.

What I'm encourage you to do, is to thing farther than what is going on right now.

If Django Foundation really want to help in this revolution - add a banner on that landing page. Feel free to choose

https://eji.org/

https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/

And this kind of contribution will work much better.

Thank you, for this opportunity to share my opinion.

On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick 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 django-d...@googlegroups.com.

[Alexander Lyabah]

let's not change the subject

we are not talking about black and white, we are talking about whitelist / blacklist and master / slave. Those statements have a big history in programming, which has nothing to do with slavery at all.

Don't mix words with meaning and senses.

... It is important to understand when you make changes like this. ... words and meaning

I've never seen anyone who is by doing 'git checkout master', think about white race superior. - It is because master has a different meaning, different sense, which is nothing to do with slavery, and fight for freedom.

I've never seen anyone who is by playing white in Go-game, think about white race superior. (Even though by Go-rules white gets +7.5 points against Black at the beginning of the game) - it is because white has different meaning and different sense, and it is nothing to do with slavery, and fight for freedom (it is because blacks move first).

You have power here to do what ever you want to do in this framework. I what you to use common sense and don't follow the rules dictated by news-channels and big corporations. I want rules, you follow, being strong and independent from what is going on around. In that case you don't need to split community after next big news.

Thank you, with all respect.

On Friday, June 19, 2020 at 4:18:04 PM UTC+3, Tom Forbes wrote:

As an international framework I think we should make our interface as language and culturally agnostic as possible. ‘Allow’ and ‘Deny’ are simply semantically clearer than ‘white’ and ‘black’. That alone is a convincing argument for me.

On 19 Jun 2020, at 13:55, Alexander Lyabah <a.l...@checkio.org> wrote:



Django in international framework, not US-framework. You should not change variable names just because meaning of some words have been changed in US recently. Those words have been used in source-code for years, and nobody put racism in those word when this framework was founded and nobody puts any racism in when one is using for creation something big and meaningful.

What I'm encourage you to do, is to thing farther than what is going on right now.

If Django Foundation really want to help in this revolution - add a banner on that landing page. Feel free to choose

https://eji.org/

https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/

And this kind of contribution will work much better.

Thank you, for this opportunity to share my opinion.

On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick 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 django-d...@googlegroups.com.

[Adam Johnson]

Alexander, it's not really up for debate any more. We've already merged the PR's to Django.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/19a78e27-7d1d-4f0b-a2af-8a9594aa620fo%40googlegroups.com.

--

Adam

[Alexander Lyabah]

I'm not debating, since nobody has something to say. I'm explaining, why things that you are doing are embarrassing.

I hoping that wikipedia will be not that populistic https://en.wikipedia.org/wiki/Whitelisting

On Saturday, June 20, 2020 at 5:32:58 PM UTC+3, Adam Johnson wrote:

Alexander, it's not really up for debate any more. We've already merged the PR's to Django.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/19a78e27-7d1d-4f0b-a2af-8a9594aa620fo%40googlegroups.com.

--

Adam

[Alexander Lyabah]

Btw, PR-author has now a privilege to create an article https://en.wikipedia.org/wiki/Allowlistening

[Alexandr Tatarinov]

I would like to share this article which has pretty compelling arguments, especially regarding the feelings (point 4).

[Robert Roskam]

Hey All,

I see this opportunity to rename these things to be what they in plain, descriptive language. Since we will rarely have as many people together considering this change, I find it useful to think what we would have named these things from the beginning and then consider if our naming could be more clear.

I also found the term master odd when I first started using git. It didn't map to anything or have an analogy that I found useful. If we switched to main/trunk or whatever Github decides on, I don't much care what the new name scheme is. 

Further, I find the allow/deny, accept/block for lists of things as far more descriptive.

Some elaboration: when I first came into professional technical circles, I found the tendency to use color as a short-cut for culturally accepted meaning to be potentially confusing to those from other cultures.  White/black, red/green/yellow may have received _technical_ meanings from the last 50-60 years or so from the American-centric culture, and I speak ignorantly, since I'm an American, but I don't know if I can assume that other cultures do the same.

Robert Roskam

[Hooshyar Naraghi]

Hello,

I totally agree with Alexader's position, and I re-iterate his sentiment: This is embarrassing.

If I shared this discourse about whitelisting/blacklisting in the software field with founders of Back Lives Matter, I would suspect that they would look at me in a strange way.

Don't do something, because it is trending, or, in this case, because some guy at Google (or at any company) did it. That's called herd mentality. If any computer professional cares enough about racial discrimination in the U.S. (and in the rest of the world, for that matter), they ought to get involved in racial justice movements/projects. There are plenty of them around.

Would we, please, stay out of messing around with computer/software terms? Unless one has undisputed evidence that those computer folks who first came up with terms like whitelisting and blacklisting were racist or at the minimum they were influenced by a racist history, which I believe they were not. I would further propose unless one can prove that every time in our profession we use computer terms like whitelisting and blacklisting, the thing that triggers our conscious mind is the idea of the white race as good and the black race as bad, which I believe it does not.

BTW, bringing down statues of Confederate generals/leaders is a different discourse. They were racist and to this day their existence exemplifies the institution of racism and discrimination.

Regards,

Hooshyar Naraghi

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d5c3a001-b7f0-4dd6-b43a-1439df36c71co%40googlegroups.com.

[Alexander Lyabah]

Robert, thank you for your response.

For me, as an experience developer, blacklist is more descriptive, since I saw this word in so many other places, languages, frameworks. But it is just me, I'm here not to say that my opinion is more important than anyone else's.

What is more important here, Django doesn't have a strong rules for making decision about how framework is building and changing. Next week US-news will have a new subject for discussion, new words will be claimed to be abusive, new django community member will find an abusive word in source code (or sounds like it or very close to it), and community will be happy to claim this word to be not that descriptive, and find a better, more description replacement for it.

with big respect

[Daryl]

Alexander, 

"""What is more important here, Django doesn't have a strong rules for making decision about how framework is building and changing"""

You couldn't be more wrong with this statement.

One of Django's strengths is that decision making is *not* polluted by one strong opinion, a whim by a marketing department, or trend-following. 

You should read this

https://docs.djangoproject.com/en/3.0/misc/design-philosophies/

and this

https://docs.djangoproject.com/en/dev/internals/organization/

to educate yourself about how a strong organisation ensures that decision making is high quality, transparent and meritocratic.

D.

On Mon, 22 Jun 2020 at 07:11, Alexander Lyabah <a.ly...@checkio.org> wrote:

Robert, thank you for your response.

For me, as an experience developer, blacklist is more descriptive, since I saw this word in so many other places, languages, frameworks. But it is just me, I'm here not to say that my opinion is more important than anyone else's.

. Next week US-news will have a new subject for discussion, new words will be claimed to be abusive, new django community member will find an abusive word in source code (or sounds like it or very close to it), and community will be happy to claim this word to be not that descriptive, and find a better, more description replacement for it.

with big respect

On Sunday, June 21, 2020 at 6:54:57 PM UTC+3, Robert Roskam wrote:

Hey All,

I see this opportunity to rename these things to be what they in plain, descriptive language. Since we will rarely have as many people together considering this change, I find it useful to think what we would have named these things from the beginning and then consider if our naming could be more clear.

I also found the term master odd when I first started using git. It didn't map to anything or have an analogy that I found useful. If we switched to main/trunk or whatever Github decides on, I don't much care what the new name scheme is. 

Further, I find the allow/deny, accept/block for lists of things as far more descriptive.

Some elaboration: when I first came into professional technical circles, I found the tendency to use color as a short-cut for culturally accepted meaning to be potentially confusing to those from other cultures.  White/black, red/green/yellow may have received _technical_ meanings from the last 50-60 years or so from the American-centric culture, and I speak ignorantly, since I'm an American, but I don't know if I can assume that other cultures do the same.

Robert Roskam



On Monday, June 15, 2020 at 12:28:23 PM UTC-4, Tom Carrick 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 django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e6311154-ecfc-4117-a1c4-da669dfa6523o%40googlegroups.com.

--

-- 
======================
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell       021 521 353
da...@kawhai.net
======================

[Alexander Lyabah]

 Daryl, that is very strange, that you bring it here now.

> One of Django's strengths is that decision making is *not* polluted by one strong opinion, a whim by a marketing department, or trend-following.

renaming whitelist and blacklist is exactly what is in trend right now. I understand that not everybody are following US-news, but if you google "blacklist blm" you will find, how big the trend is, actually.

Also, thank you sharing those link, but can you plz elaborate more, why do you bring those and what do you what to proof by sharing those links, so when I read those links again, I know on what point I should focus more.

Thank you for being involved in this conversation.

[Markus Holtermann]

First things first:

I'm glad, Django changed master/slave and blacklist/whitelist to more appropriate and adequate terms. Naming things is hard. And just because somebody came up with a name decades ago doesn't mean it can't — or even shouldn't — be changed. Especially when there are more descriptive alternatives.

I'm glad, Django is in the position to take a stance for a more inclusive language in technology and against decades old, racist, terminology.

I'm glad, Django, as several other software projects out there, picked up on the Black Lives Matter protests happening in the US and around the globe.

I'm glad, Django has a Code of Conduct
(https://www.djangoproject.com/conduct/) and a community where racist behavior is not tolerated.

---

Alexander, since you brought up the news, I'm sure you're aware that the BlackLivesMatter protests are happening around the globe and are not only in the US. Racist behavior exists pretty much everywhere, certainly in the US and Germany.

I'm a young, white man, from Germany. I have never experienced any racist behavior towards me. But I'm fairly certain that there are plenty of people on this list who have.

We're still living in a society where white men are privileged in many ways. If I can stand in solidarity and support of black colleagues, friends, and members of the Django community, by reexamining and addressing language choices that have ugly backgrounds to their history, I'm glad!

Markus

> --
> 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 django-develop...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/267f6649-a434-47fb-93c9-880b594d213ao%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/267f6649-a434-47fb-93c9-880b594d213ao%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Daryl]

The focus while reading the Django pages should be on the differences between Django's governance approach (long term goal settings, a board of technical experts, meritocratic decision making) vs the many frameworks and projects that have flashed in the pan (please excuse me for using a phrase that some languages might not understand). 

Typically flash-in-the-pan projects have fewer experts, and control and decision making is *usually* meritocratic but sometimes egocentric. Eventually, no matter how bright the initial flash is, decisions by the self-chosen few are made that result in the failure of the project.

This isn't to say that a failed project is not of value - many of the learnings from failed projects are rolled into even better projects, but this is not what Django is about. The developers quickly realised (way back in the days when the initial developer's own newspaper project was the largest Django installation around) that a strong governance structure would be required.

With regard to the current "hot" topics (master/slave and blacklist / deny), these may be viewed as trend-following, but a deeper study of both nomenclature will inform you that current technology in databases no longer follows the original meaning of master / slave, so a new or different name is required. This might not suit people of my age who grew up with master/slave databases and understand the non-racist use of the words, but why should the current nomenclature suit just me?

Master / slave patterns still exist in some databases, but generally the idea of one node being a master is getting rare. This is somewhat poetic, as it mirrors the real world where in most countries, where the trend is (hopefully) away from master / slave relationships.

My personal opinion for the 2nd topic (blacklist / whitelist / allow / deny) is that this is a good time to pick a more descriptive name, and allow/deny would mirror the linux hosts.allow and hosts.deny logic that has been perfectly apt for 4 decades or more, and AFAIK is a better description in most spoken languages in use today. You (Alexander) may prefer "blacklist", and some of the technical board may also prefer "blacklist" (i don't know) but you can rest assured that the decision would have been made without significant weight being applied to the technical board member's *personal* experiences, but the experiences of every *future* user of the framework.

Finally,  in order to argue against changing these names (which has been pointed out has already been merged) you would have to come up with an argument to show reputational or technical harm would be done by changing. Of all the users who have posted on the list who *disagree* with the changes, none have written an argument with substantial merit in my opinion.

Remember, it's all about the future users of Django, not just the current users.

D

--

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 django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/267f6649-a434-47fb-93c9-880b594d213ao%40googlegroups.com.

[Alexander Lyabah]

Daryl,

I've never called anyone egocentric here, maybe thinking in a very short-term - yes (like a person, who is making decision just by current needs and not thinking about future at all)

> With regard to the current "hot" topics (master/slave and blacklist / deny), these may be viewed as trend-following, but a deeper study of both nomenclature will inform you that current technology in databases no longer follows the original meaning of master / slave, so a new or different name is required.

Well, this is exactly what trend-following means, I don't know how to argue here. Please feel free to explain what is trend following means in your opinion.

> Remember, it's all about the future users of Django, not just the current users.

Oh, I'm sure about it, but it doesn't mean those changes as smart, right?

Again, as I spend a lot of time explaining why renaming now is a bad thing, and I'm keep hearing again and again racism is bad and everybody are doing it, and for some reason renaming terms is a good thing again and again

As a final though here (and I promise I'm not going you tire you any longer) I want to tell you a story that happens in parallel universe.

Again, sorry for my English, I spend a lot of time explaining technical things in English, and study philosophy in Russian, but have being involved in English discussion like this before, which I'm obviously failed.

So, this universe looks exactly the same, fight for freedom, US-news, BLM, Django etc...

In this word developers said "We 100% support BLM, we against any racism. Some of community members have sent proposal for renaming blacklist, but we 100% sure, that this term has nothing to do with racism. Moreover, terms can't explain things 100% clear, we just use those terms to explain things faster. Because we are here is not for inventing and reinventing new terms, we are here for building new things. Let me explain in example. When one dev from US said to another dev from France - "don't forget to add blacklist functionality here", that explains a lot, because term blacklist is commonly known term. Someone, from community have an idea to rename all blacklist in source code to allowlist, and don't use term "blacklist" at all. Well in that case when dev from France will ask "allowlist is a list which is allowed to be expended? Or allowlist is a list that is allowed to be used by other lists?", the US-dev will answer "No, don't use read US-newspapers? allowlist is the same as blacklist but without racism", thats why we don't want to reinvent terms for what ever reason. Thank you for understanding"

But in the same world astrophysicists haven't been that wise, so they claimed: "We 100% support BLM, we against any racism. Thats why we decide not to use term "black hole" instead we will use term "heavy thing", we've asked a lot of other astrophysicists and they all agree that "heavy thing" explains thing better, of course, we are not following for renaming trend, we are here for science, it is just a good time to rename something that we have planed to rename long time ago. Remember, this all is for future generation of astrophysicists not for current generation, because we think, that the next generation will be much dumber and we should help them to understand new terms"

Thank you, and again, with all respect and with hope for the better future.

To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/267f6649-a434-47fb-93c9-880b594d213ao%40googlegroups.com.

[John Obelenus]

Alex I find the notion that you think changing terms that have bad racial connotations to be "embarrassing" to be entirely without merit. It is not embarrassing to consider the feelings of Black and other minority people when using language. Moreover, racism is not simply a US only phenomenon. It is a world wide phenomenon.

+1 to making these changes and removing racial undertones from this project. To stand against this change is to refuse to hear the opinions of those who are hurt. That is exclusionary and lacks empathy.

[Alexander Lyabah]

I'm sorry for my bad English

[Daryl]

In this word developers said "We 100% support BLM, we against any racism. Some of community members have sent proposal for renaming blacklist, but we 100% sure, that this term has nothing to do with racism. Moreover, terms can't explain things 100% clear, we just use those terms to explain things faster. Because we are here is not for inventing and reinventing new terms, we are here for building new things. Let me explain in example. When one dev from US said to another dev from France - "don't forget to add blacklist functionality here", that explains a lot, because term blacklist is commonly known term. Someone, from community have an idea to rename all blacklist in source code to allowlist, and don't use term "blacklist" at all. Well in that case when dev from France will ask "allowlist is a list which is allowed to be expended? Or allowlist is a list that is allowed to be used by other lists?", the US-dev will answer "No, don't use read US-newspapers? allowlist is the same as blacklist but without racism", thats why we don't want to reinvent terms for what ever reason. Thank you for understanding"

"blacklist" isn't as widely understood as you presume, and if you survey people (but I can't provide the source i have seen in the past) you will find that more people understand what it means to "deny" than to "blacklist". QED.

But in the same world astrophysicists haven't been that wise, so they claimed: "We 100% support BLM, we against any racism. Thats why we decide not to use term "black hole" instead we will use term "heavy thing", we've asked a lot of other astrophysicists and they all agree that "heavy thing" explains thing better, of course, we are not following for renaming trend, we are here for science, it is just a good time to rename something that we have planed to rename long time ago. Remember, this all is for future generation of astrophysicists not for current generation, because we think, that the next generation will be much dumber and we should help them to understand new terms"

That's a facetious argument - black holes are named for their color.

 

[Mark Bailey]

+1 on a good decision to make this change.

[Markus Holtermann]

Hi all,

Reviving an old topic. GitHub has by now tooling in place to rename branches and keep open PRs in sync. In fact, if I were to change the `master` branch to `main`, GitHub tells me this:

Renaming this branch:
* Will update 158 pull requests targeting this branch across 112 repositories.
* Will update 1 branch protection rule that explicitly targets master.
* Will not update your members' local environments.

I'd suggest to go through with this change and make the necessary changes to the CI / website.

Cheers,

Markus

On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
> +1 on a good decision to make this change.
>

> --
> 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 django-develop...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/1e3d742a-7f38-4258-a5a3-bfb01a333020o%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/1e3d742a-7f38-4258-a5a3-bfb01a333020o%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Kenneth]

I agree. We should go ahead and do the switch

You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/tctDuKUGosc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6fb9c6cc-39a6-4741-9d61-d03a44d9c477%40www.fastmail.com.

[Adam Johnson]

Yes, let's do it. I did it to my open source projects a couple weeks ago and everything has been smooth since. We'll need some find/replace for links in the main repo, on djangoproject.com, and I imagine some other places.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFHoQAD1i2X_HXjNPvHGHwYsaamxfMtjGDMT_F-6kg7FVHb5EA%40mail.gmail.com.

--

Adam

[Matthias Kestenholz]

Yes, please.

As a third party app developer I'll have to update a few GitHub
workflows and tox configurations (since I'm running testsuites against
the main branch too). It may be useful to announce this change on as
many channels as possible (mailing lists, the forum, as a news entry on
the Django website). Just an idea, this shouldn't be a blocker for
moving forward with this.

Thanks,
Matthias


On 24/02/2021 00:12, 'Adam Johnson' via Django developers (Contributions

to Django itself) wrote:
> Yes, let's do it. I did it to my open source projects a couple weeks ago
> and everything has been smooth since. We'll need some find/replace for

> links in the main repo, on djangoproject.com <http://djangoproject.com>,

[Markus Holtermann]

Thanks for the input, Matthias. That's useful to know. I'll make sure the change is announced.

Cheers,

Markus

> --
> 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 django-develop...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/81446dcd-e04c-3c28-91b5-a276a38baaf7%40feinheit.ch.
>

[Markus Holtermann]

Brief update on this.

The overall tracking pull request ist https://github.com/django/django/pull/14048/

* On 2021-03-03 at UTC morning, well migrate django/code.djangoproject.com and django/djangoproject.com

* Likely on 2021-03-09 we'll migrate django/django

Cheers,

Markus

> https://groups.google.com/d/msgid/django-developers/8caebe33-6b52-46f7-8f7b-b324474a546b%40www.fastmail.com.
>

[Markus Holtermann]

Hi all,

Mariusz renamed the branches this morning and merged the corresponding pull requests. Thank you!

Please let us know if you spot problems so they can be fixed.

Cheers,

Markus

> https://groups.google.com/d/msgid/django-developers/dd0f1e1a-3e6b-4202-8c55-f0741b35f88e%40www.fastmail.com.
>