������Ƶ

The most recent to analyze the open-source community reported that 86% of open-source contributors identified as male, with the remaining 14% comprised of women, other genders and “did-not-answer” responses. Since that survey, , the open-source community has begun to work together to fix this bug, with many different solutions being hotly debated. The most discussed solution so far stems from the idea that a more inclusive environment leads to a diverse community – an oversimplification being: “be nice to each other and more people will want to be around you”. Many say that leading by example is the way to build an inclusive community but, as the numbers show, that clearly doesn’t work when those who lead aren’t aware that the example they’re setting is a bad one.

The majority of the conversation over the past few years has revolved around the implementation of Code of Conduct policies in order to set expectations for the behavior of participants. Sparked initially by conversations in the tech conference community (namely “” and the ), the idea of such policies has caused a surprising amount of controversy, especially considering their widespread implementation in the corporate world over the last two decades. In 2015, however, the open-source community saw a significant rise in these initiatives, with sample policies such as the being adopted into , including such well-known projects as GitLab, AngularJS, and RubyGems.

Despite being only a few weeks into 2016, the controversy surrounding this solution has already caused sent ripples through the open-source community this year. When the organizers of a Beirut-based Javascript conference violated their own Code of Conduct, the respected conference organisation to with the event. However, any positive support felt by marginalised members of the web development community as a result of the JSConf reaction was swiftly tempered by another incident, this time in the PHP community. The vitriolic reaction to the idea of implementing a Code of Conduct in their caused a prominent member of the community to and . It remains to be seen whether a by another community member will be implemented successfully, if at all – given that the is dominated by non-marginalised members it seems unlikely. The fact that the in implementing a Code of Conduct on their projects, where open-source projects like Ruby have so far failed due to overwhelming , is a never-ending source of disappointment and disillusionment for those who would be protected by such a policy.

So how can you, as a contributor, support inclusivity in the open-source community and help to improve the situation? Encouraging the take-up of Code of Conduct policies and “signal-boosting” (promoting the voices and opinions of others) those who advocate for such initiatives is a simple first step. If the project you’re contributing to already has such a policy then an even easier first step is to actually read it!

Of course, simply listing rules is no guarantee that they’ll prompt any improvement in the situation, and therefore commitment from the community (especially from those leading the project) is vital for successful implementation. Judging the level of commitment to enforcing a Code of Conduct can generally be determined by the answers to the following questions:

Does this Code of Conduct come from a respected source, such as Contributor Covenant or the ?

These reputable policies have evolved with the contribution of many different voices and this range of experiences is important and valuable in order to support as many marginalized groups as possible.

Is the conversation around the implementation or possible enforcement of these rules respectful and supportive of the intention behind it?

This helps to make it clear whether the implementation is simply a box-ticking, superficial exercise or is taken seriously by the project contributors.

Does the Code of Conduct specify unacceptable behaviors and contain clear methods for reporting and handling violations?

While it would be impossible to create an exhaustive list, specifying common inappropriate actions sets crystal clear expectations for everyone involved. A Code of Conduct that lacks a clear reporting process demonstrates that it does not have leadership that is willing to enforce it, and therefore is meaningless. Additionally, the false sense of security it provides is potentially dangerous.

If we return to the idea of “leading by example” for a moment, you can also contribute to an inclusive community by calling out unacceptable behavior – either directly with the person or by bringing it up through the reporting process laid out in the Code of Conduct. The more we challenge inappropriate or unwelcoming behavior in open-source communities, the more inclusive they will be. Oftentimes people are unaware of just how detrimental their behavior is to the community – sometimes all that is needed is a friendly reminder to be more mindful of others.

In a similar vein, it’s important to accept when you are called out on your behavior. We all have to accept that we’re still learning how to improve the open-source community – free speech rights are not violated when someone is criticized for being offensive and asked to modify their behavior. In such a dispersed online space as the open-source community, it’s best to remember that you really are what you write – your “banter” from real-life interactions or offline reputation as good person simply is not carried over into online spaces.

But open-source isn’t just about code; it’s also about communication. Wherever that communication takes place, whether in issue comments or the project’s IRC channel, it’s important that it respects and supports other community members. In an effort to move inclusivity beyond the repository, additional developments have been made in bots for the tech industry’s prominent communication tool, . Written as simple text detection and response instructions, an increasing number of open-source groups are making use of these bots to automatically, and in a neutral manner, (such as sexist or racist comments) in shared communication spaces related to the project. Open-source projects such as have seen very positive results come from such implementations and are planning future expansion for its usage into other areas, such as their continuous integration workflow. These sorts of solutions encourage the community to be more mindful of speaking to each other in a respectful manner and it is reassuring to see even larger organisations .

A common theme in the process of evolving the open-source community is that respectful treatment of others should simply come down to basic manners and therefore “don’t be a jerk” or “be excellent to each other” is enough instruction. However, that assumes that everyone has the same expectations of what being “a jerk” or “excellent” to each other requires – and quite frankly, they don’t. Some people need rules, calling out of unacceptable behavior or, in extreme cases, penalties. As with every part of a civilized society, supporting the implementation, evolution and enforcement of even seemingly obvious rules is an important part of making the entire community a better place for everyone involved. Contributing to an inclusive open-source community will result in better code from a more diverse range of developers and so, hopefully, the next time the FLOSS survey rolls around the numbers won’t be quite so dire.