A code of conduct guides the standards for behavior in a community, methods and structure for enforcement are well documented. What is less clear (but can be a big concern) for teams is how to manage day-to-day interactions that might cause tension, fatigue and burnout. This pocket guide is designed to help teams think through how to manage these interactions and create a plan for how to handle them.
Each section provides a 'prompt' for conversation and brainstorming. It is important to note that the prompts are not exhaustive and may not be relevant to every team or project.
Be mindful about who your collaborators are; those you will be intentional about engaging with, and those who may turn up to participate in some other way (friendly, or otherwise). As you go through the next sections, give time to consider the goals, motivations and challenges associated with each.
- Partners
- Developers
- Students
- Fans/Enthusiasts
- Influencers
- Users
- Customers
- Support Contributors (helping users)
- Designers
- Localizers
- Regionally-specific collaborators (language/geography)
- External Maintainers or other Community Leaders
- Other
What type of engagement do you think you'll see from these groups?
- Contribution (code, design, localization, documentation etc.)
- Bugs/Issues/Complaints
- Mentorship/Welcoming people
- Content Production (social media or otherwise)
- Leadership (GitHub triage role or other formalized position)
- Other
What feelings and moods do you think you'll see (or you have seen)?
As the pandemic made visible, there is so much more going on behind the scenes of people's lives than is visible in their online interactions. Your collaborators may be having one of their best days ever, or experiencing debilitating lows. In both cases, emotions can unintentionally bleed into interactions. Have a discussion with your team about how you might amplify positive interactions, and diffuse the more challenging.
Remember: You are representing your project/company/organization in the Open; as such, it's critical that interactions are respectful and professional; at all times, and on all platforms. Be curious! Its surprising how a situation can be diffused, by asking simple follow-up questions, showing empathy and seeking clarity.
Some moods you may run into:
- Enthusiasm
- Frustration
- Excitement
- Anger
- Admiration
- Helpfulness
- Self-doubt
- Fear
- Creativity
- Arrogance
- Happiness
- Exhaustion
- Urgency
If, for any reason, you feel out of your comfort zone, refer to your organizational or team leadership.
What tools are you using for these collaborations?Which are company/project/org-owned/managed tools? Your Code of Conduct applies to all spaces owned by company/project/org, these include things like GitHub repository.
- GitHub Issues and Pull Request conversations
- GitHub Discussions
- Forums
- Mailing Lists
- Blog(s)
- Chat channels
Which are owned/governed by external individuals or groups?
Keep in mind, that unless articulated otherwise, these spaces are governed at the discretion of the channel/platform owner.
- Slack
- Discord
- Discourse
- Riot/Matrix
- Twitter/Threads
- IRC
📣 You MUST have a plan for each of these should an employee report or experience a violation of that Code of Conduct. For each, document for your team, who the accountable channel owners are, where to find the Code of Conduct and how to report incidents. If you can not find this information, it's strongly recommended that you find alternate spaces for this collaboration.
The Open Source Code of Conduct outlines 'Expected Behaviors', but it's important to lay ground work in the context of your project spaces. You can do this in the README, or CONTRIBUTING, or make use of issue templates- the point being, that by having these documented somewhere, it's easy to point to as evidence of project expectations
- Use people's pronouns
- Add alt text to shared images
- Ask questions, seek to understand before challenging or correcting
- Gratitude - a simple thank you goes a long way
- Patience - give time for maintainers to respond to issues, pings and the like
- Celebrate each other's success
- Avoid comparison of contribution value, frequency or importance
- Remember that life happens, sometimes people are away for personal reasons, and not ignoring you
- Other - what other behaviors would you add?
- Adhere to the
- Your Open Source Code of Conduct
- Following documented template prompts for reporting an issue or submitting a PR on GitHub
- Look for open issues of the same topic, before opening a new one.
- Other policy
Remember, what's unacceptable in a business setting, is also unacceptable in Open Source collaborations. This is true no matter someone's role, tenure, popularity or influence. By documenting these specifically in the context of your project, you are setting a bar aligned with your Code of Conduct.
📣It's helpful to be specific, as phrases like 'Don't be a jerk' which are often left to interpretation of what being a jerk means.
Many Code of Conduct lists 'disruptive behavior' as a violation, which creates room for maintainers and community leaders alike, to identify behaviors that are disruptive in the context of their specific projects. There are some that, are easy (like no spamming), but others like the repeated re-opening of issues can seem to be blurry.
📣 If behaviors contribute to continued distraction of your team, or which adds stress to the collaborations in your community, chances are the behavior is disruptive should be addressed.
- Avoid use of ALL CAPS as a way of emphasis or yelling
- Don't re-open issues when sufficient attempts have been made to address the concern
- No Spamming, advertising or promotion of professional services
- What other disruptive activities would you want to include?
At the top of the many codes of conduct you'll see 'Our Pledge', which then lists what's often called 'protected groups', or 'supported groups'. These groups are those who have, historically, been excluded, made invisible or harmed in Open Source communities. This list signals accountability for the experiences of the most vulnerable and marginalized groups in communities, and accountability to ourselves. As such, it's important to be on the lookout for behaviors that may target these groups.
Suggestion: document a moderation plan internally, so that you can be consistent.
For example...
- Don't dead-name people (use people's former names)
- Don't comment on someone's appearance in any way
- Don' English as a first language, avoid jargon and slang
- Negative behaviors in non-project spaces which have negative impact on the community, this includes making personal comments on social media
- Don't use racist, sexist or discriminatory words in any interaction.
- What other behaviors have you seen, which you would like to call out specifically?
Below are some ways a Code of Conduct/or escalation of what-seem-like-minor violations might be addressed, according to severity.
For the steps below, your team should have a conversation about accountability, but also document things like has admin-access should you need to ban an account.
Generally, a warning is something given in good faith. You believe someone has made an error, isn't self-aware, may be having a bad day or is otherwise going to be receptive to the warning. It's important to differentiate between behaviors that are disruptive (like re-opening an issue in disagreement), and those which have an impact (intended or not) on people.
Here is a sample warning notice.
Like Warnings, there is a huge leap of faith on your part that the person given the decision will be receptive to a second-chance. It can be a good opportunity if someone is experiencing external stress in their lives to take time, reflect and return, but this option isn't recommended unless you have this level of insight. Statistically even with this thoughtful evaluation, temporary bans have about a 50/50 success rate.
Here is an example of a temporary ban notice, which includes an on-boarding before return. .
A full ban is just as it sounds - removal from all participation in all project spaces. This might occur after a warning was unsuccessful. Or, because an account was obviously created to spam - or someone is just so clearly showing no intent to participate professionally, and inclusively.
This is the time to revisit all of the different spaces your project collaborates on and with.
If someone looks like a 'drive by' participant in your project or community ( unknown account, with only disruptive, spammy, harmful or otherwise nuisance interactions), reach out to your escalation path to request their account be banned.
Use this as a workspace to detail the steps your team will follow in event someone displays any of the discouraged behaviors in the Code of Conduct, or as listed in your CONTRIBUTING.md/README.md
Who should be consulted? Who will make the final decision if there is a disagreement?
It's good to have someone responsible and trusted to sign-off on decisions, when it makes sense. If you are unsure, or there is a tension or anything which feels out of scope for your team to manage, it probably is out of scope, and you should reach out to your manager, or skip level following the same process identified at the top of this document.
Here are some examples of how you might, as a team, document your approach. It's important to remember, that no incident will be the same, and thus some of these will need to be tweaked for the situation. Nonetheless it's good to have a plan!
For all drive-by violations: Those violations by accounts we do not know, and who are causing disruption despite warning/correction.
We will...
- Immediately email escalation pathway and request their ban on GitHub.
- Take any other steps to ban the individual from tools immediately.
For violations described in the Code of Conduct, or explicitly in our project documentation by a known community member as disruptive we will..
- Give one warning then ban if they continue.
For violations where the behavior is clearly seeking to be disruptive and the person isn't known in the community
We will...
- Ban immediately
For all minor violations that may involve someone who is of high reputation, and significant to the project in some way (long time contributor, customer etc)
We will...
- Talk to escalation pathway
- Warn directly/privately
For all major violations that may involve someone who is of high reputation, and significant to the project in some way (long time contributor, customer etc)
We will...
- Talk to escalation pathway
- Issue a temporary or permanent ban
Set aside some team time to agree on your steps.
We will...
- Publicly warn the person so, we deem a 1:1 message to make more sense
- Update the reporter (if not on the team) on the actions we took
- Monitor
We will...
- Have a team conversation to create a checklist for action including review of all owned and not-owned spaces where this person collaborates.
- Update the reporter (if not no the team) on the actions we took
- Disable participation on all systems
- Set a date for return
- Schedule a 1:1 chat with the person returning with guidelines for their return
- Monitor
We will...
- have a team conversation to create a checklist for action including review of all owned and not-owned spaces where this person collaborates.
- update the reporter (if not no the team) on the actions we took
By now you should have a solid idea of how you and your team want to lead by example the behaviors Open Source Code of Conduct; how you plan to share expectations in the context of your project spaces, and tactical steps for following-through on enforcement.