- 1. Comprehension:
understand which kind of people you’re dealing with. Preserve attention and focus.
- 2. Fortification:
how to fight against it or how to protect yourself against it. Build a healthy community.
- 3. Identification:
how to identify poisonous people. Look for tell-tale signs.
- 4. Disinfection:
how to disinfect your community from the poisonous person. Maintain calm and stand your ground.
In an open source project, you’ve got two main
resources: attention and focus. These resources are the scarcest.
You must protect them. To understand the annoying feeling given by poisonous
people, imagine that you have a group of people and pile of money in a table
and someone comes in the room and start taking money out of that pile. That’s
what the founder of an open source project feels with poisonous people. They
take attention and focus from the group, and that’s a huge loss
1. Comprehending the threat.
Poisonous people can:
- Distract. They keep distracting you,
- Emotionally drain your community.
- Cause needless infighting.
You need to avoid paralysis. OCD
(Obsessive-compulsive disorder) people can derail forward progress:
They keep full focusing on their part of the project to make it better
even if it’s not needed anymore.
- People obsessed with process.
They always want to have a process to work, the need you to give
Even nice guys can be poisonous unintentionally.
Sometimes they don’t even realize that they’re starting to be like that.
You need to disengage yourself in order to keep
moving forward, not getting stuck in an endless discussion just to try to prove
your point. A nice form to do this is by telling them something like “We’re
going to try this and see if it works”.
2. Fortifying against the threat.
The first thing to do is build a strong community
based on four things:
- Politeness. They have to be kind with
- Respect. Respect each other to keep growing
as a healthy community.
- Trust. Reliability with the team is
important to make everyone feel welcome.
- Humility. Conceited people are really
Document your project’s history. If you don’t
document your project’s history, you’ll need to repeat it over and over again
to every user who asks. Document things like:
- Mistakes: this is the most important
thing you need to document. If you document mistakes, you won’t need to
repeat it to every person who comes out with a “new” idea that you’ve
tried before and didn’t work. You’ll show people that you’ve actually
thought about it and they won’t try to do it again.
Have healthy code collaboration policies:
- Send commit emails, encourage email
- Do big changes on branches for easier
generous with branches.
- Increase your project’s “bus-factor”
on components: you need to let people participate in a part of the project
together. Try to make groups of work, because sometimes there’s an
important part of your project being made by just one person and suddenly
that person disappear (that’s why they call it “bus-factor”,
because it seems that he was hit by a bus and died), the code is there and
no one knows anything about it or about its logic.
- Don’t allow names in files.
Have well-defined processes:
- Releasing software. You need a release
process documented for your software.
and reviewing patches.
- The community
founders establish the culture: if you start your project being a nice
team full of nice, well-going people, you will attract more of that
people. But if you start angry and screaming, then you will attract more
angry screaming people. Plan what kind of community you would want to
culture becomes self-selecting
Voting is a last resort: a healthy community should
rarely need to vote.
3. Identifying poisonous people
- Uses silly nicknames. Such as “Superhacker666”
- Uses multiple nicknames in different
media. For example, in Yammer his nick is “Pancho Pantera” and in Skype
his nick is “Mr. Hacker”.
- Uses excessive punctuation, like “Hello
- Exaggerated talking people, with
expressions like “ZOMGWTFBBQ!?!?!”.
- Unable to pick up on the “mood”
- Doesn’t understand common goals of the
incessant RTFM questions.
the status quo.
- Angrily demands help. This person is
always asking for help and gets angry if he/she doesn’t get it quickly.
- Attempts to deliberately rile people. Better known as trolls.
- Makes accusations of conspiracy
- Refuses to acknowledge the opinions of
others. They presume their ten degrees and important titles refusing to
accept external opinions.
- Makes sweeping claims. Usually about the
project’s future success
- Re-opens topics that long settled
without reading the articles.
- Willing to complain,
but not help fix anything.
- Unwilling to discuss design.
- Too insecure to take
- You are not your code.
It’s not about you, it’s about the code and how to make it better. If you
never receive any feedback you never get better.