Change non-inclusive naming

[martintoreilly]

I'd like to change some of the references we use to move away from using terms that have their origins in concepts of racial inequality.

Whitelist / blacklist

Decision is to change all references to whitelist to allowlist and all references to blacklist to denylist. If we make the PR to bandernatch then we get to make the terms match there as the maintainer is happy for terms to be picked by who does the work (see the PR I opened for this https://github.com/pypa/bandersnatch/issues/569)

Default branch name

Initial proposal was to change the default repository branch name from master to main, following the conversation at https://github.com/git-for-windows/git/issues/2674, which apparently has some traction in the wider community.

Looks like internal consensus in project team is for develop.

[martintoreilly]

@jemrobinson @JimMadge @thobson88 Thoughts on my proposed new naming conventions please. I'm open to suggestions for other alternative names. Also happy to plan timing of changes for after we merge outstanding large PRs like the Github ingress review one.

[JimMadge]

I'm happy with those names. In fact, they are more descriptive. I prefer main over default.

Thinking about descriptive names, master might actually be a poor choice. In the way we tend to use that branch, it doesn't control other branches, nor is it a 'master copy' because changes introduced on other branches will eventually be merged back.

[jemrobinson]

Is our master branch actually development?

[martintoreilly]

Is our master branch actually development?

Yes, I think it is.

[thobson88]

100% agree on the approved/forbidden change. I'll update the package policy docs.

I think develop is the git flow convention (as opposed to development). Perhaps that's all we need, but if we wanted another name for the master branch in that model I'd suggest stable (as more descriptive than main).

[martintoreilly]

So it sounds like we have consensus on changing from whitelist and blacklist to approved list and forbidden list.

I think the only place it's not entirely in our gift to make the change are the whitelist and blacklist plugin sections in the Bandersnatch configuration file we patch with our approved and forbidden lists. I've opened an issue on the Bandersnatch repo proposing a similar change - https://github.com/pypa/bandersnatch/issues/569.

[martintoreilly]

I'm happy with our main branch being development or develop. @jemrobinson I'll leave the final call on this to you.

[jemrobinson]

I'm happy with develop if that's an existing convention.

[martintoreilly]

Choices made by others

master alternatives

• Looks like GitHub are already working on making an alternative name default. This is in response to a suggestion to use main, but GitHub don't specify what their choice will be.
• The Linux kernel has gone with main.

whitelist / blacklist alternatives

allowlist / denylist

• GitLab
• Twitter
• Linux kernel
• NCSC
• These are also the standard terms for firewall rules

allowlist / blocklist

• Mozilla
• Chrome and Android, nodejs
• Go.
• This older draft RFC
• Curl

others

• PHPUnit went with ExcludeList
• .NET Rosyln went with a combination of safelist and ignorableX

[martintoreilly]

Looks like there's broad consensus on replacing whitelist with allowlist, but we seem to be the only ones thinking about using forbiddenlist to replace blacklist.

I think we should pick either denylist or blocklist as these seem to be the terms gaining traction in the wider community.

Preferences? @jemrobinson @thobson88 @JimMadge?

[jemrobinson]

allow / deny seems like a sensible pairing to me.

[martintoreilly]

Decision is allow / deny. If we make the PR to bandernatch then we get to make the terms match there as the maintainer is happy for terms to be picked by who does the work (see the PR I opened for this https://github.com/pypa/bandersnatch/issues/569)

[martintoreilly]

Git now supports configuring the default branch name

GitHub is changing the default branch name to main

[martintoreilly]

It's coming up to a year after we decided to move from whitelist and blacklist to allowlist and denylist but we've not yet made the changes to references in our code and documentation. Can we bump this up the priority list? Note there is now a parallel discussion on making a similar change for all Turing repos on the Hut23 repo