Inclusive language in code and documentation

[bwaidelich]

We are a an open and inclusive community and code/documentation should reflect that by replacing words that might exlclude or provoke minorities.

From the Neos 5.3 Release Nodes:

Words are not only "letters stringed together". They also include a lot of meaning. Within software development there are some include/exclude concepts based on the terminology of "white" which, to be super clear, has no correlation with something being "included"/"allowed" and "black" not with being "excluded"/"disallowed" under any possible point of view.

[albe]

One open point we might want to discuss/decide on is our default branch name(s). A couple of other projects have already removed their "master" branch in favor of something more on point. Here a few ideas on how to approach this:

• just keep "master" 🤷 (note: it really originates from the master/slave naming concept, but could be re-interpreted as "master record" as in music, but that's a far stretch IMO - anyways and independently of the root meaning, there are better options once again)
• "main" (new default in GH and according to them the most used alternative)
• "next"
• "development"
• "unstable"
• just the following versions specifier, i.e. currently "7.0.x" (that's what e.g. doctrine did), possibly with a "dev-" prefix

https://github.com/github/renaming

Then the question is when to do that: GH will provide tools for making the change seemless later this year, to avoid having to retarget all open PRs etc.

[robertlemke]

I'm all in favor of renaming our Git "master" branches to "main". As described in the Github document (https://github.com/github/renaming#later-this-year), we might wait with this until Github's tools are ready. Until then we may want to post an RFC on discuss.neos.io which ends with a voting by the Neos Team.

[bwaidelich]

I agree to roberts comment and removed this issue from the project board for now (since we can do that after the release still)

[albe]

Coming back to this, what GH provides as of now is a pretty straightforward "rename" branch tool: https://github.com/github/renaming#renaming-existing-branches

So we could in fact rename our head branch, but need to take care of additional steps in

• GH actions
• Jenkins
• bot integrations (?)
• all developers local branches (GH will show a helpful message when trying to push to old)

I thought about a gradual move for a while, with creating a shadow main branch first, then switching default with keeping a shadow master and eventually removing that. While that sounds smooth, it will be a very long process, it will not prevent things breaking when switching, will create another branch we need to keep in sync and finally not profit from GH convenience mentioned above. Hence why I would consider doing a github rename sometime soon (maybe for/directly after next release? So any PRs following afterwards can just directly target main and there's time for everyone to adjust)