Communication doc: improvements

COMMUNICATION.md

@@ -2,22 +2,62 @@
 
 ## Document purpose
 
-OpenTelemetry has a [Code of Conduct](https://github.com/open-telemetry/community/blob/master/code-of-conduct.md) which primarily pertains to "bannable" offenses: things like harassment, personal attacks, and so on. Certainly OpenTelemetry does not tolerate any such behavior.
-
-And while we all deserve to collaborate without fear of overt harassment and personal attacks, that is a very low bar! This document is more aspirational and has fewer "teeth" (i.e., it's not about "banning" people), but it's also very important: 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 disagreement.
-
-Finally, this is **a living document** and should be adapted over time as the OpenTelemetry project evolves. 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.
-
-Now, without further ado:
+OpenTelemetry has a [Code of
+Conduct](https://github.com/open-telemetry/community/blob/master/code-of-conduct.md)
+where maintainers and community members pledge to foster welcoming and open
+community. Code of conduct gives examples of unacceptable behavior by
+participants like harassment, trolling or personal attacks which result in
+remove, edit, or reject any contributions to the project as well as declining
+participation in the project to individuals.
+
+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.
 
 ## Communication guidelines
 
-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](https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like/) 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 them for their interest and contributions, and being patient with their initial misunderstandings. In fact, their points of confusion are a valuable signal pointing towards documentation gaps.
-* **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 videoconference, 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._
-
+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](https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like/)
+  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._