Four social rules for a “No Asshole Zone”

Free Software needs a strong community. If we fail to attract everyone willing to work for Free Software, we’re shooting ourselves in the foot. Also, we’re probably not being as friendly and open towards people as we should be, morally speaking. That’s a serious failure for a community where morals matter.

The low share of women participating in the community (oh, where to start with the links? I’ll just pick this one by Jodi Biddle) is an especially egregious problem. I’m sorry to say that FSFE is doing no better in this regard than the overall community, much as we want to.

One easy step that we’ve already taken is to update our internship page to say that when choosing between two or more similarly qualified candidates, we’ll prefer female applicants. Yes I know, hardly revolutionary – but you have to start somewhere.

I just came across Sumana Harihareswara’s keynote at WikiCon 2014, titled “Hospitality, Jerks, and What I Learned“. The whole text is interesting, and I recommend you read it in full.

In one section, Sumana talks about constructing a “No Asshole Zone”, and specifically focuses on four social rules that help people to work in public – something that sometimes includes failing and showing ignorance.  The rules are:

No feigned surprise. No well-actuallys. No back-seat driving. And no sexism, racism, homophobia, and so on.

It’s important to realise that these rules aren’t specifically about being more welcoming towards women. They’re about being more welcoming towards everyone. They’re about making our work more productive and satisfying.

A more detailed explanation

Feigning surprise. When someone says “I don’t know what X is”, you don’t say “You don’t know what X is?!” or “I can’t believe you don’t know what X is!” Because that’s just a dominance display. That’s grandstanding. That makes the other person feel a little bit bad and makes them less likely to show you vulnerability in the future. It makes them more likely to go off and surround themselves in a protective shell of seeming knowledge before ever contacting you again.

Well-actuallys. That’s the pedantic corrections that don’t make a difference to the conversation that’s happening.  Sometimes it’s better to err on the side of clarity rather than precision. Well-actuallys are breaking that. You sometimes see, when people actually start trying to take this rule in, that in a conversation, if they have a correction, they struggle and think about it. Is it worth making? Is this actually important enough to break the flow of what other people are learning and getting out of this conversation. Kind of like I think we in Wikimedia world will say “This might be bikeshedding but -”. It’s a way of seeing that this rule actually has soaked in.

So far, so good. But what happens when someone fails to stick to these rules?

I think it’s also important to note, well, how do these rules get enforced? Well, all of us felt empowered to say to anyone else, quickly and a bit nonchalantly, “Hey, that was a well-actually,” or “That’s kind of feigned surprise, don’t you think?” And the other person said sorry, and moved on. I can’t tell you how freeing it felt that first week, to say “I don’t know” a million times. Because I had been trained not to display ignorance for fear of being told I didn’t belong.  [...]

If you don’t understand why something you did broke the rules, you don’t ask the person who corrected you. You ask a facilitator. You ask someone who’s paid to do that emotional labor, and you don’t bring everyone else’s work to a screeching halt. This might sound a little bit foreign to some of us right now. Being able to ask someone to stop doing the thing that’s harming everyone else’s work and knowing that it will actually stop and that there’s someone else who’s paid to do that emotional labor who will take care of any conversation that needs to happen.

Within FSFE, we put a lot of importance on keeping conversations polite and productive. We already rely quite a bit on FSFE’s staffers and other experienced list moderators to sort out conflicts. However, a lot of our rules are implicit. Sumana’s talk makes some of them explicit, and suggests some useful new approaches we should try.