Approaching Projects

Approaching Projects with Proposed Changes

Once you start paying attention to inclusive language on your own projects, you’ll start noticing issues in other projects, and you might want to do something about it.

Unfortunately, if you rush in with a patch, this won’t always be positively received. Some will take it as a personal attack, while others will see the changes as silly, unnecessary, or even actively harmful. That first interaction will set the tone for all future language-related discussions, so it should not be rushed or tactless.

Here’s some things to think about before you make that first contact.

Remember whose side you’re on

The project is not your enemy to be defeated. Rather, they are colleagues who you can help communicate better. We are in this together, to improve the experience for users and developers.

In almost every case, language decisions that you are trying to change were made without intent. Avoid treating their language choices like offenses or attacks. Rather, they are past, innocent mistakes that you want to help them rectify, for the benefit of their users.

Rushing in with an attitude that the project has done a bad thing, and you’re there to fix it, is almost guaranteed to put everyone on the defensive, hurting your chance of success.

Do your homework

Open source projects are about conversations and collaboration. Take some time to learn something about the culture, and acceptable norms, before jumping into the conversation.

Read the mailing lists. See what discussions have already happened around the topic. If you bring up the topic, and there has already been a divisive discussion around it, you will undermine your own message.

See what the contribution process is. Drive-by patches from a random stranger might not be well received. Finding an ally within the community is often a less divisive approach.

Whatever you do, do NOT just show up with a patch without looking around first. Patches from unengaged community members might be well-received, but in this particular case may be seen as criticism, and you may harm not only your chances of constructive engagement, but also anyone else approaching with a similar goal.

Be patient

It took us years to get here. A few more weeks isn’t going to hurt anything. Rushing into things is a great way to miss the social/community cues, and make the wrong first impression.

Focus on the positive aspects of language choices

Rather than focusing on why the project’s chosen words are bad, focus on how your recommendations improve clarity, remove unintended connotations, or communicate more clearly to non-native speakers.

While a large part of this initiative is, of course, removing offensive or otherwise problematic phrasing, it’s also about all of those things - carefully, intentionally, consciusly selecting words and phrases that are the best possible ones to communicate the concepts.

Tell success stories, giving credit appropriately

If a project begins to move towards more inclusive language, you should celebrate this. Tell the story, and give all the credit to the project, rather than to yourself, for the changes. This isn’t about you, it’s about making software, and, by extension, the whole world, a more welcoming place.