Amidst all the protests around the globe, the tech community is also engaging in some ways. GitHub has announced that they'll replace racially-loaded terms.
This includes dropping terms like "master" and "slave" for alternatives like "main/default/primary" and "secondary;" but also terms like "blacklist" and "whitelist" for "allow list" and "deny/exclude list."
What do you think about this? What other terms do you think should also be changed?
Latest comments (56)
I can see how master/slave could be problematic, but the "master" branch doesn't imply that there are slave branches, and certainly isn't racially loaded, just like a master bedroom doesn't imply there are slave bedrooms.
Either way, it doesn't really make any difference, and seems like a hollow gesture to me, but if it means that diversity increases on GitHub, then I'm all for it.
Is this a joke? I'm not trying to be provocative here but surely this is just insane?
blacklist/whitelist isn't racially loaded at all. There's basically no way to make that argument.
Master/slave. Ok sure, MAYBE you could make that argument. but that implies that no other race has ever been enslaved?
This whole thing sort of seems like a massive virtue signal, to show "wow look how progressive we are" Without actually doing much of anything.
Changing some technical terms isn't going to end racism. It's just going to inconvinence some people. Might not even do that.
I think renaming the "master" branch is,
I wrote more about these in another post.
Good for them. However, there are things that help the victims, and there are things that don't. This one doesn't, and it's probably done for their own image of themselves, to seem like they're doing something. This response is meek, at best, and egoistic, at worst. That's my opinion.
If they truly wanted to help, they would advocate and lobby for abolishment of private prisons and war on drugs, as well as demilitarization of police.
Exactly. GitHub could spend therr time and PR resources to stop their contract with the ICE, and rethink banning based on ethnicity.
Considering that tech has moved towards
workerfor a while, I'm not surprised by the change. Like, boss-worker nodes vs. master-slave nodes. Or even child processes. Things that are under or spawned off of a controlling element have been moving away from historically charged phrasing.I'm glad to see them making progress towards a better way of phrasing, but it makes me think less of them that they're doing it now... There's no way they actually care and aren't just doing it for the pat on the back for being progressive during #blacklivesmatter.
Wait until someone thinks "child process" is offensive because of "child labor".
Exactly. GitHub has far worse social problems to fix than the name of a branch (see point 6 in my post).
Thanks for gathering all of point 4 in one spot! I remember each of those individually, but seeing them all in one place is particularly damning.
I don't know about the point here, though (and similarly point 3 at your write-up). Since language and meaning evolve over time, I don't see an issue with renaming child processes if a lot of people associate it with child labor instead. In that case, it doesn't affect me at all if it stays or if it changes, but it could help people if it changes, so net win. This is also why I see Github's timing as the suspicious part -- they're getting positive feedback and recognition for something that they weren't affected by and a lot of people in what they see as affected populations don't see issue with.
They aren't doing it out of empathy when there's rarely a person affected. They're doing it to look good.
When white people start to care about something, things change REALLY quickly. All we have to do is care about the things that will have a real huge impact on the lives of underrepresented people.
It only took world wide protests to change one word. I don't know what we'll need to do real change... Is there even hope?
No reason to stop trying💪
I'd be interested to know whether this idea came forward from a POC. I don't think this would've been the first thing that came to mind for me if asked what Github could do in response to the #Blacklivesmatter movement. I personally don't feel this will accomplish much for POC but I guess changing it won't harm anything.
Probably not. See point 4 in my post.
These terms have existed for decades and now suddenly we feel they're racially loaded? I think this is a knee jerk reaction to a problem that doesn't exist.
Very well put! I've linked to your quote in my post.
The whole debate wouldn't be as problematic, if it didn't go the way every outrage debate goes.
"We say it is bad, prove us wrong", and suddenly there is a whole bandwagon without any proof or argument to be made.
This is not how a discussion should work, and most of the time the path of least resistance is just to give in to the demands, to save your face publicly.
I'm not against the change, if it makes people happy, go for it. I'm just against how the discussion and stigmatisation in this whole process works, every damn time.
This is the easiest way to do nothing and still pat yourself in the back, if Github is serious about their social responsibilities they should cut their contracts with ICE, cheap stunts like this are a shameless PR move.
I was going to say exactly the same thing
I just renamed mine in GitHub. Given I have Azure Pipelines linked to my repos for CI and CD, I also had to make a few changes there:
"Road to hell is paved with good intentions" is what I think.
What will this change for people of color? Everybody will have to use new term they are not used to. This only creates more unnecessary work for creators.
The fact that it is causing a lot of people a small frustration may also get them to think. I've seen a lot of discussions happening on why these terms are bad. Even if people were to completely leave their branches alone, they may have learned something.
The master branch in Git was just a placeholder name anyway. With repos forking there is no real concept of master. Or, as the Pro Git book often calls it the 'blessed master', which, in hindsight, sounds even worse.
Renaming "master" will be no small frustration.
I'm guessing it won't be as horrible as painted. Plus, you don't have to change. It's entirely optional. It's not that there will be a blocklist of bad branch names built into every git command line...
And there are safer ways to do this than just renaming everything. Adding a little automation to make main mirror master, update the builds over time, add hooks to warn users etc.
It will be far less painful as we adopt ways to more easily resolve these problems.
The small frustrations I was alluding to were the small open source projects and personal Repos that can change easily. I was done in less than 2 hours. But maybe some of my forks may need to spend some time too. And maybe some links from blogs and stackoverflow will break. For me, that's ok.
I am just thinking how many pipelines this will break. Am I the only one?
BTW would it mean the next step is that we cannot use these words in our repositories?
Wait until they see how my RaceConditionExceptions class is named.
Yeah, those pipelines were a bit more work. With config as code it's mostly a simple search and replace. And some folks inside GitHub already seem to be looking into a more platform supported option to reduce the fallout.
A note, if I may. Not every pipeline is a DevOps pipeline that can even be defined in code. There are process pipelines and tools that do not allow this.
Let's say you are a corporation with GithubEnterprise and you depend on another 3-rd party git tool. GitHub changes master to main but your 3-rd party provider did not yet update. What now?
As a QA (mainly) I shiver whenever people say "simple" and even more with "search and replace".
It was in my case, but then again, I own almost every step in my process. And I use different branch names in some other cases already.
In complex environments I'd take a more cautious approach, maybe start using automation, like GitHub actions to sync master to main. Roll out hooks to detect dependencies on master etc. That way you can take the slow and cautious approach.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.