Use more inclusive naming for GitHub branches

[kevinswiber]

For the purpose of more inclusive naming, would the AsyncAPI maintainers consider renaming GitHub repo master branches to main?

Here is some context, provided by the Inclusive Naming Initiative:

Master
In computing, A “master” often refers to the original or main version of an entity.

• main
• original
• source
• control plane

Reasoning:

While master in and of itself is potentially neutral, the propensity in which it is associated with the term slave in computing makes master on its own guilty by association. Though it is used as a standalone, it’s impossible to remove the association with command and control entirely, and thus we recommend moving away from even singular use.

Recommendation: Adopt immediately.

As referenced above, the recommendation for removing master-slave terminology is as follows:

As the IETF puts it, “Master-slave is an oppressive metaphor that will and should never become fully detached from history.” The word’s origins and historicial use reveal use that is at best chauvinistic and racist, and in almost all cases connotative of ownership. While there is some small ambiguity about the term master, the term slave is unambiguously about the ownership and subjugation of another person, and has been since its inception.

The terms master/slave are harmful to Black and people of color contributors and employees. Slavery is a tradition barely 3 generations abolished – there are grandparents alive today who were actual, non-metaphorical slaves. Segregation and Apartheid are even more recent. In accordance with most open source codes of conduct and company handbooks, the mandate of all people in a project is to create a welcoming space, regardless of the level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality. Master/slave are not welcoming words.

While the Inclusive Naming Initiative offers reasoning behind making the change, there has been some contention in the broader tech community regarding the term. That said, my interpretation of the AsyncAPI Initiative Code of Conduct leads me to believe that this community may consider the change important.

I'm certain this will represent a big effort, and I don't propose this change lightly. I'd appreciate your consideration!

[doc-jones]

This is an interesting article on some things that can go wrong and how to fix them when moving from master to main.
https://onesignal.com/blog/converting-github-repositories-to-main/

[quetzalliwrites]

Nice new thread 🧵 ! Thank you for starting this one, @kevinswiber!

I wanted to note (for our USA OSS members) that outside of the USA, GitHub does a terrible job of communicating and syncing w/ community on changes. When they made the world-wide change of main, they did not do a good job of communicating with different countries about the historic background of slavery and why they didn't keep using the word master. By not being inclusive in their treatment and communication of this big (and breaking!) change, they accidentally confused and caused harm in OSS communities outside the USA.

You must understand that USA companies that control tech that is often used world-wide consistently forget outside cultures and users. This is not a good way to make a product more inclusive! It takes work to make important changes and to make sure you take the time to explain well to the entire community why something needs to change.

Hopefully this background context can help our USA community members understand why this change hadn't arrived to this initiative yet. 🙂

[kevinswiber]

@alequetzalli Thank you for sharing your thoughts! I have edited the discussion to include excerpts provided by the Inclusive Naming Initiative. I've also linked to the AsyncAPI Code of Conduct, which may be interpreted as supporting such a change. I hope this helps provide enough context and clarity for our global community of AsyncAPI practitioners. I will do better to provide sufficient context going forward, especially for such a large breaking change with downstream impact. 🙏

[quetzalliwrites]

Muchas gracias, @kevinswiber. Lo aprecio muchísimo. 😀👍🏽

[smoya]

I can't add a lot to the topic, especially considering my privileged position. All I can say is that I would always try to do my best at making others feeling respected. So I totally +1 this.

Technically speaking, last time I raised this concern, we talked about this issue https://github.community/t/can-i-trigger-action-on-push-to-default-branch/145422/4 being a blocker.

Do you know if the workaround is still needed @derberg? Is the following a solution that can unblock us? : https://stackoverflow.com/questions/64781462/github-actions-default-branch-variable

[derberg]

Of course, it is not solved.... it is not so trendy topic anymore so why would GitHub care 😞

Stackoverflow link mentions ${{ github.event.repository.default_branch }} and $default-branch and non of them work, I tested quickly in my playground, no trigger.

So we simply need to update all workflows like this:

on:
  push:
    branches: 
      - master
      - main

and then once all is migrated change to:

on:
  push:
    branches: 
      - main

I don't remember what other things must be changed.

[derberg]

In addition to #140 (reply in thread)

This is a change that affects all the AsyncAPI projects that are under the maintenance of different people, from different parts of the world. So we basically need to perform voting in TSC as the change must be done globally. I personally don't think we can afford to have a complexity that will make us have some default branches called master and some main, we just need it for all.

IMHO prerequisite that needs to be done before voting is:

• we need a well-defined task with a checklist of things that must be done
• a group of volunteers to do it quickly in a group to not cause any disruption
• reason behind it (but I think it is already provided)

IMHO ☝🏼 is needed if we want it to be accepted easily. We have folks here from around the world, from different cultures, and I imagine that for some people the only important info will be "how much work does it take, and how will I be affected".

Anyway, this is my personal, not TSC opinion. Might be that none of the above is important and all folks agree immediately.

What do others think? I definitely might be wrong

[kevinswiber]

Having done this myself with several repos, there is a lot to consider, and I agree it's worth creating a checklist. There might be a solid one out there on the Internet somewhere.

One thing to consider is that package managers sometimes explicitly rely on master branch names when resolving dependencies. This was true for Cargo and Rust, last I checked. The pain I decided to endure was maintaining both a master and main until the issues with package managers are resolved. This may not be feasible for all repos at this time. However, I wanted to get the discussion somewhere on the radar sooner than later.

[quetzalliwrites]

Since it's a major change it makes sense to discuss it in the TSC I guess? But I also think that this is a big enough inclusion issue to merit getting fast-tracked. Of course, I understand nothing gets fast-tracked without actual help, so please do add me to the list of volunteers to delegate a piece of the work to.

If we make a checklist and then create issues for each task needed, we can have an Excel (yes, I hate excel too 😂) sheet to share the list of issues amongst us in this discussion thread too. That way it could be easier to divide the work this change implies.

[quetzalliwrites]

We could even make an event out of it and make a bit of an impromptu hackfest to make it fun for the entire community to join and help make the changes faster.

(Just throwing out ideas in case it helps. 💡 )

[derberg]

Let's do a checklist first, to understand how much work is needed, and then we really know if it is a big deal or not 🤷🏼

[derberg]

Yo, I started this issue to provide a checklist for all the changes that need to be done in the project to switch from master to main. Please contribute