I've seen some great presentations about empathy in communication recently, specifically mpj from Fun, Fun, Function and another from the Destroy All Software blog. They've inspired me to examine some of the specious arguments I've seen against communicating politely, civilly, or with empathy, talk about why they're flawed, and also talk about how research has shown that psychological safety within a team makes that team more efficient.
One thing that many open source communities have to handle is supporting whatever is built. One of the more common communication problems that happens when offering support is what is referred to as "The X/Y Problem". We're going to take a look at what this pattern entails and how to resolve it.
One common "defense" that people put forth when they receive a code of conduct warning is that the person issuing the warning is "not accepting constructive criticism gracefully" or "not being welcoming". However, the whole reason why we're having to enforce the code of conduct is because their criticism wasn't constructive. This article will break down why this defense is specious and give community managers a place to point to when people behaving badly try to use it to justify their destructive behavior.
Sometimes you already have a code of conduct in mind when you start building a community. Other times, you just want to get the community started and worry about the details later. Either way, you need to establish certain cultural norms: informal understandings that govern the behavior of members of your community. A code of conduct allows you to formalize certain things but there are always gaps that need to be filled in by less formal, more ad hoc practices. In this post, I'll discuss some of the things that have been successful for me in the communities that I've worked within.
I've been asked a number of times recently and many, many times over the years how I can tell when a comment or action has "crossed the line". Here I'm going to discuss some simple rules of thumb that I use to make that determination.
Up until now, I've been talking about "community" in mostly abstract terms. Since all communities are collections of people, they all have a large set of challenges in common. It is important to keep in mind that, as communities grow past a certain size, they tend to organize themselves in one of three distinct ways. I wanted to take the time to define the terms I use because I will probably refer back to these terms in future articles.
This time of year, with darkness coming so early in the day, is a natural time to stop, look back at what's come to pass over the year, and take what lessons we can from it. When I sat down to write this article, there was really only one subject that I felt best fit with this theme.
Many open-source communities now have codes of conduct to formalize their ideals and goals around inclusivity. However, human behavior and interactions don't always fall into neat little boxes of "definitely acceptable" and "absolutely out-of-bounds". There are lots of gray areas and room for interpretation. So, what happens when you have someone that doesn't obviously violate your project's code of conduct but is causing a constant problem and discouraging others from participating?
In this article, I'm going to talk about the negative patterns that I've seen people fall into when first participating in open source and some more productive approaches that should help everyone involved.
This is a series of articles dedicated to taking a look at various aspects of managing a community, typically involving an open-source project. We'll cover subjects like how to best organize a community, what to do about problem users, what methods work best to communicate with users and why, and many others from the strategic to the tactical ...