Modernize terminology #3

New Issue

DarkFeather · 2020-08-17T03:22:00-05:00

DarkFeather commented

2020-08-17 03:22:00 -05:00

We should modernize our terminology to follow the times.

Use blocklist/allowlist instead of blacklist/whitelist, following a Linux mailing list
Use main instead of master for the central branch, following GitLab/GitHub
- We expect this one to cause some breakage with Maat Builder -- manual intervention is likely to be required, but can be as simple as removing all source directories.
- We can effect this with git branch -m master main && git push -u origin main.
- Gitea will need some cleanup afterwards by going to /settings/branches and setting the default branch to main before git push --delete origin master.

This issue will be updated if any other terms are found/proposed. Close criteria are completed remediation of complaints and no new complaints for 90 days.

We should modernize our terminology to follow the times. * Use blocklist/allowlist instead of blacklist/whitelist, following a [Linux mailing list](http://lkml.iu.edu/hypermail/linux/kernel/2006.1/03879.html) * Use main instead of master for the central branch, following [GitLab/GitHub](https://gitlab.com/gitlab-org/gitlab/-/issues/221164) * * We expect this one to cause some breakage with [Maat Builder](https://maat.aninix.net) -- manual intervention is likely to be required, but can be as simple as removing all source directories. * * We can effect this with `git branch -m master main && git push -u origin main`. * * Gitea will need some cleanup afterwards by going to /settings/branches and setting the default branch to main before `git push --delete origin master`. This issue will be updated if any other terms are found/proposed. Close criteria are completed remediation of complaints and no new complaints for 90 days.

DarkFeather self-assigned this 2020-08-17 03:22:01 -05:00

DarkFeather added the due date 2020-11-17

2020-08-17 03:22:28 -05:00

DarkFeather added the

In-progress

label 2020-08-17 03:22:40 -05:00

DarkFeather changed title from ~~Modernize terminology.~~ to Modernize terminology

2020-08-17 03:31:20 -05:00

DarkFeather commented

2020-08-17 03:51:41 -05:00

We should watch for Gitea to implement some feature to set the default branch name like GitLab.

We should watch for Gitea to implement [some feature to set the default branch name like GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/221013).

DarkFeather commented

2020-08-17 05:15:02 -05:00

master->main conversions completed, for the most part.

DarkFeather commented

2020-08-22 10:21:56 -05:00

Update: confirmed that Gitea allows setting the default branch name now.

DarkFeather commented

2023-06-08 15:36:29 -05:00

Updated blog post from GitLab: https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/

jml commented

2024-05-26 22:35:11 -05:00

There is an RFC that's been in the works since 2019 related to this called Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs They (IETF) have a Github Action based Bot that can automatically flag this stuff in repos. And NIST, maintains a guide to inclusive language recommendations that I also think is an important reference here.

The IETF's Github-only automation tool for this sort of thing has made me start thinking this sort of thing should be as-automated by CI tools as possible. Ideally there's some dictionary that we can point at, and when the CI system is going over repositories, especially if there is any PR Automation/CI it should fail and notify why.

There is an RFC that's been in the works since 2019 related to this called [Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs](https://datatracker.ietf.org/doc/html/draft-knodel-terminology-14) They (IETF) have a [Github Action based Bot](https://github.com/ietf/terminology/blob/main/.github/in-solidarity.yml) that can automatically flag this stuff in repos. And NIST, maintains a [guide to inclusive language recommendations](https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#inclusive) that I also think is an important reference here. The IETF's Github-only automation tool for this sort of thing has made me start thinking this sort of thing should be as-automated by CI tools as possible. Ideally there's some dictionary that we can point at, and when the CI system is going over repositories, especially if there is any PR Automation/CI it should fail and notify why.

DarkFeather commented

2024-06-27 12:13:30 -05:00

Presently, we use pre-commit hooks via uniglot-clone in AniNIX/Uniglot to do this. You can see some of our hooks here: https://aninix.net/AniNIX/Uniglot/src/branch/main/Hooks/scripts.d

It seems achievable to write a Python wrapper to action on that solidarity list and examine all Markdown files at the very least. I'm not sure we can enforce it on all files yet, as some libraries & configurations still reference old terms, especially in security tools for the lists.

Presently, we use pre-commit hooks via `uniglot-clone` in [AniNIX/Uniglot](/AniNIX/Uniglot) to do this. You can see some of our hooks here: https://aninix.net/AniNIX/Uniglot/src/branch/main/Hooks/scripts.d It seems achievable to write a Python wrapper to action on that solidarity list and examine all Markdown files at the very least. I'm not sure we can enforce it on all files yet, as some libraries & configurations still reference old terms, especially in security tools for the lists.

Sign in to join this conversation.