I think what ends up happening—and this isn’t exactly an original insight—is that the negativity eclipses the neutral and the positive. The negative interactions stick in my memories and make it difficult to remember all the good that has come from being a FOSS maintainer. Even sitting down and writing the list above helped me remember how much positivity there is in FOSS. It was almost cathartic.
I believe it takes something like six positive interactions to cancel out one negative interaction.
One of my frustrations is that not enough people take the time to explain how to interact better. Communicating over text is hard. Really hard. In person, feedback is immediate so if I say something awkwardly phrased then I can correct it immediately, especially when the other party acts negatively (which doesn’t even need to be verbalized, but can be subtle body language clues).
Over text, you just make an awkward comment and then there is no feedback at all and I can’t correct it. Effective communication over text is a learned skill.
This is why adding comments like “hey, this is how that comment came across to me” is so important, as it provides the kind of feedback you have in real-life but is absent in text-only communication.
I also don’t like the “code of conducts” that are basically just a lazily written bullet list rephrasing “don’t be an asshole” in several ways – something everyone already agreed on in the first place – and then provides an in-depth explanation on how to punish people. That’s just not helpful in getting people to improve their behaviour, and a massive distraction at actually improving the situation.
I also don’t like the “code of conducts” that are basically just a lazily written bullet list rephrasing “don’t be an asshole” in several ways – something everyone already agreed on in the first place – and then provides an in-depth explanation on how to punish people.
I have seen and experienced so much harassment coming from CoC-toting projects that participation in projects with CoCs has mostly become a red flag and an immediate “no thanks” for me.
A project will have to do something really interesting and important to override this stance (the only project that managed to do this recently was Rust, but only barely).
Every unwanted behaviour seen from far enough can be summed up as “being an asshole”. CoC need to spell out examples because we do not share a definition of what being an asshole is and giving most common problematic behaviours as explicit descriptions helps to draw a sketch of what is not wanted. Which of course does not mean that every CoC does it well.
The problem is that many don’t even seem to “spell out examples”, but rather just list a bunch of terms as unwanted behaviour which are very open to interpretation. The “Contributor covenant” - by far the most popular CoC – does this. What it notably doesn’t do is actually give people guidance on how to avoid negative interactions, explain how certain behaviours/phrasings might be perceived, how people can do better, how to constructively handle things when a conflict does arrive in such a way that everyone leaves the interaction on a positive note, etc.
It’s just a mostly useless list of things almost everyone already agrees on. It provides no guidance, no advice, or anything of real value at all. No one who has read it will be one iota better at participating. Making such a list is easy whereas giving the above guidance is hard, hence my comment calling it “lazy”.
Now, if your goal is communicate “do this, or else be banned” then okay, fair enough. But I don’t think that’s very helpful or useful for anyone involved.
What it notably doesn’t do is actually give people guidance on how to avoid negative interactions, explain how certain behaviours/phrasings might be perceived, how people can do better, how to constructively handle things when a conflict does arrive in such a way that everyone leaves the interaction on a positive note, etc.
I’m still collecting links on all of that both for continuous personal improvement and handing out to others trying to improve themselves. You or other readers can feel free to message me any that you have which you thought were really helpful. I’ll pass them along to others.
CoC need to spell out examples because we do not share a definition of what being an asshole is
That’s nice in theory, but in practice I think it’s actually harmful to spell out specifics too much. It leads to people rules lawyering instead of discussing things based on general principles. I don’t think we need to share a definition of what being an arsehole is. Our definitions are close enough, and if they really differ a lot then we should have our own separate communities with our own standards.
This is a pretty off-topic aside, but I see the same contrast in how Americans tend to think of important issues (as issues relating to the interpretation of an important document) vs how Britons tend to think of important issues. The ‘rights-based’ approach in America tends to lead people towards rules lawyering about the interpretation of particular passages of pretty ambigious text. It’s anecdotal, but I see a lot of appeals to the constitution in American discussions of what the law should be, but more appeals to ethics, morality, religion, rule of law and other general principles in British discussions of what the law should be.
The purpose of this admittedly off-topic point is that I think we’d be better off with codes of conduct that say ‘Don’t be a dick’ and then leave being a dick up to the decision of the people in charge on a case-by-case basis, rather than specifiying a set of rules that is only going to get rules-lawyered by the person that’s being an arsehole. Like, if the person is being an arsehole just tell them to stop and if they don’t, kick them out. ‘Oh but technically your rules don’t say anything about [arseholish behaviour type 1242]’ should be met with ‘yeah but you’re an arsehole, goodbye’ not a big debate around whether the rules are comprehensive enough.
In the real world we have laws because our communities are so big we can’t have consistentcy and fairness without them. In an 99.9% of open source projects simply giving 1-5 people the right to decide what is appropriate behaviour seems much more sensible. If you’re having so many issues you need to write down a set of rules for dealing with them, that’s a pretty big red flag!
I also don’t like the “code of conducts” that are basically just a lazily written bullet list rephrasing “don’t be an asshole” in several ways – something everyone already agreed on in the first place – and then provides an in-depth explanation on how to punish people.
I agree that this kind of CoC is not ideal. Have you seen examples of really effective CoCs? I would love to see examples of what has actually worked well before.
The places I’ve seen CoCs working the best were not software projects but conferences. I’ve seen many instances where CoC acted as a good mechanism to prevent and react to abusive people.
Don’t know if effective, but the coreboot CoC was a result of lots of debate to counter the fear/threat of a “weaponized CoC”. It’s based on a (by now rather old) version of the Citizen Code of Conduct, which was perceived to be less harsh than the Covenant, and we added to it to resolve further concerns:
“Remember that people might be sensitive to other things than you are.”
“Most of our community members are not native English speakers, thus misunderstandings can (and do) happen.
Assume that others are friendly and may have picked less-than-stellar wording by accident as long as you possibly can.”
“Using this code of conduct aggressively against other people in the community might also be harassment. Be considerate when enforcing the code of conduct and always try to listen to both sides before passing judgment.”
The first one is an appeal to remember that the project has global reach: what’s appropriate with the buddies you grew up with while you’re in your living-room may not be appropriate when broadcasted to the world (even if you’re, in fact, in your living-room). It may be received in a horribly unintended way.
The second one was added because some folks come across as rather harsh and inconsiderate, but their only flaw is a limited command of the English language. We don’t kick out folks for stuff like that!
The third one is the “don’t abuse the anti-abuse tool” clause. I don’t think we’d have achieved rough consensus on adopting the CoC without that one.
Generally speaking, I found it the most effective though to already handle minor transgressions in a friendly manner (pointing out that things veered off towards the edge - friendly tone, no sanctions, open to discussion) and point out the global reach issue. It’s a real issue, it doesn’t delve into the political fight of the day, and it allows people to adapt their behavior to community norms while in the community without feeling knocked down for being who they are.
I found a few when I searched last year which at least attempted it to some degree, but I’m not aware of any that I really like. I’ve written draft versions of my own CoC and companion rationale document, which I’d like to put out there with some fanfare in the future, but it’s not ready yet (it’s actually still in a rather rough state).
Feel free to contact me (email on profile) if you’d like to read and criticize drafts and/or collaborate in the pre-release. I won’t have much time in the coming weeks though as I’m focused on other things, but I’d very much like to pick this up in a few month’s time.
Damn, dude, you really put your heart into this one. Brave of you to write it up and share it with us. Powerful stuff, man. I really enjoyed reading it. I respect you even more now than I already did. This article is probably going to be popping in and out of my mind for a while.
Also, thanks for writing tools like xsv and ripgrep that help us do important jobs in a bit safer and faster way.
Nice article! I like the “low effort” framing and might use that. A lot of people probably don’t realize that their comments or suggestions are “low effort”, so it may deserve some explanation.
One thing that I think is underrated is asking an honest question of a maintainer – that’s NOT low effort. What the low effort comments seem to have in common is:
I have a preconception of “how things are done” and I’m just going to assume that everything works that way
In other words, generalizing a limited view of software to every project that exists.
I think people don’t ask honest questions because they’re afraid to be shot down, or maybe that they won’t understand the answer. But I think that is a better way to open the communication and most maintainers will appreciate it.
One thing that I think is underrated is asking an honest question of a maintainer – that’s NOT low effort.
Very much agree and I always love to receive questions asked in good faith. At least, that’s my ideal. My own personal problem is that sometimes the same questions are asked over and over—even if it’s in good faith—and it can just get tiring having to deal with those. That’s the asymmetry I was talking about. Certainly, I should try to answer those with the same patience and care that I answered it with first time. But it can be hard (again for me personally).
Yes I can see that the most popular projects will have that problem. What’s interesting to me is that that a lot of the norms around open source software have withered away and been de facto set by Github.
This sounds like an “eternal september” complaint and I suppose it is a little, but I also think the problem is on both sides. I grew up in the age of Usenet so I was used to “netiquette” as well – i.e. showing that you made a good faith effort to search before posting a question
And it was also an age where you were “expected” to maintain a FAQ. FAQs solved a real problem. There was a “contract” for interaction.
I remember encountering ESR’s doc a long time ago:
But how many people on Github have read those types of docs? ESR’s doc has exactly the information people need, but many people have probably never heard of it. Unfortunately, it starts out overly aggressive and kind of talks down to the reader.
So I think it would be nice to have an updated / condensed version of that. I think one problem is that I’m not feeling this enough now to be motivated to write such a doc. But anyone whose project becomes popular probably doesn’t have time to write such a doc! They’re busy fixing bugs, etc.
Actually the Github observation reminds me that I watched a talk by the creator of Elm about making better software for productive interactions. There’s some merit to that for sure. Like all social software, Github has certain “nudges” – it can’t be neutral. I largely like it, but lowering friction means that a lot of “low effort” comments appear.
Although I think the old-fashioned way of prominently link a FAQ and “correcting” people who behave badly may also work.
I also think negative interactions can come with “marketing”. Last time I looked, Elm breaks some norms with regard to compatibility without adequately documenting them. And it promises a lot of things. So to me it’s natural that users would get angry.
I didn’t follow the actix thing very closely, but I think part of it may come from trying to “beat benchmarks”, which is a form of marketing.
I try to stick to factual posts and acknowledge downsides for that reason. It also used to be norm of open source that you put BUGS in your docs, etc. That is, they assume that the user is knowledgeable, and didn’t market “down” to them. Although of course the explosion of open source use might mean this dynamic can no longer be the norm.
Yeah I think it would be great to have an short article showing some interactions / questions that are useful and those that are not. I took a peek at the ESR article again and it seems to have aged pretty poorly. The tone is way too aggressive, which starts things off on the wrong foot.
And the CoC are all about saying what’s not allowed rather than giving some good examples of what a normal interaction should be like.
Open source is probably different than any other interaction a person has in their life. You have never met the person and you’re looking for technical help or information. So it’s natural that it should need some guidance about how to do it productively.
I may attempt such an article but so far my experiences have been pretty good, and I have a big blog backlog I’m working through at the moment…
Great article, should be required reading before taking part in FOSS. Really understanding that there’s a human at the end of the chain is more valuable than any bullet point in a CoC, though I appreciate that one is shorter to read.
Very good article @burntsushi.
I believe it takes something like six positive interactions to cancel out one negative interaction.
One of my frustrations is that not enough people take the time to explain how to interact better. Communicating over text is hard. Really hard. In person, feedback is immediate so if I say something awkwardly phrased then I can correct it immediately, especially when the other party acts negatively (which doesn’t even need to be verbalized, but can be subtle body language clues).
Over text, you just make an awkward comment and then there is no feedback at all and I can’t correct it. Effective communication over text is a learned skill.
This is why adding comments like “hey, this is how that comment came across to me” is so important, as it provides the kind of feedback you have in real-life but is absent in text-only communication.
I also don’t like the “code of conducts” that are basically just a lazily written bullet list rephrasing “don’t be an asshole” in several ways – something everyone already agreed on in the first place – and then provides an in-depth explanation on how to punish people. That’s just not helpful in getting people to improve their behaviour, and a massive distraction at actually improving the situation.
I have seen and experienced so much harassment coming from CoC-toting projects that participation in projects with CoCs has mostly become a red flag and an immediate “no thanks” for me.
A project will have to do something really interesting and important to override this stance (the only project that managed to do this recently was Rust, but only barely).
Every unwanted behaviour seen from far enough can be summed up as “being an asshole”. CoC need to spell out examples because we do not share a definition of what being an asshole is and giving most common problematic behaviours as explicit descriptions helps to draw a sketch of what is not wanted. Which of course does not mean that every CoC does it well.
The problem is that many don’t even seem to “spell out examples”, but rather just list a bunch of terms as unwanted behaviour which are very open to interpretation. The “Contributor covenant” - by far the most popular CoC – does this. What it notably doesn’t do is actually give people guidance on how to avoid negative interactions, explain how certain behaviours/phrasings might be perceived, how people can do better, how to constructively handle things when a conflict does arrive in such a way that everyone leaves the interaction on a positive note, etc.
It’s just a mostly useless list of things almost everyone already agrees on. It provides no guidance, no advice, or anything of real value at all. No one who has read it will be one iota better at participating. Making such a list is easy whereas giving the above guidance is hard, hence my comment calling it “lazy”.
Now, if your goal is communicate “do this, or else be banned” then okay, fair enough. But I don’t think that’s very helpful or useful for anyone involved.
I’m still collecting links on all of that both for continuous personal improvement and handing out to others trying to improve themselves. You or other readers can feel free to message me any that you have which you thought were really helpful. I’ll pass them along to others.
That’s nice in theory, but in practice I think it’s actually harmful to spell out specifics too much. It leads to people rules lawyering instead of discussing things based on general principles. I don’t think we need to share a definition of what being an arsehole is. Our definitions are close enough, and if they really differ a lot then we should have our own separate communities with our own standards.
This is a pretty off-topic aside, but I see the same contrast in how Americans tend to think of important issues (as issues relating to the interpretation of an important document) vs how Britons tend to think of important issues. The ‘rights-based’ approach in America tends to lead people towards rules lawyering about the interpretation of particular passages of pretty ambigious text. It’s anecdotal, but I see a lot of appeals to the constitution in American discussions of what the law should be, but more appeals to ethics, morality, religion, rule of law and other general principles in British discussions of what the law should be.
The purpose of this admittedly off-topic point is that I think we’d be better off with codes of conduct that say ‘Don’t be a dick’ and then leave being a dick up to the decision of the people in charge on a case-by-case basis, rather than specifiying a set of rules that is only going to get rules-lawyered by the person that’s being an arsehole. Like, if the person is being an arsehole just tell them to stop and if they don’t, kick them out. ‘Oh but technically your rules don’t say anything about [arseholish behaviour type 1242]’ should be met with ‘yeah but you’re an arsehole, goodbye’ not a big debate around whether the rules are comprehensive enough.
In the real world we have laws because our communities are so big we can’t have consistentcy and fairness without them. In an 99.9% of open source projects simply giving 1-5 people the right to decide what is appropriate behaviour seems much more sensible. If you’re having so many issues you need to write down a set of rules for dealing with them, that’s a pretty big red flag!
I agree that this kind of CoC is not ideal. Have you seen examples of really effective CoCs? I would love to see examples of what has actually worked well before.
The places I’ve seen CoCs working the best were not software projects but conferences. I’ve seen many instances where CoC acted as a good mechanism to prevent and react to abusive people.
Interesting, in my opinion, take on the subject sircmpwn published recently: https://drewdevault.com/2020/01/17/Effective-project-governance.html
ZeroMQ proces by Hintjens: https://rfc.zeromq.org/spec:42/C4/
Basically extends sircmpwn’s one with maintainers and an explicit default-to-merge policy.
Don’t know if effective, but the coreboot CoC was a result of lots of debate to counter the fear/threat of a “weaponized CoC”. It’s based on a (by now rather old) version of the Citizen Code of Conduct, which was perceived to be less harsh than the Covenant, and we added to it to resolve further concerns:
The first one is an appeal to remember that the project has global reach: what’s appropriate with the buddies you grew up with while you’re in your living-room may not be appropriate when broadcasted to the world (even if you’re, in fact, in your living-room). It may be received in a horribly unintended way.
The second one was added because some folks come across as rather harsh and inconsiderate, but their only flaw is a limited command of the English language. We don’t kick out folks for stuff like that!
The third one is the “don’t abuse the anti-abuse tool” clause. I don’t think we’d have achieved rough consensus on adopting the CoC without that one.
Generally speaking, I found it the most effective though to already handle minor transgressions in a friendly manner (pointing out that things veered off towards the edge - friendly tone, no sanctions, open to discussion) and point out the global reach issue. It’s a real issue, it doesn’t delve into the political fight of the day, and it allows people to adapt their behavior to community norms while in the community without feeling knocked down for being who they are.
I found a few when I searched last year which at least attempted it to some degree, but I’m not aware of any that I really like. I’ve written draft versions of my own CoC and companion rationale document, which I’d like to put out there with some fanfare in the future, but it’s not ready yet (it’s actually still in a rather rough state).
Feel free to contact me (email on profile) if you’d like to read and criticize drafts and/or collaborate in the pre-release. I won’t have much time in the coming weeks though as I’m focused on other things, but I’d very much like to pick this up in a few month’s time.
@burntsushi
Damn, dude, you really put your heart into this one. Brave of you to write it up and share it with us. Powerful stuff, man. I really enjoyed reading it. I respect you even more now than I already did. This article is probably going to be popping in and out of my mind for a while.
Also, thanks for writing tools like xsv and ripgrep that help us do important jobs in a bit safer and faster way.
Thanks for the kind words @nickpsecurity. Appreciate it. :-)
Nice article! I like the “low effort” framing and might use that. A lot of people probably don’t realize that their comments or suggestions are “low effort”, so it may deserve some explanation.
One thing that I think is underrated is asking an honest question of a maintainer – that’s NOT low effort. What the low effort comments seem to have in common is:
I have a preconception of “how things are done” and I’m just going to assume that everything works that way
In other words, generalizing a limited view of software to every project that exists.
I think people don’t ask honest questions because they’re afraid to be shot down, or maybe that they won’t understand the answer. But I think that is a better way to open the communication and most maintainers will appreciate it.
Very much agree and I always love to receive questions asked in good faith. At least, that’s my ideal. My own personal problem is that sometimes the same questions are asked over and over—even if it’s in good faith—and it can just get tiring having to deal with those. That’s the asymmetry I was talking about. Certainly, I should try to answer those with the same patience and care that I answered it with first time. But it can be hard (again for me personally).
Yes I can see that the most popular projects will have that problem. What’s interesting to me is that that a lot of the norms around open source software have withered away and been de facto set by Github.
This sounds like an “eternal september” complaint and I suppose it is a little, but I also think the problem is on both sides. I grew up in the age of Usenet so I was used to “netiquette” as well – i.e. showing that you made a good faith effort to search before posting a question
And it was also an age where you were “expected” to maintain a FAQ. FAQs solved a real problem. There was a “contract” for interaction.
I remember encountering ESR’s doc a long time ago:
http://www.catb.org/~esr/faqs/smart-questions.html
and I remember reading this book 10+ years ago:
https://producingoss.com/en/index.html (man lots of this feels quaint now, in a large part because of Github)
But how many people on Github have read those types of docs? ESR’s doc has exactly the information people need, but many people have probably never heard of it. Unfortunately, it starts out overly aggressive and kind of talks down to the reader.
So I think it would be nice to have an updated / condensed version of that. I think one problem is that I’m not feeling this enough now to be motivated to write such a doc. But anyone whose project becomes popular probably doesn’t have time to write such a doc! They’re busy fixing bugs, etc.
Actually the Github observation reminds me that I watched a talk by the creator of Elm about making better software for productive interactions. There’s some merit to that for sure. Like all social software, Github has certain “nudges” – it can’t be neutral. I largely like it, but lowering friction means that a lot of “low effort” comments appear.
Although I think the old-fashioned way of prominently link a FAQ and “correcting” people who behave badly may also work.
I also think negative interactions can come with “marketing”. Last time I looked, Elm breaks some norms with regard to compatibility without adequately documenting them. And it promises a lot of things. So to me it’s natural that users would get angry.
I didn’t follow the actix thing very closely, but I think part of it may come from trying to “beat benchmarks”, which is a form of marketing.
I try to stick to factual posts and acknowledge downsides for that reason. It also used to be norm of open source that you put BUGS in your docs, etc. That is, they assume that the user is knowledgeable, and didn’t market “down” to them. Although of course the explosion of open source use might mean this dynamic can no longer be the norm.
“Asking questions” is a topic that’s been on my mind a lot recently and it seems to keep surfacing through all the culture related posts. For example: It’s fine to be elitist sometimes, or What’s I’ve learned over 10 years on StackOverflow. I’ve posted a comment about it on that last story and received interesting replies. Furthermore, I’ve attempted to hash out my ideas in the first paragraph of this article.
Yeah I think it would be great to have an short article showing some interactions / questions that are useful and those that are not. I took a peek at the ESR article again and it seems to have aged pretty poorly. The tone is way too aggressive, which starts things off on the wrong foot.
And the CoC are all about saying what’s not allowed rather than giving some good examples of what a normal interaction should be like.
Open source is probably different than any other interaction a person has in their life. You have never met the person and you’re looking for technical help or information. So it’s natural that it should need some guidance about how to do it productively.
I may attempt such an article but so far my experiences have been pretty good, and I have a big blog backlog I’m working through at the moment…
Great article, should be required reading before taking part in FOSS. Really understanding that there’s a human at the end of the chain is more valuable than any bullet point in a CoC, though I appreciate that one is shorter to read.