More inclusive branches
GitHub has changed its default branch tomain,when it previously used master as the branch name for new repositories. This, however, is derived from master/slave name conventions associated with historical atrocities. It is only logical that we understand this and adapt — making a little change with a giant social impact.
Changing branches in GitHub is easy to do. If you go to the Settings > Branches tab in your repository, you can rename your possible old master branch to main. Once this change is done on the remote, all the local copies of the repository have to be changed. This can be done with the following set of git commands:
This will make sure that:
- The local branch name is changed to
main.- Your local
mainbranch has the most recent history from the remote. - Your local
mainbranch is set to the new upstream. - Reset a remote branch to a new origin.
For more information on git commands, see their official documentation and this post on the specific topic.
Note that when you want to rename a fork of a GitHub repository where this change has been made, you will need to update the branches of your fork first.
Renaming your branch name doesn’t require much work, so go ahead!
More inclusive code
The second place where we should look for more inclusive opportunities is the code base itself. Often, we use common practices or names that haven’t been changed in a long time. A very good example is the term ”white” or ”black” listing, where color defines allow/deny functionality. The link to race can be easily made.
Changing this to an allow/deny list not only removes the issue, but also makes the functionality clear.
Deprecating functionality can also be easily and quickly done. If we provide a descriptive user message like: Use 'denylist' for a more inclusive code base ♥, we can gently guide developers to a more neutral ground. However, it is important that we guide, rather than force people. Explanations, patience, and friendly recommendations are the way to go.
More inclusive documentation
The last thing we should go over is the feature documentation. While writing code documentation on how the software should be used, unnecessary pronouns making it less inclusive could slip in.
Feature documentation is sometimes written in terms of he/his. ‘If the consumer wants to use this, he can implement this.’ We should be careful not to exclude people and use the more general ‘they’ or ‘one’. I.e: ‘If the consumer wants to use this, one/they can implement this.’
This is about a single-word change, but it could mean the difference between inclusivity and exclusivity. A quick word search for he/his on your documentation files should already help you a lot with this.
Conclusion
Note that each title starts with ‘More inclusive’ and not ‘Inclusive’. Inclusion is a verb, not a state. It is about continuously striving toward the ideal place for each and every person. This is not about continuously correcting or shaming people because they describe something in a particular way. It’s about helping and educating each other about the impact of what we do. These could seem like small changes but they are in fact indications of kindness. Instead of discussing whether this or that is shameful, we should try to be as open-minded as we can.
Software development has the luxury of being very flexible. We can make groundbreaking changes with very little effort. Now let’s use this power to make groundbreaking, inclusive changes.
Thanks for reading,
Stijn
Subscribe to our RSS feed