On 10 August 2010 17:19, SteveC <[email protected]> wrote: > 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 >
Hey I fully support what you have said. From the ubuntu community, their code of conduct works well http://www.ubuntu.com/community/conduct as it provides guidelines that can be adhered to, or conversely used to put those who damage the community on a timeout. It's worked well on a few occasions, and I think an OpenStreetMap version of the code of conduct that has to be signed up to would be beneficial. Steve _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
