Protect the community/Notes

< Protect the community

Notes from the talk Protecting projects from poisonous people, Ben Collins-Sussman and Brian Fitzpatrick (Subversion), delivered 2006-10-14 at the Google Summer of Code Summit, Google HQ, Mountain View, Ca.

On how to maintain a community's focus and standards, and identify people who are damaging the community.

Contents 1 Understand the threat 2 Fortify against the threat 3 Identify poisonous people 4 Deal with infection

1 Understand the threat

Preserve attention and focus. Focus of the developers and community is the key resource. It is the attention and focus of the community that is the most important resource. The code is secondary.

Poisonous people distract from this attention. For example, obsessive perfectionists can derail forward momentum, and won't let design decisions be resolved. (Solution is to ignore the 5% minority, and just write the code anyway).

Build a strong community, based on: politeness, respect, trust, humility.

Other points:

• Don't be mean to potential committers. Trust+respect, attracts better developers.
• Don't rehash old discussions, point to archives
• Document your project's history! Don't have an "oral history".
  • Have a hacking document (for starting Haskell projects?)

2 Fortify against the threat

• By building and encouraging a healthy community
• Separate lists of users and developers (and irc channels).
• Politeness
  • don't just send urls, send urls with a blurb
  • ask people to be nice.
  • monitor the temperature, and point out rudeness
• Encourage email code reviews.
• Quality control: set standards, and point out publically when they're not followed.
• Big changes should occur in branches
• Avoid talking about bike sheds (http://bikeshed.com/)
  • don't get distracted by small details in small problems!
  • draws discussion away from core developers
  • (the 'Data.List.split' function...)

• Be wary of "power plant" developers progress, who go off and work on large changes on their own, without engaging the community.
  • people who write huge pieces, that can't be reviewed, can't be integrated
  • The result will not designed by the community, and may not be accepted
  • Risk of "bus error" syndrome -- only 1 person understands the code
  • So merge early, merge often
  • And have them work publically
  • It's just not reasonable to accept huge chunks of code

• Don't accept code without tests
  • Don't just pull in features, things will get more and more unstable (lesson from Zope)

• Noisy minority:
  • don't reply to every message in a thread, summarise.
  • people who won't accept, might end up replying to everything, creating a larger impression of discontent.

• Increase the "bus factor", that is, the number of developers that understand the code.

• Idea (from subversion), don't allow names in packages - creates ownership and slows developement ).

• Have well defined coding/release processes, Stable branches, testing, backporting bugs

• Have a policy for reviewing patches, so they don't fall through the cracks. SVN has a designated guy who moves patches into the issue tracker, if they're not addressed within 2 weeks.

• Culture becomes self selecting. Founders establish and perpetuate culture.

• Point out when people are doing the wrong thing. Ask them nicely to do the right thing. Then act if they're not following.

• Note that people can also be off track, but not doing harm

• Voting is a last resort. Healthy communities don't need to vote on things- there should be consensus.

3 Identify poisonous people

Easy:

• Uses silly nick names
• Uses multiple nick names on irc/code/...
• overuses capital letters ;)

More subtle:

• Unable to pick up on the "mood" of the community (i.e. a release is imminent, but they go ahead with a big commit).
• Doesn't understand the common goals of the community
• Asks RTFM questions

Conceit

• won't engage/argue with other positions
• makes sweeping claims. empty statements about a project's success
• reopens topics from years ago

Cooperation:

• complains, but won't submit patches
• unwilling to discuss design
• won't accept criticism

Hostility:

• insults the status quo
• angrily demands help
• trolling
• makes accusations of a conspiracy (scary troll)

4 Deal with infection

• Maintain calm and stand your ground.

• Questions to ask yourself:
  • are they damaging attention and focus
  • is the person going to benefit the community
  • are they paralysing the project? (as perfectionists may do).

• Do not
  • Feed them your energy/waste your time
  • Don't engage them
  • Don't get emotional
  • Don't respond, it gives them purchase (Silent treatment is very effective)

• Do pay careful attention to new comers
  • even if they're annoying at first
  • look for the fact under the emotion
  • be careful about cultural differences
  • extract a real bug report, if possible. ignore emotion. keeps temperature down.

• Know when to give up and ignore them

• Know when to boot them (using statistical evidence)
  • Perhaps even very enthusiastic people, but not submitting patches and distracting the community
  • had to ask such a person to leave, as they're distracting focus
  • balance between public humiliation/contacting privately
  • not everything needs to be done in public, particularly things that cause embarrasment.

• Stay vigilent, keep the community strong. So that you don't start leaking developers.

Recent content is available under a simple permissive license.