This is not a technically difficult task (https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx) but it might break some things. I definitely think we should try to change it.

Does this mean we would have to change the cluster API (which includes master in its vocabulary) as well in a semver-major?

@ronag i don't think that cluster was brought up in this thread, though it has been discussed on other occasions.

I'm -0 to the change itself. I don't think that changing it because it is "industry standard" is a valid argument, at least not yet. If we are changing it because we think it is a loaded/inappropriate word, then I think we should remove all occurrences to remain consistent with that decision.

I don't feel like this is something people have actually complained about. When we've made these changes in the past (for example in child_worker.suicide) it was guided by someone acting in good faith feeling strongly about the terminology.

If someone from the project's base does feel strongly about it - I suggest we rename it, though master is the default git branch name so I would caution we pick our battles.

I vote we:

• Don't change the name from master to something else currently.
• Change it when a contributor/collaborator feels strongly enough about this.

Of course, if you @trivikr personally feel strongly about this then I support you :]

Of course, if you @trivikr personally feel strongly about this then I support you :]

I don't feel strongly against using master branch name. I proposed it as I plan to follow it in my personal projects and work projects, and wanted to ask Node.js community.

Should we add this to tsc-agenda?

though master is the default git branch name so I would caution we pick our battles.

Is there an equivalent ask in git repo?
If not, we should create one.

Also, to all the people making the drive by comments: please keep discussion civil and remember Node.js has a code of conduct. If you can't be polite here you really don't have to comment. It's fine to either support or object to the proposed change (or any proposed change) as long as you are civil - we do not tolerate abuse towards the project and its members here.

To collaborators: kind reminder that you are allowed to ban users that make these sort of comments and to hide said comments - but please update the project (as explained there) with what actions you took so that any moderation actions taken are done in full transparency.

Is there an equivalent ask in git repo?

I'm not sure where the git repo is - but I recommend trying the mailing list and asking there https://git-scm.com/community

I think "doing whatever git does and bringing the issue to their attention" is a viable strategy - but again, I don't feel particularly strongly about the use of "master" and if someone else does - sure.

Should we add this to tsc-agenda?

I'm not entirely sure why?

Should we add this to tsc-agenda?

I'm not entirely sure why?

To let tsc make a call on this request.

Other option would be to keep this issue open for a week or so, and see if it gathers more feedback or support.

To let tsc make a call on this request.

As far as I understand it that's not how our governance works. Any collaborator may add the tsc-agenda label for an issue so it gets TSC eyes on it - but that should only be done if consensus seeking fails. It's an escape hatch for when we need to force a vote which is pretty rare. At least that is my understanding of the process.

So far everyone here seems to be pretty in sync (no one is opposed but no one is particularly in favor). We're not even in disagreement 😅

I'm not sure where the git repo is - but I recommend trying the mailing list and asking there git-scm.com/community

I've sent an email to Git Community mailing list, and will update here once they come up with a decision.

Bear in mind that URLs linking to master will not redirect to the new default branch name (and for repos where it matters, which isn't this one, github-pages only works on the default branch when it's named master). It may be worth waiting for Github to fix these discrepancies before making the switch.

(to be clear; i'm in favor of making the change, and "main" seems as good as anything else, but the disruption caused by Github's incomplete support for a non-master default branch are significant)

+1 to main but I do want to see what lead GitHub takes in making this easier

I personally feel very strongly that we should change this.

+1 to main

I would be -1 untill a plan is drawn for the changes. This could cause a lot of issues with our build ci which would need to be accounted for.

Ok, it looks like there are people in favor in the org who feel strongly that we should change this. So far no objections and everyone in the conversation is +0 -0 or +1.

Does anyone object to changing this (just the main branch name from master to main)?

It looks like it's not particularly hard technically (+ an update to the collaborator guide and policy). We probably need to address the links as well.

So far no objections and everyone in the conversation is +0 -0 or +1.

What about #33864 (comment)?

Also, I think GitHub might pick trunk instead of main. cli/cli#929...

Does anyone object to changing this (just the main branch name from master to main)?

I don't object... but I don't think it's a good idea to rush this...

Fwiw there is quite a lot of work for us to do in order to make sure we do this in a way that is not disruptive.

To @AshCripps point, we definitely need to do a large audit and preparation before moving forward.

I was putting together some notes yesterday outlining steps to take and what to consider before making a change like this

I'd like to suggest that we pause discussion until Monday and I can come back with a suggestion of what we should audit and steps to follow to do this in a way that would minimize disruption

@ronag that message was posted after I started writing mine so I did not see it. Sorry for the (timing) confusion. Fwiw #33864 (comment) isn't a conceptual -1 it's a -1 until a plan is drawn for how we make the changes. I thought that not making the change quickly without discussing this or laying out how (clearly) is a given.

Needlessly censoring words does nothing to resolve the social issues surrounding them. The reasoning behind this is the same used when changing the gun emoji to a squirt gun. But in the end, such efforts only take away words and symbols we can use to easily describe concepts, such as the hierarchical and control structures we work with every day. It's destructive at worst and pointless virtue signalling at best.

Anyway, -1 to this. Not worth the effort.

I am -1 on renaming/changing the branch.

-1 on this.

Putting this on the tsc agenda for discussion

-1 on renaming the branch

I would recommend we escalate this (to a vote for example) when:

• We have a clear plan on how to make this change addressing the raised issues (GH links, build infrastructure etc).
• We have an individual or group willing to champion those changes.

Can either of the collaborators -1ing (@gireeshpunathil / @mscdex ) speak up regarding what in particular they are objecting to? (The process of changing it? the name main itself?)

Also, this issue is locked because it has received a large number of abuse comments. Like the website change - changes with this flavor tend to get a lot of attention.

I can come back with a suggestion of what we should audit and steps to follow to do this in a way that would minimize disruption

@MylesBorins Also think about how to roll back when things go wrong. Auditing Jenkins jobs is the kind of mind-numbing tedium that makes human error more likely than not.

@benjamingr I don't think such a change is necessary and by making such a change it would be creating a lot of technical issues. I've never heard anyone seriously say they found the branch name offensive since git's inception, much like I've never heard anyone seriously find similar terminology offensive elsewhere in computing in the many decades it's been in use.

I believe attaching a single context to such technical terminology (that involves inanimate things) is not useful. Instead, everyone should be focusing their time and effort on things in the world that are actually and obviously offensive.

@mscdex

much like I've never heard anyone seriously find similar terminology offensive...

That's literally what you're seeing here. Keep in mind that what you might consider "actually" and "obviously" offensive will differ significantly from what others may find "actually" and "obviously" offensive.

There are definitely some very real and difficult technical challenges to address here. My suggestion would be to make this a strategic initiative with the first step being to establish precisely how to make this change with the least amount of disruption.

As a community that has pledged for inclusivity, it is natural to be sensitive and sympathetic to the current situations. However, I guess taking a step back and looking at things from a more wider perspective, I would ask these questions myself, in order:

• Is Node.js community well represented by race, gender, ...? any process change required for the membership criteria for better inclusion of under-represented groups?
• Is Node.js leadership well represented by race, gender, ...? again, any process change required?
• Is Node.js process and practices designed to be inclusive, and is it working well? a retrospective session with commitment to acting on the results?
• Is Node.js nomenclature, words used etc. free from offensive terms? (items such as this)

Doing the naming change first - easy, but causes turbulence in the eco-system, plus gives an impression that we are good with the rest (it is so possible that we are doing good there, but we haven't inspected). Addressing the other things - difficult and time consuming, but addresses the root of the issue from systemic perspectives.

I am willing, and eager to taking part, and / or driving such initiatives, if there is a consensus on Let us do these things first, and attack this later!!!

That's literally what you're seeing here.

Are you referring to the OP? If so, that didn't exactly strike me as someone saying they personally find the term offensive. To me the issue text read more like "hey, other people are making this change in other projects, should we do it too?".

Keep in mind that what you might consider "actually" and "obviously" offensive will differ significantly from what others may find "actually" and "obviously" offensive.

Here "actually" and "obviously" was meant to describe things that a greater majority of people can agree are offensive.

To make it explicit, I am strongly +1 on doing this. This is not mutually exclusive with other initiatives in any way.

As for the technical issues, we can either wait to see if something comes from Github, or implement tooling ourselves that would keep the current branch name synced/as an alias, for example.

I'd like to echo the sentiment from @addaleax that changing the branch name need not be mutually exclusive from other changes which our project likely needs to do to be more welcoming / inclusive. We should always be examining our process and thinking about what we can do to improve and make small iterative changes towards where we want to be.

The term master for the main tracking branch is something that has always bothered me. To push back against any narrative that might claim that changing the name of the branch is a fad I'd like to point to https://github.com/mylesborins/node-osc which is one of my more popular modules. I have been using the name current rather than master for over a year. The only reason why I had not brought up making this change at the project was because I didn't think it would have the momentum to be successful, not because I didn't believe that this change should be made.

@mscdex do you have specific technical failures you are concerned will happen? Would an in depth transfer that speaks to all of those changes put your mind at ease? If there was a way to ensure that anyone attempting to push or work with master in the future would be gracefully redirected by GitHub help to ease those concerns (this is a feature I'm poking at internally to see if it can be offered).

I believe attaching a single context to such technical terminology (that involves inanimate things) is not useful. Instead, everyone should be focusing their time and effort on things in the world that are actually and obviously offensive.

We debated extensively about naming API surfaces, why should this be any different? We accepted a default and those helping to create that default are saying "hmm, maybe we should reconsider this". Even if you don't find it useful to attach that context does that fact that others do, and in turn it makes them less productive at what they do, not resonate with you?

Doing the naming change first - easy, but causes turbulence in the eco-system, plus gives an impression that we are good with the rest (it is so possible that we are doing good there, but we haven't inspected). Addressing the other things - difficult and time consuming, but addresses the root of the issue from systemic perspectives.

@gireeshpunathil I'm having a really hard time parsing the logic here. It seems like you are saying that because making this change will be easier than other changes will imply there is no other work to be done? I don't think anyone is saying that at all. What I do see people saying is that this is a small incremental change, that will take quite a bit of work to do properly... but one that I think will be meaningful to various members of our community.

FWIW I've been thinking quite a bit about our governance model, and more specifically consensus seeking, to examine if it is the best governance model for an inclusive environment. I proposed a openjs world summit session to discuss it as well!

I truly think that making positive social change is an ongoing effort that requires constant small change in the right direction. In fact I would argue that choosing to not make smaller, more obvious, iterative changes (such as changing our default branch) would have the inverse effect of telling people that Node.js is an environment that does not care about this.

Also some interesting references for this discussion

Original Discussion on git mailing list

Proposed change to git to allow overriding the default branch

A contributor from bitbucket stating the github + bitbucket + git are all working on this together

A great twitter thread explaining why making this change is the right choice

A statement from a GitHub employee that main is likely to be the new default

A checklist used by the github cli to change default branch

A tool by @gr2m to automate the process of changing the branch

Discussion about changing defaults in GitLab

It seems like you are saying that because making this change will be easier than other changes will imply there is no other work to be done?

@MylesBorins - that was an addendum. My main point is that the other items that I listed are more tangible, personal and direct to the people / group who are subjected to the theme in question, and hence present a natural order to address.

I now see your submission in collab summit, and acknowledge it as part of a constant attempt towards improving our community, in the context of diversity and inclusivity! thank you!!

Not a TSC member, but I am a +1 to this change, echoing @addaleax and @MylesBorins sentiments that these do not need to be synchronous changes but can be done simultaneously as we do more intensive work.

For full transparency, I've also brought up the possibility of doing this with all repos under the @nodejs/community-committee.