Be Kind Communications Guidelines

Article Cover Photo by unsplash-logoMatt Collamer

This is a snapshot of a living document I am working on. The canonical version is on github. If you wish for the latest version of the below text, please check there.


By Lee Hilton

Original GNU Kind Communications Guidelines by Richard Stallman

Purpose

In the last several years, the community at and around the GNU project has been debating and building a standard document describing how to communicate with each other. The result is the GNU Kind Communications Guidelines, a wonderful attempt at codifying a mindset that is oriented towards solving problems.

A core problem that needs solving in much of society and especially the software world is around inclusion. Gender, race and sexual orientation are only a couple of the vectors that exclusionary behavior can travel along. Our culture, specific to the free software world and more broadly, both intentionally and unintentionally communicates in ways that create barriers for vast numbers of people to participate.

Flaws

The original document linked above is not without some known flaws. Originally it did not include the footnote concerning preferred pronouns. Richard Stallman, founding member and long time public face of GNU, has long been a proponent of a very specific solution to personal pronouns. He was advocating strongly for simply adopting “person”, “per” and “pers” in place of any pronoun originally, and at some point must have been convinced of the simpler “use the identifiers you are asked to use, if and when you are asked”.

There are other issues. For example some people reading this could may take way the advice to “cow down to the other person(s)”. The opening item on this list especially, telling the reader to "assume good intentions". If you are a person subjected to cultural repression, this would be a painful takeaway.

I hope that time, learning and clear thinking allows the guidelines to resolve this bug. It is not the intention to tell anyone to acquiesce their space and rights to another person, so if it does that then it needs fixing.

This is a living document. If we find bugs and flaws in it then we can fix them.

Why “Be Kind”

An aspirational goal I have is to be the type of person that everyone is comfortable working with. Regardless of who you are, where you come from, any matrix of personal qualities that you identify yourself under. I want you to feel valued, I want you to feel welcome, and I want us both to benefit in equal measure from knowing each other.

That type of goal requires work. It also transcends online conversations and enters the real world. It isn’t solely about software. It is about the way we live. It is about actions. Realizing I was going to fork the document and evolve it away from its focus on GNU’s organizational interests I decided it was easiest to simply drop the GNU and turn it into an action.

It is incumbent on the reader to understand that this isn't a set of hard and fast rules. It is not a perfect map. It is a set if ideas to help achieve goals. One of many way to become a welcoming and inclusive person. Using these thoughts may require hard, possibly painful, self examination and work. Do it, do the hard thing. The world deserves you at your best.

Guidelines

  1. Please assume other people are speaking in good faith, even if you disagree with what they say. When people present ideas as their own, please accept it as their idea. Please do not criticize people for wrongs that you only speculate they may have done; stick to what they actually say and actually do.
  1. Please think about how to treat other people with respect, especially when you disagree with them. For instance, call them by the names they use, and honor their preferences about their gender identity [1]. If you learn that a term, name or idiom inflicts pain, assume the person expressing the objection is genuine and remove from you vocabulary that which harms. It costs nothing to speak kindly.
  1. Please do not take a harsh tone towards other people, and especially don’t make personal attacks against them. Go out of your way to show that you are criticizing an idea, not a person. Often it is worth exploring the idea instead of criticizing. Seek to learn if an agreeable idea is simply obscured by phrasing you object to and help bring to light that which is worthy.
  1. Please recognize that criticism of your statements is not a personal attack on you. If you feel that someone has attacked you, or offended your personal dignity, please don’t “hit back” with another personal attack. That tends to start a vicious circle of escalating verbal aggression. A private response, politely stating your feelings as feelings, and asking for peace, may calm things down. Write it, set it aside for hours or a day, revise it to remove the anger, and only then send it.
  1. Please avoid statements about the presumed typical desires, capabilities or actions of some demographic group. They can offend people in that group, and they are always off-topic in GNU Project discussions.
  1. Please be especially kind to other contributors when saying they made a mistake. Programming means making lots of mistakes, and we all do so—this is why regression tests are useful. Conscientious programmers make mistakes, and then fix them. It is helpful to show contributors that being imperfect is normal, so we don’t hold it against them, and that we appreciate their imperfect contributions though we hope they follow through by fixing any problems in them.
  1. Likewise, be kind when pointing out to other contributors that they should stop using certain nonfree software. For their own sake, they ought to free themselves, but we welcome their contributions to our software packages even if they don’t do that. So these reminders should be gentle and not too frequent—don’t nag. By contrast, to suggest that others run a nonfree program opposes the basic principles of GNU, so it is not allowed in GNU Project discussions.
  1. Please respond to what people actually said, not to exaggerations of their views. Your criticism will not be constructive if it is aimed at a target other than their real views.
  1. If in a discussion someone brings up a tangent to the topic at hand, please keep the discussion on track by focusing on the current topic rather than the tangent. This is not to say that the tangent is bad, or not interesting to discuss—only that it shouldn’t interfere with discussion of the issue at hand. In most cases, it is also off-topic, so those interested ought to discuss it somewhere else. If you think the tangent is an important and pertinent issue, please bring it up as a separate discussion, with a Subject field to fit, and consider waiting for the end of the current discussion.
  1. Rather than trying to have the last word, look for the times when there is no need to reply, perhaps because you already made the relevant point clear enough. If you know something about the game of Go, this analogy might clarify that: when the other player’s move is not strong enough to require a direct response, it is advantageous to give it none and instead move elsewhere.
  1. Please don’t argue unceasingly for your preferred course of action when a decision for some other course has already been made. That tends to block the activity’s progress.
  1. If others have irritated you, perhaps by disregarding these guidelines, please don’t excoriate them, and especially please don’t hold a grudge against them. The constructive approach is to encourage and help other people to do better. When they are trying to learn to do better, please give them plenty of chances.
  1. If other participants complain about the way you express your ideas, please make an effort to cater to them. You can find ways to express the same points while making others more comfortable. You are more likely to persuade others if you don’t arouse ire about secondary things.
  1. Please don’t raise unrelated political issues in GNU Project discussions, because they are off-topic. The only political positions that the GNU Project endorses are (1) that users should have control of their own computing (for instance, through free software) and (2) supporting basic human rights in computing. We don’t require you as a contributor to agree with these two points, but you do need to accept that our decisions will be based on them.

By making an effort to follow these guidelines, we will encourage more contribution to our projects, and our discussions will be friendlier and reach conclusions more easily.

Footnote

  1. Honoring people’s preferences about gender identity includes not referring to them in ways that conflict with that identity. For instance, not to use pronouns for them that conflict with it. There are several ways to avoid that; one way is to use gender-neutral pronouns, since they don’t conflict with any possible gender identity. One choice is singular use of “they,” “them” and “their.” Another choice uses the gender-neutral singular pronouns, “person,” “per” and “pers,” which are used in Information for Maintainers of GNU Software . Other gender-neutral pronouns have also been used in English.