Discipline in Open Source Projects?

An anonymous reader asks: "I've recently been elected (with another project member) to lead an open source project that we helped start several years ago. One of our goals as project leads is to implement some way to discipline project members who are disruptive to the project. In the past, the project has been slowed by flames, trolls, and even filibustering. Everyone says they want to work together, but some refuse to accept majority opinion. This passive-aggressiveness, coupled with growing despair on the part of other members, would have caused the project to dissolve if a vote had not taken place to elect new leadership (which the project has been lacking for some time). As co-leads we want the project to continue and grow, and we welcome all opinions, but how can disruptive members be told 'enough is enough'? We've read Ubuntu's Code of Conduct, but how can it or something similar be enforced?"

Comments

There can be only 1.

[Aladrin]

There's only 1 way that I know of: Remove their privileges.

In a project, that means removing their ability to contribute. You can do this by either breaking their arms or removing their commit privileges.

Seriously, though, if someone is disruptive and filibustering, WHY are you letting them have important tasks? Either go on without the task or give it to someone else.

Re:There can be only 1.

[squiggleslash]

I think we should cut their goolies off*.

On a more serious note, one of the major issues with computing is that some of the most brilliant minds are also some of the most obnoxious. To the point that, without mentioning any names, a major free software operating system project was founded in part because the founder had his privileges removed from another major free software operating system. The offshoot is considered by most to be far, far, more successful, yet there's little question the founder isn't easy to work with, and whether just or not, the fact his privileges were removed in the first place wasn't exactly a surprise.

* I'm probably dating myself with that reference.

Re:There can be only 1.

[dodobh]

Theo De Raadt lost commit privileges to NetBSD. Paludis isn't quite another operating system.

Google Tech Talk About OSS + People

[jptxs]

http://video.google.com/videoplay?docid=-421601196 1522818645

What is this, kindergarten?

[Zerth]

If somebody is detrimental to a voluntary project, you only have 2 real choices. If they are in charge, fork the project. If they aren't, ignore them.

Trying to punish them is kind of futile. Unless you want to keep this person around and are trying to "reform" them, just add them to your killfile, ban them from your forum, and revoke their CVS access.

Why do you have to have a majority?

[TheWanderingHermit]

You could study how the Friends (Quakers) handle discussions and disputes. They've managed to do quite well for about 400 years or more without using voting and majority rules. One problem with a majority rule is that there is always the chance of a person or people feeling left out and ignored. While working with building a consensus takes longer, when you reach a decision and move forward, you're moving forward with everyone able to put their full support into it.

Whenever I bring this up in discussion forums, especially in "geek" forums, quite often I see strong reactions that it won't work and can't work and so on, but it has been working for close to 400 years. I've used it in special ed classrooms with emotionally disturbed students and they found they could work with it when they got used to it. I have seen it work in many groups. The principal ingredient, in most cases, is for the leaders to treat all with respect and to expect others to do the same.

Simple: Do Not Feed Trolls.

[chris_sawtell]

Let me say it again.

Do NOT Feed Trolls

Honest; it's a simple as that.

As a further protection take away their posting
rights to the SCM system you use, and be sure to keep offline
backups because poisonous people can get very nasty.