[umvi]

> I don't think people who are outside of these underrepresented groups understand just how many small reminders a day we get that the "default" is for us not to be welcome.

IMHO (and I didn't downvote you, btw), I believe you (and other minorities) are choosing to interpret things like complaining about political changes to code and projects as persecution. That is a choice you are making. You could also choose to see it for what it really is - people disagreeing about politics. Interpreting a political stance as a personal insult or persecution is not the right way to go, IMO. Assume good faith; give the benefit of the doubt.

If a project maintainer pushes back and complains when internet mobs try to force him to remove the word "red" from his codebase because it triggers soviet refugees... that doesn't mean the project maintainer is persecuting soviet refugees or that soviet refugees are "unwelcome" to contribute. Soviet refugees may choose to interpret the project maintainer's actions as such, but that doesn't make it so. In reality the project maintainer disagrees with the politics on the issue of removing the word "red" from his code and is pushing back.

The beauty of GitHub, HackerNews, and internet fora in general is that nobody really knows your race or gender or really anything about you (unless you make it known). From my experience, people on the internet are just usernames with personality, judged on the merits of their insights and contributions. I've worked with some great people online in the past on different projects, and to this day I have no idea if they were male or female or non-binary or black or white or asian or blind or deaf.

[tw4l]

I appreciate you taking the time to share your perspective. I think where we disagree is in characterizing making inclusive language changes as "political" and keeping the status quo as "non-political", when the status quo is demonstrably not working for a lot of people. Changing "master" to "main" is admittedly likely near the end of the list of what the tech industry needs to do to in that regard, but if we can't even get low-effort token gestures like that to happen without a lot of outcry I'm not optimistic about any kind of substantive change.

The idea of places like HN being meritocratic tech utopias where race and gender are irrelevant and everyone's just a username with some neat ideas is really compelling. I can only offer that in my experience it's common knowledge among woman developers that if you want to have a good day, it's best not to read the comments here. It seems I've forgotten that myself!

[umvi]

> I think where we disagree is in characterizing making inclusive language changes as "political" and keeping the status quo as "non-political", when the status quo is demonstrably not working for a lot of people

Sure, your perspective is valid too, I just tend to lean the other way. I tend to believe that it is impossible to please everyone and that we should not strive to unless it has clear, demonstrable value.

> we can't even get low-effort token gestures like that to happen without a lot of outcry I'm not optimistic about any kind of substantive change.

Well, I think part of the reason for outcry in this particular case is that it is (again, IMHO) not a "low-effort token gesture". I mean, if you look at the patch being submitted in the email linked at the top of the thread to make main the new default:

> 351 files changed, 3903 insertions(+), 3890 deletions(-)

and for me personally it means that all my future git repos are going to have a different default branch than my past repos which breaks some of my utility scripts. And if I configure the default branch of my future repos to remain "master" to avoid this then some people might take offense and see it as a dogwhistle.

So to me this whole thing seems like a big charade, but maybe the silver lining is that Git really should have been designed from the start to easily take arbitrary default branch names, and this patch will enable that.

[zeroimpl]

Is there any evidence that the submitter of the code did not want to make the change? It seems quite possible that the contributor wanted to make this change and volunteered their time. If that’s the case, the complexity of the change should not be relevant. The only complexity to consider is the downstream complexity. And besides, the change seems to be a one-liner plus find-and-replace in thousands of unit tests. Could probably have been done in a matter of minutes.

I am just speculating of course and maybe they were very unhappy to have to do this.