Terminology and Depictions across Parse Platform

The purpose of this topic is to have an open, inclusive and respectful debate about potentially objectionable terminology and depictions used across Parse Platform. This includes code such as variable and function names, code comments, product configuration option names, documentations, graphics and other material.

Some examples are (not all necessary currently used within Parse Platform):

  • controversial terminology: master branch, master key or white/blacklist
  • non-inclusive terminology: binary pronouns usage (he/she) dismissing non-binary gender identities
  • depictions: using images / icons / emojis of a specific gender / ethnicity or weapon such as sword, pistol, or bomb

Why?

This is a controversial political topic that has previously led to wide ranging discussions in other companies and organizations. Inclusion begins with an inclusive discussion, allowing all opinions to be voiced and any opposing opinions to challenge each other, before coming to a conclusion. A healthy and respectful discussion culture is the basis for a cohesive community.

The goal of this discussion is to:

  • identify any changes that should be made and estimate when and how they should be made
  • develop a policy or add a reference to a 3rd party standard that we want to adopt

Current status

While the Project Management Committee has repeatedly and recently discussed this topic internally, there hasnā€™t been a broad, community-wide discussion about this yet. The current approach is to gradually ā€œease-inā€ changes that follow where the industry is moving. About a year ago, GitHub began to suggest the default branch name to be changed to main instead of master, but was still in the process of providing the tools and mechanisms to do so in a less disruptive way. Today renaming the default branch works mostly frictionless, and renaming the master branch to main is part of the new branch model for release automation.

Considerations

  • This discussion originated in the context of U.S. American politics; while we welcome the general development of societal linguistic awareness, we donā€™t want Parse Platform to become a political playing field for day-to-day politics or adopt the toxicity that unfortunately too often comes with political debates.
  • A broad discussion should appreciate that Parse Platform has a large anglophone community and be sensitive towards regional aspects, while also appreciating that Parse Platform has a global community that represents a wide range of opinions that may go beyond or diverge from any other regional opinion.
  • There are technological (effort / compatibility) implications to any proposed change which should be taken in to account when making decision in this political discussion.
  • Be respectful, appreciative and inclusive towards anyoneā€™s opinion, whether you agree with it or not. Personal attacks or offensive language is not tolerated and a moderator will take action if necessary.

References

I think this is no longer the case, here.

Many open source projects and global companies have adopted the change. Although we arenā€™t a centralised US OS project, considering our code is specifically in US english (we use color, centralized, etc), I think it makes sense to follow culturally inclusive and acceptable language, considering not doing so is a deliberate choice hereafter.

I also personally think we should be setting the standards for our community around professional standards. We actively promote inclusion and acceptance within our community, so our coding standards should do the same.

1 Like

Thanks for the correction, I updated the post.

I should add that in my view, inclusive language should be encouraged, not enforced. I donā€™t promote exiling someone because they accidentally mis-pronoun another community member, for example.

Encouraging our community to apply inclusive coding standards and language should be a nurturing and supportive experience, preparing developers for the expectations that professional environments employ.

Maintaining the status-quo could potentially promote undesirable language that could subjectively reflect poorly on our great developer community.

1 Like