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). On Mon, 15 Jun 2020 at 17:27, Tom Carrick <t...@carrick.eu> wrote: > This ticket was closed wontfix > <https://code.djangoproject.com/ticket/31670#ticket> as requiring a > discussion here. > > David Smith mentioned this Tox issue > <https://github.com/tox-dev/tox/issues/1491> 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 > <https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/> > - 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-developers+unsubscr...@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 > <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1F3dRC9xaWWr47zbCfwDLEmspaTK3u%2Bf0%3DmcoRQ5%2B%3Dvw%40mail.gmail.com.
