Poisonous People

Wednesday, April 14th, 02010 at 14:41 UTC

A while ago, some of the lead developers behind SVN did a talk at Google entitled How Open Source Projects Survive Poisonous People (And You Can Too). If you have the time I certainly recommend that you watch it. What follows are some of the notes from that session along with a few comments from my own experience. Having a sort of transcript online somewhere help others to copy and cite as needed.

Even if you don’t work on open source projects, you probably work with other people in your day job. Many of the points here are not targeting trolls or co-works and bosses that you hate. Poisonous people come from all different walks of life, those who want your project to fail, to n00bs, to people who just don’t understand the project or process. If these are not dealt with, they will poison the community to a point where it isn’t fun anymore and when it’s not fun, people start to leave or drag their feet. This kills the motivation and potentially the project.

Keep this in mind as you go through this document, that even though this is an open source and a computer programming example, it could just as easily be any team of diverse people working on a large scale project from architecting a municipal building project to a small team of people hosting a bake sale. Poisonous people can pop-up anywhere, and what’s worse is that they might not even know it.

Four stages for protecting your project

In their presentation, the SVN developers break it down into 4 major stages that you will need to go through when identifying poisonous people. Unfortunately, you could be in all 4 of these stages at the same time with different individuals. The process is never complete, nor comprehensive.

  1. Comprehension
  2. Fortifying
  3. Identify
  4. Disinfect

Comprehension

The most important aspect of any community project is the attention and focus. The main goal is to protect this over everything else. Once you realize that people are there because they want to be, you need to make sure the environment remains that way. For open source projects people are volunteering their valuable time and effort, this is no different than volunteering in meat-space on the weekends. You don’t have to be there, the minute it isn’t fun, you’re off. Your obligation to remain is next to none. Even in the work place, you normally are getting a paycheck so you keep coming to work, but there are times when the environment changes so much that it isn’t fun and people start looking elsewhere for jobs. Leaving your day job is even worse because you can at least bribe good people with money, perks or other incentives to stay.

In the video, they list several ways poisons people cause the community to loose attention and focus. Some are self-explanatory, some are computer jargon and need further explanation.

Painting a bike shed is a famous axiom in the world of community management. It goes back to a famous example of the construction of a nuclear reactor. There was a large team formed to select a site and plan the construction on a new nuclear reactor. The problem was that most people on the team were there to either satisfy some requirement, for their own personal gain or political pressure. Most people had no idea how to build a nuclear reactor. So they happily nodded at all the proposals, the 1,000 page dossier and blue prints for the construction site. No one had enough expertise to disagree or want to look foolish by asking silly questions about reactions, containment fields or heavy water—they were on this committee, they should know about this stuff! So toward the end of the project someone decides they want to leave their mark on the project and suggests that maybe some of the engineers will be biking to work, so we should build a small bike shed for them to lock-up and store their bikes. Everyone agrees that this is a good idea, but what colour should it be painted? Now a full-fledged argument ensues, it should be RED, no YELLOW, no GREY and so on and so on. None of these people had the expertise to comment on the important issues in dealing with the nuclear reactor, but they could offer their opinion about the colour of a bike shed, thereby contributing to the project. People want to stake their claim and show that they are “experts” and justify why they are in this committee, even if it is just to have selected the colour of the bike shed.

Now, the bike shed is an analogy for plenty of issues in your daily life. Rather than deal with the large questions of the company’s five year plan, people argue about the type of coffee in the lounge. This is a bike shed question, it doesn’t matter because it doesn’t change the goal of the project and is side-tracking the important discussions. This is Parkinson’s Law of Triviality, “The amount of discussion of a feature is inversely proportional to its complexity”. For very complex ideas, only a few people can legitimately contribute, therefore discussion is low. On ideas that are not complex, the colour of a bike shed for instance, the discussion is incredibly high.

If you get into a bike shed discussion, the best way to deal with it, is to identify it for what it is and move on. Only then will you actually get some work done.

Fortify the Project

There are four simple tenets to help improve your community that will help protect against poisonous people from appearing.

Some sites put this right into their mission statement. Phrases like “I promise to be nice” or “You know THAT guy, don’t be THAT guy”. It makes it easy when someone is acting out of line to go back to that short message they agreed to when they signed-up saying, “I promise to be nice”. I gentile reminder of that can go along way to diffusing a problem.

We also have to remember that email is faceless. Some of the vitriol people write in an email, they would never say to anyone’s face. We need to be respectful and polite when replying. Stooping to their level doesn’t help.

To help protect your project, it needs to have a well defined mission statement and direction. Knowing the end goal and the scope of the project will help prevent feature creep and people who want to push their own agendas.

As people come on board your project, as they will inevitably do, whether this is an open source project or project for your day-job, I’m sure someone, without intention of tripping the group up, will say, “I’m so glad to have joined this team, you are doing some great stuff, won’t it be great if we just added X, it would be so much cooler!”. They don’t realize they are poisoning the project by derailing it from the original focus.

Having a mission and solid direction allows the team to say, “Thanks for the input, we’ll add it to the backlog and if we have time at the end, we’ll address it then. Our goal is to complete Y, X isn’t part of the original spec, we’ll have to deal with it later”.

Remember, features can always be added after the 1.0 is launched, not before then.

Mailing List Etiquette

With open source projects, the volunteers are usually not geographically close, so mailing lists and IRC chats are ideal to keep everyone on the same page in understanding the state of the project. While mailing lists are an excellent resource and repository of knowledge, they are incredibly daunting for a newbie. Just think of yourself joining a project that has been working for two years, generating thousands of emails and someone tells you, “No, you need to go read the archives to learn why that’s a bad idea”. Wow, forget that, I’d be out of there in a flash. Having the mailing list archives are great, but you can’t expect the people who need to read them to actually do so, it’s not feasible.

When poisonous people come to your mailing list, you need to be gentile in dealing with them. These are a few tips to help keep issues in check.

Point them to specific parts of the archives, do not allow them to re-open discussions. It is disrespectful to the community to go back and question a team’s previous judgements. It wastes everyone time rehashing issues that have already been discussed and consensus already built-up and agreed apon. One person’s mission to bring back something that they might not have liked goes counter to a community’s decision.

Prevent them from respond to every message, sometimes called filibustering. This makes them seem like they have more weight than they actually do. Submitting 10-15 email messages means they have a higher proportion of messages in the system, and therefore they must be important, which isn’t the case. Multiple messages derail consensus, it creates unwarranted noise from a single source. Rather than have multiple emails within the same thread of discussion, have them write a single well thought-out response rather than several individual posts. There is no need to respond to each person’s previous messages with their own message.

Some mailing lists have subject line standards. This allows people to quickly see what is being discussed without having to read the whole message before getting to the point. For instance, some companies add the client name in the subject, or if it is a meeting request, put the date-time in the subject.

Top posting is another pedantic hot topic on mailing list. Top posting is when you put your entire reply at the top of the email message rather than inline with the conversation. Some organization abhor top posting. Actions such as this and subject line standards just need to be put into a document somewhere for the entire team to reference. Without this you can’t really blame folks for making these mistakes, especially when their email clients are designed that way.

Create documentation

No one likes to create documentation, it isn’t fun, it’s tedious and some design methodologies such as Scrum advise against it. There are certainly pros and cons to why having as little documentation as possible is a good idea. Don’t spend your time on something that will be wrong in 2 weeks time. That said, there are several piece of documentation that are essential to the well-being of a community.

You need a mission statement. This is a document which outlines the project. If someone new joins and wants to do something beyond what is in the mission statements, then they have too choices, go somewhere else, or help build what the mission statement put forward, then when it is finished, it can be amended to possibly accommodate changes

Other useful pieces of documentation are the design documents. How to deal with big fixes, an issue tracker, some sort of code version control system. It is also important to document your mistakes and decisions so people can refer back to them if the discussion flares-up again.

As your community grows, there will probably be other ways you document your process, beit on a wiki, mailing list, or website, you’ll find what works best for you. Just keep in mind that you need some solid text to point poisonous people too, to help them understand why they are draining the energy of the group. Without documentation, then you can’t relieve yourself of their questions, because you can’t blame them since there is no where else they could learn this information.

Power Plants

Collaboration is an important part of every project. The whole team needs to know what is going on, who’s doing what and where things are headed. This is the point of stand-ups in Scrum. On a daily basis you are telling the team what you have done and what you are working on. That way there is a feel of progress and ownership. In some open source projects, and probably work related projects too, some folks just take their piece of work and disappear, only to re-emerge several months later with a “finished” version. These are sometimes called “power plants” and they are detrimental to the community. It’s really one person’s way of showing that they are important. They go away do something without telling the team and re-appear, basically saying, “Look how good I am, I went and did something no one else could. Now you must take it”. That isn’t healthy for team moral. When one of these massive changes flops down into your project, everyone needs to take some time from what they were doing and review the changes. Is this power plant more than what was asked for, does it actually solve the problem at hand, do we need to review this code, and allsorts of other questions. Had this been developed and integrated on a daily basis, there wouldn’t be this scare and need to check everything. The original author might be assuming they are helping the community, but actually they are poisoning it.

Bus Factor

I’m not sure why computer scientists are more prone to getting hit by buses than any other profession, but somehow it has stuck in our vernacular. The “Bus Factor” is the number of developers, or members of the team, that would need to disappear to cause your project to stall. If there is only one person who knows how to rebuild the fluxcapacitor, then you have a Bus Factor of 1. If that 1 person gets hit by a bus, the project dies too. Therefore, you want the highest possible bus factor number. Every member of your team can step in as needed. This might seem silly, and somehow “Bus Factor” is, but it’s a fact or life, people have spouses and children that get sick, sometimes for days in a row. Their life is not your project, so you can’t always expect them to be there or to put you as the highest priority. In the world of open source, if someone leaves it might just take a bit longer to complete the project or find someone who can replace them, but what if you are in a submarine or in outer space. You certainly don’t want to have a “Bus Factor” of 1!

To increase your “Bus Factor” you can undertake several different approaches.

Ask others to help on under-developed parts of a project. This spread their expertise into new areas. One way to accomplish this is to comment on existing code. It’s OK to be an expert, but you can’t let people mark-up their territories. When they stake a claim, they are actually limiting the number of people who can help. By having others go through parts of a project that others have worked on, it spreads the knowledge and makes it better. Given enough eyeballs, all bugs are shallow.

To help prevent people from staking a claim and discouraging other people from editing the code, do NOT let people put their name on it! The project as a whole was developed by the team, it isn’t Brian’s part over there, and someone else’s part of here. We as a team should take responsibility for the whole thing.

In open source projects, there are several other ways to determine authorship, namely change logs. Everyone who commits something to the project has their name in the commit logs. By making all the names public, it gives everyone credit for their work.

Putting names in a file makes people nervous. If this part of the project is anonymous, then everyone owns it, no one feels nervous about changing it.

Do not let people blackmail the project: “I wrote it, I want my name on it or else…”. Remember that the community always trumps any individual ego! Keeping the community health is better than any single bug fix. Any problem or bug will get fixed over time, maybe not as fast as if you accepted their submission, but it is more important to keep the community together in the long-term than any short-term code fix.

Voting as a Last Resort

In the video they talk briefly about voting. Their conclusion is that voting is a bad thing, if you are voting on everything, then you are doing something wrong. There are several reasons why voting is a bad idea in a community situation. Firstly, voting means there is a winner and a loser. No one likes to be on the losing side. Over time, if your ideas are constantly voted down, then you might just take your toys and go somewhere else. One of the main goals is to keep the community together and by voting you are creating an “us vs. them” situation. A better way to handle problems is via compromise. Rather than presenting both sides and taking a vote, a healthy community can engage in a discussion about the issue and either come to a compromise or review the original goal and mission to see if the issue is even valid.

Having a direct democracy in voting also causes other problems. Does everyone’s vote count as equal? What about that contributor who pushed one minor change versus the lead developer? Certainly they have very different perspectives on the issues and know the ins and outs of the situation. Yet, with enough newbies, they could force a project in unexpected ways due to sheer numbers. Just look at Switzerland, it is great that everyone has a voice in the community, but at the same time if you rattle their cage over some issues, they don’t always vote with the long-term goals in mind, but rather their own short-term needs.

Ultimately, a compromise on the issue is the best way forward. Each party discusses the issues and then everyone feels that they are part of the solution rather than simply a number in a vote on the winning or losing team’s ballot.

Take aways

In order to successfully deal with poisonous people you need to have a well-defined process for your community actions.

You need to be welcoming to new members. This might mean that one person is the ambassador to all new members. They are shown the mailing list, the archives, other important documentation, etc. The only way your community will grow is with new members and new ideas, therefore you need someone there to invite these people into the fold. Having a single person, or team of people, doing this will free-up others to actually get their work done.

Along those same lines, you might need to assign a single person to manage the task list. Make sure no bugs, issues or patches fall through the cracks. A new person might volunteer their time and effort, but if no one says thanks or incorporates their work, you can bet they won’t stick around very long because they do not feel welcome.

A community is more than the people who started it. Even a founder can be booted. If they are not showing respect for your community, then they are poisonous to your project. Poison people can come from within.

Identify

Both on and offline, there are several tell-tale signs of poisonous people. Online, you tend to get people who’s identities don’t tend to match. In this day and age, we tend to have our usernames, email address, IM accounts, IRC names and other vanity accounts be similar. If people are joining with an email address like “CoolGuy76” and IM name of “WatermellonsAndHotDogs” a few red flags should be popping-up as warnings. Along with this, their emails and other correspondence tend to score high with your internal spam detector, things like UPPERCASE LETTERS and crazy punctuation?!????!!! The video recommends that you try to have a good cop, bad cop situation. Let one team member be the bad cop and worry about this person being poisonous to the project while you have at least one other person willing to play the roll of good cop and give them a chance. Potential poisonous people need a devil’s advocate. It could just be a language barrier, an age difference or they are a new newbie and just are lost in what the proper etique is.

Another tell-tale sign of a poisonous person is that they are openly hostel to the community, whether they realize it or not is another question. Insulting the status quo is a sure fire way to not win friends. Saying things like, “That’s not how I did it when I worked for X”. Well, this isn’t X, this is a team project with different needs and goals than when you were at X. People are very comfortable in what they are used too, they want this project to be exactly like their old ones. Any time there is a shake-up in a company or community, the ones who want to keep it the same are the ones who aren’t pulling their weight. They had a nice ride going and with these changes, someone is going to find out they can’t actually innovate and contribute in a new way. Having your own status quo allows you as a community to point new folks at previous community decisions, the mission statement and the goals. You need a solid documented reason that you are not building a product like you did at X, otherwise you are inviting people to poison the project into something they are comfortable with rather than what the community has decided.

Conversely, sometimes members blackmail the community. If you ever hear a statement like, “The project is great, I love it. What I need is for you to add feature X, otherwise I am not contributing Y.” or “If you build Y, then my company will adopt this, if you don’t then we’re going with the competitor”. These people are holding your community at random. They are demanding something be built for them, or else… No community should be driven by one person’s needs. Much like earlier, the health of the community is more important than one person’s bug fix. If feature X or Y is important, it will eventually be built, maybe not as soon as you or they wanted, but you need to think of the long-term over the short, and besides, who knows if the blackmail threats are true? You could spend a lot of development time building Y and they still go with the competition. Now you are behind schedule and without a contract!

Sometimes well meaning people just join at the wrong time and suck out your effort, poisoning the community. When you are on a big push finishing a release cycle or sprint or a major deadline and they just appear without picking-up on the current mood and atmosphere of the team. Everyone is focused, stressed and trying to make the deadlines and these new folks are sucking your time, asking questions they could be looking-up. Had they joined months earlier or a week later, this would not be such a problem, but they just came at the wrong time. This is difficult to deal with, because they are poisoning the team, but un-intentionally. As discussed earlier, you need one member of the team to be there and welcome new members. This is the best opportunity to help them understand the current mood so they don’t cause problems. You don’t want to turn these people away and you don’t want to ignore them, but you can’t waste your valuable time answering and rehashing old questions and issues with each new member.

Ignore Poisonous People

Other ways to identify Poisonous People:

They refuses to acknowledge the opinion of others. As we’ve said before, this is a community effort, just because the project isn’t exactly how they want it, they need to realize that as a community we came to a consensus. If they are unable to acknowledge others, then they are obviously not willing to build a consensus and work with a team. This can only end poorly.

They tend to make sweeping claims about projects future success if they don’t get their way. Statements such as, “This project was doomed from the start”. This doesn’t boost team moral. As a community you need to all have the same vision moving forward, anyone who is pessimistic can infect the entire team.

When someone re-opens long settled issues without reading archives, they are sucking down your attention. Time is effort that could be spent elsewhere, so it is important to not let them get the discussion started, for all the same reasons as why they need to acknowledge the opinions of others. The community made a decisions and one person shouldn’t derail a good thing just to get their way.

Poisonous people tend to complain but don’t offer any fixes. This is outright trollish behaviour, channels such as the mailing list are for discussions about development, it’s not one person’s group therapy session. If there is a real bug, then get them to move the issues to their proper places such as the issue tracker.

Having specially built tools to handle different aspects of the community should be used in their respective ways, otherwise you are wasting people’s time and on a large mailing list, that can be a lot of man hours even for a short email message.

Sometimes poisonous people are productive, but don’t act in a good way. For example, they go away and write loads of code, but they don’t participate in the discussion. Any complex design need communication, not someone who disappears for a few weeks and returns with a black-box. This is back to “power planting” which doesn’t end well either.

Ultimately, you don’t need to be desperate for developers or team members, it is OK to ignore some folks. Things might take longer, but the long-term health of the community is more important.

Remember, people are not naturally thick-skinned. Everyone on the team needs to divorce themselves from the discussion. Never take it personally, otherwise your emotions will get in the way and things fall apart and the community suffers.

Disinfect

Disinfecting the problem requires you to first assess where the damage is coming from, then you can begin to focus on cleaning-up the problem. Are the poisonous people draining your attention and focus and will this continue? Maybe it’s just temporary because they are new or your are trying to meet deadlines, but when those passes they will be excellent contributors.

At some point in time, you need to stop and ask yourself, are you wasting your time talking to these people? If they are sucking up so much of your time, the simple answer is not to waste your time on them. With email this can be really easy, just filter any message they send as “read” or “archived”.

Maybe these poisonous people are having a larger effect on the community. Sure they might bug you and you can fix the problem by ignoring them, but are they distracting the entire community? Is it losing momentum because of them?

One solution is not to feed the creature. When you respond, you give them more surface area to attack, which spirals into wasting more and more time. You need to stick to the facts, don’t get emotional. Which is very difficult, because email is so faceless it is easy to say things you never would in a face to face situation.

At this point these poisonous people are potentially turning into trolls. There are plenty of essays online about handling trolls, so I won’t dig too deeply into that here, except to say that you can repel trolls with kindness. Some trolls are looking for a fight, if you are civil and polite they have nothing to argue with.

If that doesn’t work, you need to know when it gets so awful that you need to boot them. Remember that the health of the community is paramount to any one person. No matter how much they contributed, you need to consider the long-term health of the community. This might mean doing some unpopular things such as booting members.

Even good people can appear to be trolls. They have well intentioned questions, but draining the community’s attention because they needed someone to hold their hand. The best solution for this is good documentation. It is a horrible thing to tell them to RTFM, but sometimes, if worded politely, it is the best answer for everyone.

You need to pay attention to new members. Sometimes they might look like a troll, but maybe it is a language barrier, they are new to mailing lists or communities, or they are very emotional. You need to extract the emotion out of their message look for the actual issue. This is why it is important to have an ambassador to new members.

If a newbie says: “Shame on you for letting this bug slip through, for writing this bad code, etc.” They have a valid bug in there somewhere. You need to remember to stay calm, politely direct them to the ticketing system, and try to resolve it. The worst thing you can do is engage them at their level and reply to their email lambasting them about, how dare they complain about the coding practices, etc. You need to rise above it and have some pretty thick skin when someone is complaining about the project you put so much effort into, but stooping to their level doesn’t help.

Summary

There are 4 main points to always keep in mind when building a successful community:

Sources

I can’t take credit for the idea of Poisonous People, this is merely an outline of their talk with some notes from me. I didn’t come-up with this concept, but try to keep it in mind as I am working with other groups and double-checking myself against this list too.

Categories: Community, You're doing it wrong

Tags: , , , , , , ,