pieterh wrote on 23 May 2016 17:15

Kevin Meredith asked me an interesting question on Twitter. What's the best way to answer this?, I wondered. A tweet is so short. A full blog post so clumsy. So here's the Social Architecture FAQ, which I will update with other questions if/when people ask them. LET F=1.

How can we grow software communities with more female developers?

The short answer is, "remove barriers to entry and opportunities for selection bias." The longer answer is, "contributors self-select from the existing pool of users and potential users, and you cannot distort this process without harming the community."

I'll work on a more detailed answer.

How do you deal with rude contributors who are brilliant/highly skilled?

The short answer is, "kick them out." The longer answer is, "give them enough rope to hang themselves, then kick them out." The full answer is a little more involved.

Let me first deconstruct that glaring assumption of individual worth. "Brilliant/highly skilled" is worth nothing if that brilliance does not go in the right direction. And "direction" is a social decision, as I've explained often. Individual skill tends to distort and mislead, if it's not well balanced by other minds. Here we have the problem with "rude," which is short-hand for "does not listen to others to arrive at consensus." So not only is that brilliance worthless to the project, it will be actively damaging for it. Brilliance combined with modesty and polite collaboration, now we're talking.

So your starting point for measuring a contributor is, "does s/he understand and follow the project's rules?" If those rules don't exist or are badly designed, it creates a huge vulnerability for projects, that lets bad actors in the gate.

Now, it tends to be bad marketing to simply eject people based on their attitude. It also gives them material to attack the project for bias and elitism. It is better to embrace a bad contributor, and give them time to show their damaging behavior. By rapidly merging their (awful) pull requests, then quickly reverting or cleaning them up, it creates a historical record. "You did not use our guideline of clear problem statement with minimal solution. I'm going to revert your patch, sorry."

Some people are rude by accident. A bad day perhaps. Such contributors will rapidly correct their behavior. They'll apologize and send a new patch. They'll welcome others' help. It's clearly visible. And some people immediately walk away when their brilliant yet chaotic and outlaw patch is reverted. And then some will argue and try to bully their way through. These are the ones you need to ban, when it's time.

To properly ban a bad actor you need consensus of the project. That means allowing enough pain to accumulate that others demand action. You can judge this. Then you start a public thread, cite the violations of procedure, and ask the actor to explain themselves. They will come back with more bluster, blame you for merging their patch, etc. Then you ban them, block them from the mailing list, tweet your decision, and revert all their patches from the code base.

If after all that there is fallout, use it to promote your project. The willingness to ban brilliant-but-rude contributors makes the difference between long term health and a cheap short term fix "oooh, look, great new features!" (that no-one really wants and which break everything.)