Encouraging empathy

12:03 pm community, freesoftware, General

A couple of days ago, I tweeted this: “Insight of the day: All “community norms” documents come down to one word: Empathy. Think how others will feel before you act.” I think that’s worth developing on.

This is what empathy meant to me growing up

As I was growing up, empathy meant "Deanna Troi" to me

Here are a few examples:

  • GNOME Code of Conduct: “If someone asks for help it is because they need it. Do politely suggest specific documentation or more appropriate venues where appropriate, but avoid aggressive or vague responses such as “RTFM”.” – think how it feels to need help, and to take the step of asking for it. I want to know that someone *understands* what I’m going through, feels my frustration, and is looking for a way to help relieve it. Recently, when confronted with a technical issue that prevented me from using my scanner, the advice I received on an IRC channel was to upgrade or change my Linux distribution! How un-empathic can you get!
  • Koha patch rules (along with every other development project in the world): “The patch must apply to the current HEAD of the master branch of the code”: Put yourself in the place of a project maintainer who receives a patch proposal. He tries to apply it to his source tree, but the merge fails. Why? Because the patch was created against a year-old release of the project, and he’s since reworked internals to solve a different, unrelated issue. The maintainer is faced with a number of unsavory choices now: Spend time reading the patch, understanding what it does, and “forward-porting” it to master; check out the old branch, apply the patch, review, and test it there, and not commit to master; or drop the patch. What would you do in that situation? Someone is giving you a gift, which is going to make work for you. Is it worth an hour or two of your time to work on it to get it to just apply to your work? You still need to review the patch after that – which you would have to do anyway. In that situation, most people will ask the original patch proposer to do the initial grunt work and get the patch working on the tip of master.
  • Now flip things around. You found a bug in software you use – the bug was really annoying. You took the time to get the source code, identify, qualify and fix the buig, open a bug report, which was confirmed, and attach a patch which you have checked fixes the problem. And what answer do you get? “Not good enough – work on it more”. How would that make you feel? That depends on how it is communicated. If it’s a stock answer, like a sheet of paper handed over a tax office counter, with a list of prerequisites, then I bet that would make me angry, resentful and frustrated. I poured time and effort into that patch, and this is how you treat it? If the criticism is of the core of the patch – it doesn’t fix the problem, or should do so differently, then the criticism might be easier to take. But if it’s issues which potentially add many hours of effort on top of time already spent, with no benefit to the proposer (check out the latest code, upgrade half a dozen dependencies without breaking my old version, compile it, and then forward-port the patch), chances are he won’t do it. An empathic response might be to make someone aware of the guidelines and their reason for being, but help him with the forward-porting on IRC by asking him to explain the patch, what it does and why.

All of those guidelines on indentation and whitespace, commenting code, including test cases, updating documentation, and ensuring code compiles at the tip of the master branch are designed to help patch proposers make patches which are easy for maintainers to apply. And in this context, an empathic patch proposer can understand them much better. Miguel de Icaza did a great job of framing this right.

When I was in college, I went to the Netherlands one Summer for a working holiday. At one point, I had a job offer for short-term work, but needed to be registered for tax to start, and I needed a bank account to get paid. So I went to the tax office, and the lady behind the counter very resignedly handed me a piece of paper with prerequisites, and told me to come back when I had fulfilled them. Then she looked over my shoulder and said “Next!” One of the prerequisites was a permanent address – I explained that I was living in a camp-site for the summer, and would that address do? Of course not! No proposed solution, no consideration of the situation I was in, no empathy.

Then I went to the bank, where I was told that I needed a permanent address to open an account. Same sense that the person I was dealing with didn’t care about me. So with my friend Barry, we looked into short term accommodation options. Landlords required (among other things) an employment agreement and a bank account before they would rent us accommodation – even if only by the week! In the end, we had to pass up that job, and work “on the black” for less than minimum wage to survive the Summer – but what choice did we have?

How frustrating! Just imagine how we felt. That’s empathy.

Again and again in community guidelines, whether it’s guidelines for people who are approaching a community to report a bug or propose a patch or feature, or guidelines for community members dealing with each other and people outside the community, this idea “think how this would make you feel if the roles were reversed” is pervasive, but unwritten. I think that it should be.

It reminds me of a social experiment I heard about recently:

Rats are placed in a box with a lever. When you pull the lever, a food pellet is distributed. The rats quickly learn to pull the lever. After a while, you change the configuration of the cage. Now, when the lever is pulled, the food pellet is distributed, but a cold shower drenches all the rats in the box. After a while, the rats learn not to pull the level, and start to punish rats who do as a group.

The second generation starts when a new rat is introduced into the box. as he approaches the leverl, the older rats all jump on top of him, to prevent him from touching it. In effect, they are teaching him the rule “don’t touch the lever”, without explaining why the rule exists. As time goes on, new rats are added, and old rats removed from the box.

The third generation happens when there are none of the oiriginal rats left in the box. None of the rats have experienced the cold shower after the lever was pressed. At that point, you can turn off the cold shower function – you will be sure that no rat will ever touch the level, because the community rules forbid it. Ask any of the rats why, though, and they will not be able to give you a better answer than “because that’s the way it is”. If rats could talk, of course.

Community guidelines which are purely written documents, but which neglect the empathic side of the equation, and don’t explain how not following the guidelines affect other people, can be similar. It’s important to include the reasons for guidelines,so that we don’t forget how breaking the rules makes others feel. It’s also important to have sufficient flexibility and adaptability in dealing with new community members – like the rat experiment, circumstances change all the time. Back when everyone was using CVS, performing merges was a complicated and time-consuming process. Nowadays, rebasing and merging with Git, Bazaar or Mercurial is so easy that some of the coding guidelines we used to have may no longer have the same impact. Likewise, email technology has moved on, and with cheap and copious bandwidth, email norms have evolved – netiquette community norms move on with them.

In general, as Bill & Ted famously said, “Be excellent to each other”. Think about how your actions & statements will be received. Be empathic.

9 Responses

  1. Tomeu Vizoso Says:

    Worries me those big software projects that grow so big and put so much emphasis on *their* community, that they lose the capacity of understanding the points of view of the other communities they have to work with.

  2. Donnie Berkholz Says:

    Nice post in general but I have one problem with it. You don’t want to upgrade your distro but you want all patches you get to apply against HEAD? Do you see the Jekyll/Hyde thing going on here?

  3. Anonymous Says:

    Quite frequently, you can just fill in your current non-permanent address in a “permanent address” field, and people won’t bat an eye unless it blatantly says “PO Box” or equivalent.

  4. Stuart Says:

    I greatly support the maintenance of clear and articulate codes of conduct, containing precise and unambiguous definitions of misconduct.

    People damage communities through thoughtlessness, in which case the documents provide reference, and through lack of respect (or lack of empathy) for others. In the latter case, no amount of happy-clappy empathy training will help those people understand the issue. The precise and unambiguous definition of misconduct is our defence.

    Imagine the failure that would follow a presentation of the notion of empathy to the workplace bully.

  5. Dave Neary Says:

    Donnie: suggesting upgrading an entire distribution because of a scanner configuration issue is, I think you’ll agree, not the most empathic response. I think you’ll also agree that different audiences have different needs, and it is not uncommon for neither party to be happy with an interaction (and the example of a developer expecting a path to be taken as-is, while a maintainer expects patches to the tip of master is one such example).

    Dave.

  6. Donnie Berkholz Says:

    Dave,
    One might presume the developer has a good reason for this request, such as dozens or hundreds of past support issues that were solved by a distribution upgrade without debugging exactly where the problem was. As you know, in general upstream developers are a time-limited resource. To operate effectively, they must distribute effort as widely as possible.

    I agree with you in a sense that the onus is on upstream to communicate exactly why they’re asking for extra effort so everyone understands the reasoning even if they don’t agree.

  7. Dave Neary Says:

    In this particular case, the standard “utility bill and/or lease agreement” was required.

  8. Dave Neary Says:

    Donnie:

    In this particular case, this was after a conversation where the person I was speaking to appeared to be an enthusiastic user rather than a core developer – the difficulty of IRC, of course, is that it’s very hard to attach a reputation to a nick if you aren’t familiar with who does what in the community. and again, in this particular case, I solved the issue (which was an issue of permissions on a usb node created with devfs) without upgrading my distribution – in fact, upgrading my distribution later rebroke the scanner.

    I have also had the same advice from someone when I wanted to get GNOME Shell working on Ubuntu 11.10 – “why are you doing something so stupid? Just install Fedora” – which is, to put it politely, not the kind of advice most people will be happy following.

    Dave.

  9. Tamara Says:

    A great post! A lot of people seem to underestimate the importance of empathy, but it really is the lack of it that turns back new contributors. Many of the experienced people in the community had forgotten how hard is to start at something and with the amount of info you are usually getting at any beginning you may overlook simplest things, and get into a loop – or end up clueless. A lot of people can be rude, or just plain indiferrent to the help you are pleading and that puts you very off from the task you wanted to do. Rtfm, yes I agree, but when you can help, why don’t you?