search

medic / cht-core

The CHT Core Framework makes it faster to build responsive, offline-first digital health apps that equip health workers to provide better care in their communities. It is a central resource of the Community Health Toolkit.
https://communityhealthtoolkit.org
GNU Affero General Public License v3.0
438 stars 209 forks source link

Remove use of "blacklist" and "master" #6574

Open mrjones-plip opened 4 years ago

mrjones-plip commented 4 years ago

What feature do you want to improve? The use of blacklist and master is offensive. With the larger Black Lives Matter movement going on now, extra attention is being paid to areas, like computer science, that were previously given a pass. We should remove use of this language in our docs and stop use of the term in code to ensure we're inclusive:

Such terminology not only reflects racist culture, but also serves to reinforce, legitimize, and perpetuate it. - academics in 2018

It's clear that there are people who are hurt by [these terms] and who are made to feel unwelcome by their use due not to technical reasons but to their historical and social context. That's simply enough reason to replace them. - Golang Pull Request

Describe the improvement you'd like We should analyze our use of these terms, along with their counterparts of whitelist and slave, and seek to either remove them or deprecate them. Initial proposal on replacement terms are:

Running a recursive grep call is an exceedingly blunt tool, but to get some quantification that lacks both subtly and insight into the time/effort of changing anything, here's some stats:

Term cht-core cht-docs
blacklist 94 6
whitelist 351 4
master 241 763
slave 0 0

Note that we build our project(s) with dependencies, so I'm explicitly excluding node_modules for this reason. Further, we'll of course have to use the master term to link to URLs of projects on github that have not adopted this change.

This change will very likely not be easy and may take a very long time (quarters not years). There is no reason to move quickly on this, short of quick wins (eg changing best practices in the docs site or blog posts announcing our intentions). Slow and steady wins the race. It may even pay to wait (see "Later in 2020" below).

Describe alternatives you've considered Early in 2020 OpenSSL elected to not make the change after a PR was opened. They cited, among many things:

is "master" actually offensive when using it in the context of "master, public, private"? By avoiding this particular rename we don't have to make any changes to public API symbols - which would be preferable.

In a ticket to update Ansible, a commenter felt the change was largely misdirected:

This whole exercise to change terms/words is absurd. It is only done so people can go back to having a good feeling about themselves. Changing the way you name resources doesn't help in fighting -in this case- racism (or intolerance in general). Instead of changing words/terms, why not pledge to have a 0 tolerance vs all forms of discrimination. That would actually mean something.

We could choose to do nothing as well as possibly add an explanation on why we're not doing anything about it.

Additional context Many big players are making or have already made the change:

Later in 2020 github is introducing some changes that may ease the changes in cht-core:

By the end of the year, we'll make it seamless for existing repositories to rename their default branch. When you rename the branch, we’ll retarget your open PRs and draft releases, move your branch protection policies, and more - all automatically. And, we’re also looking into redirecting users who git fetch or git clone the old branch name to the new branch name (with a warning and instructions to update their local clone), so it’s easy for your contributors to move. You’ll be able to do a rename from GitHub.com, GitHub Desktop, or the CLI.

Repositories List to be modified

MaxDiz commented 4 years ago

GH is planning to change "master" to "main" - https://github.com/github/roadmap/issues/63

mrjones-plip commented 2 years ago

"8 of 107 tasks" - go @jonathanvq, go! :rocket:

jonathanvq commented 2 years ago

@mrjones-plip I just added this PR https://github.com/medic/cht-docs/pull/616 for your review in the cht-docs repo. Thanks!

jonathanvq commented 2 years ago

@abbyad , @garethbowen, Is the medic-docs repo used at all? I see in the readme that it has been replaced by cht-docs, but do we need to maintain this still? I’m trying to figure out if I should do the master -> main changes here (including the doc changes, not just the branch name) or leave it as it.

garethbowen commented 2 years ago

It's been archived too, so you can definitely ignore it.

This repository has been archived by the owner. It is now read-only.

We could think about deleting it or making it private but let's not spend any time improving it.

garethbowen commented 1 year ago

I've patched the codebases to remove some sensitive words. Leaving this issue open to track the repo main branch change.

jonathanvq commented 5 months ago

@latin-panda , after reviewing this again per our recent conversation on Slack in which you asked "Can we change master branch to main in cht-core? I always feel weird saying master, IMO it doesn't go with our values", I still think changing cht-core's default branch should be the last step in this ticket as that's is the more frequently used repo in the organization.

However, we could give it a try soon and evaluate if something breaks and roll it back quickly to avoid further issues. One concern I have is that this should not only be about renaming the branch but actually updating the references. For instance, cht-docs have many references to cht-core 'master' branch, you can see a few in this file. If we rename the branch, people trying to access it will immediately get redirected to the new default branch ('main'), but in my opinion, the problem will still persist. The redirection is ok, but we will still have hundreds or maybe even thousands of references across all our repos to the old branch. They won't break, but the master branch name would still live in the code. From a purist point of view of what we are trying to do here, I think we should get rid of that as well, and not just focus on the branch name.

I can go ahead and rename the branch but the real goal will be far from done. What do you think?

latin-panda commented 5 months ago

should be the last step in this ticket as that's is the more frequently used repo in the organization.

@jonathanvq I read this ticket through, but I'm unclear what the "steps" and the "last step" are. There are many repositories mentioned here that haven't been maintained in several years, and the level of relevance is minor in comparison to the most used repositories (cht core, cht docs, cht conf, cht android).

CHT Core is our more important repository internally and externally, the one we often reference in public communication, it's one of the "faces" of Medic. Because of the level of relevance in public communications, we can set cht core as the primary target, and manage it as a mini project.

We should split this task and involve different teammates (Infa FG, QA team, community team, Care Teams FG, Allies FG, Ecosystem FG, App services). My recommendation is: