OpenTelemetry has a Code of Conduct where maintainers and community members pledge to foster a welcoming and open community. The code of conduct cites examples of unacceptable behavior by participants – like harassment, trolling or personal attacks – that would lead to removal, revision, or rejection of contributions to the project.
And while we all deserve to collaborate without fear of overt harassment and personal attacks, that is a very low bar! This document is aspirational, it describes how we wish to communicate with each other and how we aspire to create an environment that cultivates trust, even in the face of inevitable technical and organizational disagreements.
Finally, this is a living document and should adapted over time as the OpenTelemetry project evolves and we face new challenges. At any time, there are certainly errors of omissions or even simple clarifications we can make to the wording here, and any and all are welcome to propose such changes.
What follows are an unordered list of principles that guide our communication with each other – both active community members as well as those who may just be "passing through" to file an issue or suggest an improvement.
- Critique ideas, not people: It's fine and expected to disagree about technology and project direction. Even when those disagreements are significant or frustrating, though, it isn't acceptable to criticize the participants as people. In fact, it's usually a sign that there's no strong technical argument being made. (More specifically, see this post for tips about code reviews in particular)
- Be welcoming: By nature, OpenTelemetry touches a lot of other projects and will thus have a larger-than-normal ratio of casual committers and passers-by. For this reason, it's especially important to be welcoming to newcomers. This means thanking people for their interest and contributions, and being patient with misunderstandings, especially by newcomers. In fact, newcomers points of confusion are a valuable signal pointing towards documentation gaps.
- Adjust your expectations Not every part of the project has a maintainer available for quick support or bug fix. For some people this project is a full time job, for others is a weekend project. Don't get frustrated when you don't get response fast as you expected, find the way to escalate your issue to the right people's attention.
- Try to keep conversations in the open: Where possible, try to have conversations in async formats like GitHub issues, PRs, and emails. If resolution requires a call or video conference, try to make a recording and notes available and discoverable to keep our community as accessible as possible across distant timezones.
- Strive for consensus, but don't require it: Of course it's great when we can get everyone to agree. And certainly everyone should be – and should feel heard. As a rule of thumb, if there is a lone dissenter (or three) in any given discussion, their points should be clearly addressed: not just with a simplistic "Sorry, I disagree," but with a principled counterargument. Finally, our formal process for escalation and decision-making is a matter of policy, not just a matter of communication; as such, it is out of scope for this document.
Additional guidelines, edits, or other improvements to the above are always welcome.