OSM is mostly a consensus-based community, or a do-ocracy. It was never a 
benevolent dictatorship, and I have given up (as far as I know, anyway) all 
power I have in OSM. I used to write the code, own the domain names, run the 
mailing list(s), run the servers, evangelize, talk to the press and so on. I've 
successively and successfully given up those rights to very capable 
individuals. However this has led to a power vacuum when it comes to making 
some key decisions because nobody, for example and in a sense, is "in charge" 
of everything. For the most part I've enjoyed giving up control and seeing the 
project blossom, because it wouldn't have if I hadn't.

However, things break down in a consensus-based community if you don't have a 
way to deal with malcontents.

As background to the topic of this post, there is a nice video on how open 
source projects can survive poisonous people on youtube here:

        http://www.youtube.com/watch?v=ZSFDm3UYkeE

It's about an hour long so I've provided a summary I made while watching it 
again at the bottom of this post. It's thesis is that you need to understand 
the problem of poisonous people, fortify your project against them, identify 
who they are and ultimately remove them.

The talk above identifies people who are poisonous as those who appear with 
traits (amongst others) of obviousness that they will suck and drain your time, 
use silly nicknames/email addresses, are hostile, make demands and blackmail 
threats, make sweeping claims, refuse to acknowledge reasoned argument, make 
accusations of conspiracy and reopen topics continuously.

One quote from the talk in particular comes to mind: "it's a technique that 
poisonous people can use to derail a consensus-based community from actually 
achieving consensus. You have this noisy minority make a lot of noise and 
people look and say 'oh wow there is no agreement on this' and if you look 
carefull the 'no agreement' comes from one person while seven or eight people 
actually agree"

With that in mind, take a quick look at the recent discussions on the main 
mailing list link. I won't point to an individual thread or post, it's easy 
enough to figure out:

        http://lists.openstreetmap.org/pipermail/talk/2010-August/thread.html

Without discussing the individuals or the topics of the conversations, it is 
clear to me we are infected by poisonous people. This is bad because as the 
talk above specifies in the 'comprehension of the problem' section, such people 
distract, drain, paralyze, slow cause needless infighting and destroy the 
attention and focus of a community.

I know this first hand. Many (if not most or all) of the key people in OSM are 
feeling drained, distracted and upset. Some are talking of hiatus or resign. 
These are the key people who write code, build things, maintain things and run 
our working groups.

There is a tipping point between which our working groups and individuals have 
the time and patience to deal with poisonous people and the work they cherish 
doing, which are the things that make OSM work every day.

The discussions have spilled over now from poisonous people merely making life 
difficult on the mailing list, to paralyzing the project and even 
systematically corrupting the data we serve out using bots. This is not to say 
there are not good points in the discussion, good points being dealt with by 
the License Working Group or others either in meetings or on the mailing lists, 
but these are being buried by poisonous people on the mailing list and 
elsewhere. Personal communication from multiple people, public discussion, 
phone calls and more have been tried without effect.

This destroys consensus-baesd community.

So we are at a point now in OSM, I believe, where a few poisonous people are 
wrecking the time, focus and goodwill of the majority of contributors, creating 
dissent out of nothing and even purposefully breaking our data. And we don't 
have a clear process to deal with all the factors. The Data Working Group is 
one piece of the puzzle, but is not responsible for curtailing the mailing list 
going in infinite circles.

Worse - it's giving the project a bad air to outsiders, both newbies and those 
outside the project. It's stopping people from becoming more involved.

Thus we need some kind of process for calling timeout on people in the project, 
blocking them for a limited time. This could range from electing individual 
mailing list admins with a remit of when to shut down discussions (much like an 
IRC chat admin(s)), to more clear and actioned policies on list etiquette (like 
forcibly keeping legal discussion to the legal list), to an ejection committee 
to me just appointing myself benevolent dictator and blocking people for a 
limited time out cooling off period based on advice from the community (a worst 
case option I'd like to avoid).

Let's be clear - we've tried all the nice things. We've sent nice emails. We've 
sent nice emails privately. We've offered phone calls. We've offered every 
rational debate and community consensus tool we have. We just have poisonous 
people that either need to cool off or be forcibly blocked for a time.

We need to restore the balance of healthy debate over important issues, restore 
the time and focus of existing contributors and restore the positive view 
outsiders and newbies of the project are used to.

I'm posting this to three places on purpose with different audiences: 
opengeodata, osmf-talk@ and t...@. I will undoubtedly be flamed here for being 
authoritarian but at the end of the day someone has to do it, and begin this 
process. I've purposefully left out individual names, details and links to keep 
this discussion to the key thing - how and why should we block people. If you 
want those details, just reply to this post and someone will probably tell you 
publicly or privately.

What are your ideas? How should we block people? For how long? What process 
should it be? What are the best practices from other projects you're involved 
in?



Summary of the poisonous people talk:

comprehension - understand the problem of poisonous people
  - you need to protect the attention focus of community - limited amount of 
time
  - poisonous people
    - distract
    - emotionally drain
    - cause needless infighting
    - slow you down
    - either on purpose on by accident

fortification - protect project from poisonous people
  - in a project you need politeness, respect, humility, trust
  - have a mission, with examples
  - have a scope, limit the mission
  - do not let people reopen old discussions
  - don't reply to _every_ message in a thread, summarise
    - poisnous people derail discussion:
      "it's a technique that poisonous people can use to derail a 
consensus-based
      community from actually achieving consensus. You have this noisy minority
      make a lot of noise and people look and say 'oh wow there is no agreement
      on this' and if you look carefull the 'no agreement' comes from one person
      while seven or eight people actually agree"
  - document your projects history for future use to point people to
  - have code collaboration guidelines
    - email review, reasonably sized patches
  - increase the bus factor so if someone drops out, others can take over
  - have well defined processes for
    - releasing software
    - test / release cycles
    - admitting new core people
  - voting is a last resort in a healthy community
    - everything else should be tried before a vote

identification - who are the poisonous people?
  - it's usually obvious who will suck and drain your time
  - usually use silly nicknames
  - use CAPITAL LETTERS, !!!?!?!one!!, WTFLOLOMG
  - hostility, demands help, blackmail, rile people deliberately
  - accusations of conspiracy
  - conceit, refuse to acknowledge arguments
    - sweeping claims, reopen topics continuously
  - lack of cooperation

disinfection - removing the poisonous people
  - assess the damage
  - how are they affecting your attention and focus?
  - are they distracting / paralysing the project?
  - _dont_
    - feed the troll
    - give jerks a purpose/purchase
    - get emotional (stick to the facts)
  - _do_
    - pay attention to newcomers, even if annoying
    - look for the fact under the emotion
    - extract real bug report / action
    - know when to give up and ignore
    - know when to boot from community

Steve

stevecoast.com

_______________________________________________
talk mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk

Reply via email to