Rename master branch, rename masterKey to primaryKey

[dblythy]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

With the industry removing references to the word "master", "slave", "whitelist", and other potentially harmful stereotypes, Parse should adopt this change to meet industry standards.

This would likely occur in two steps:

1. Renaming the master branch
2. Removing problematic language in codebase, would be a breaking change

Feature / Enhancement Description

Whether or not you personally agree with the change, I think at Parse we want to be ahead of the latest industry movements. Adopting this change would show our commitment to diversity and inclusivity and help promote our ideals of a welcoming developer community.

Plus, our Code of Conduct enforces inclusive language and participation, so any language that has the potential to cause harm, should be removed from our platform.

It should also be noted that we don't currently use any "master / slave" structures and mostly use "parent / child".

Thoughts and discussions welcomed, please keep it civil and respectful.

Example Use Case

.

Alternatives / Workarounds

Keep as is, address at some point in the future.

3rd Party References

To name a few who have done the same:

React
Django
PHP
curl
redis

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

Renaming the master branch to main is a consideration of the new branch model in release automation. If there are any specific terms, phrases or implications in code, comments or docs we can certainly reconsider them.

In general, we would carefully review what we change and why we change it. Some current initiatives are based in the context of specific U.S. American political debates, strongly related to U.S. history. These initiatives are not without controversy and sometimes instrumentalize terms for a political purpose, ignoring etymology or ambiguity. As a global software project we don't want to become a political playing field.

[dblythy]

Yeah, I agree. I personally think renaming the master branch to main is a good middle ground for the time being. Looking forward to release automation!

[cbaker6]

I brought this topic up to the core team over a year ago. It's the reason why any parse repo I manage or submitted a lot of code to currently use main branch as I've made the change to them, i.e.

• https://github.com/parse-community/Parse-Swift, PR that made change
• https://github.com/parse-community/parse-server-fs-adapter, PR that made change
• https://github.com/parse-community/ParseLiveQuery-iOS-OSX, PR that made change

I'll point out that the core team agreed to those changes before I made them and basically agreed at the time that repos with a lower following were easier to change. I've also brought the change to primaryKey at the same time. My comments from last year are below:

Hi everyone, I wanted to get peoples thoughts on moving the Parse-Swift default branch from “master” to “main”. I’m sure most of have seen the reasoning behind this and many repos on GitHub have made this change. Doing the change is pretty easy and settings, but will break somethings that can easily be fixed. Some adjustments I foresee are: 1) Travis, Circle, GitHub Actions (changing to main for tags or actions that occur on the master branch). 2) Changing the requirement to pass a build in settings from master to main

I think waiting is a possibility, definitely for some of the larger repos that have a big following. I made the change on my personal repo’s and ran into the issue I mentioned earlier. I know some of the Apple frameworks made the change in the last couple of weeks and it seems GitHub “might” have a way to switch the PRs over as well (this a potential issue I see. Waiting for the tool may automatically convert repos that have many pending PRs for us)

Just putting this on the radar for the future as making the change would probably be breaking for all of the repos is the language used in some of the variable naming (this problem is in codebases outside of Parse as well), but the "swift linter" is throwing warnings of "inclusive language" due to "useMasterKey". If the other linters aren't doing this yet, I'm sure they will soon. IMO it's better to jump in front of this early and make the change before someone asks on a public forum like GitHub, stack, or somewhere else and we have to reactively respond. You can see in Parse-Swift where I commented out these warnings https://github.com/parse-community/Parse-Swift/search?q=inclusive_language

To give insight on the type of language that's considered not inclusive, we can take a look at the "Migrating to version 4.2" section of pgpool https://www.pgpool.net/docs/latest/en/html/release-4-2-0.html For pgpool, they made a hard change on 4.2, didn't deprecate, that may or may not be the right way to do it in Parse...

[mtrezza]

The branch naming is currently being considered on the basis whether a developer expects the authoritative branch to be named master or main or whatever. This is merely a pragmatic consideration to cause the least friction with other tools and for a user / contributor to understand the branch model, not a political statement.

We acknowledge that there may be technological tools that make political statements, such as evaluating whether code is using "inclusive language" according to their arbitrary criteria, but that does not coerce this project into assuming their political position, nor into continuing to use these tools. We are a sovereign project that can have its own debate about this.

Branch naming is part of release automation and any non-technological, political discussion is better suited in the Community Forum, because of its scope and also because the topic is not confined to a single repository. Therefore I'll go ahead and close this issue.

[cbaker6]

The branch naming is currently being considered on the basis whether a developer expects the authoritative branch to be named master or main or whatever. This is merely a pragmatic consideration to cause the least friction with other tools and for a user / contributor to understand the branch model, not a political statement.

We acknowledge that there may be technological tools that make political statements, such as evaluating whether code is using "inclusive language" according to their arbitrary criteria, but that does not coerce this project into assuming their political position, nor into continuing to use these tools. We are to have our own debate about this.

I think it’s important to point out that @mtrezza’s comments represent his opinions and doesn’t represent the whole Core Team, or the Contributors. You comments definitely don’t represent anything or process I believe. The fact that you can post a comment like this:

In general, we would carefully review what we change and why we change it. Some current initiatives are based in the context of specific U.S. American political debates, strongly related to U.S. history.

Shows you are ignorant of history of the world, the history of the language you are currently writing in, along with the respective language derivative languages. Parse shouldn’t need to be, “coerced” as you put it to do the right thing.

Note, the comments I posted above began 9/12/20, @mtrezza you chose not to participate in any of the conversation, while the other Core Contributors did. It’s been a year+ since then and the other Core Team members agreed on the process and was simply waiting for Github to release the tools to make everything easier.

[dblythy]

Again, going back to our code of conduct, which states:

Examples of behavior that contributes to creating a positive environment include:

Using welcoming and inclusive language
Being respectful of differing viewpoints and experiences
...
Examples of unacceptable behavior by participants include:
Trolling, insulting/derogatory comments, and personal or political attacks
Other conduct which could reasonably be considered inappropriate in a professional setting

This is all an arbitrary criteria which is subjective to the beholder.

Regardless of whether an issue is related to US politics or not, by choosing to continue to use language that could potentially cause harm or upset our US audience, I personally don't see why migrating and limiting our potential to isolate people base on their race isn't the best course of action. If we choose not to change - then that's fine too, but realistically, if we want to promote an inclusive developer culture, this change must happen.

[mtrezza]

As I said above, I'm encouraging a proper debate about this topic, before we make any decisions with wide-ranging implications. This is not the place for a political discussion, we are using the forum for these types of discussions. I have opened a topic for that.

@cbaker6 I appreciate your comments. How the "right thing" should reflect itself in this project can be determined by a healthy and respectful debate.

To claim that something "must happen" preempts any outcome of a debate, which has not been held community wide yet. This would be dismissive of any other opinions and contrary to an inclusive culture.

I'm locking this issue due to the emotional reactions.