No Asshole Rule

There is a very nice thing called "No Asshole Rule". It means that an asshole has two options:

• Stop being an asshole (which happens very rarely)
• Leave the community (or workplace)

Why? Because no matter how talented a person is, if they are so disruptive, it is definitely doing more harm than good. Disruptive behavior:

• Makes existing members who are uncomfortable with it leave
• Makes potential new members not join
• Gives a bad example, potentially giving such behavior a chance to stick as a standard, as something that is allowed
• Sucks up resources to treat it

It can create a vicious circle where non-toxic community members leave as they can't stand the growing toxicity, and toxic people come to replace your veterans, slowly converting your community into 4chan.

I would recommend that you follow the usual guidelines on firing a person if you decide to interfere. Provided that you already tried speaking to the user, it it reasonable to go this way:

1. The user receives an official warning stating all of the problems related to their behavior. It has to be delivered privately so that it doesn't look like publicly humiliating the user. Note that this warning is not the first step of solving the problem, it is the beginning of your last resort before actually firing the person, it should only come in place after you have discussed it unofficially before -- maybe multiple times. The user must be notified that it's actually their last opportunity to change their behavior.
2. They are given a set period of time to change their attitude. Send them some good guidelines to follow, monitor their behavior. If you feel like it is necessary, give comments on their performance.
3. If they don't change enough by that time, no "last last chances" are to be given: the warning and the deadline were already their last chance. You write another private message stating that this person wasn't a good fit for your team (and it is important to use past tense), and has to leave it. You can give an option to continue writing code for you, but do not keep such a person in your team as someone who can communicate with the rest.

If that toxic person does not act in all good faith and becomes more disruptive during their last trial (for example, they try to cause you as much harm as possible as they don't want to change), you can just ban them outright.

Unfortunately, you either allow no toxicity in your community (see the SE example), or it grows very toxic is just a matter of time (watch tons of examples on the Internet), and believe me, a lot of good people who are not comfortable with being in a toxic community will leave you if it happens.

Your other option is a complete split of your two communities into two parts, one with toxicity being allowed, and the other one considered to be a "safe space", but the toxic part may be really hard to maintain and possibly require too much additional moderation. A certain Russian web-site uses such an option, and conflicts join the "toxic and almost unmoderated part" can sometimes continue in the main section.

Perhaps this disruptive person would form a perfect "team of one", consisting only of that person, if they write code that well. It should not be considered a bad ending if it does happen -- I have seen people in my life who just can't and don't want to work in any kind of teams, but who perform awesome if left to work alone.

Most likely, though, you will just see your Mister Disruptiveness leave the community, and no matter how you miss their helpful input, the group will quickly become noticeably more healthy.

I don't know how you could specifically implement this in your community, but in the official website of an anime I was in, they handle users like that but giving them some sort of privilege which doesn't have to do with moderation, and keep those privileges as long as the "brilliant but problematic" users behaved well. For example, they gave them attention by listening to their ideas, and if they showed some signs of appeasement they gave them access to some exclusive material or information (such as interviews with some actors, etc. ) or they tried to get them busy by giving them some assignments which kept them occupied like working in infopedias, documentation, etc.

While the other answers are excellent, I would like to add another possible set of approaches.

This answer is premised on the assumption that, if possible, you'd like to keep X as a contributor (otherwise, existing answers exhaustively cover the ground), and offers possible approaches on how to do that while avoiding negative impact on other users.

1. Channel the user's feedback in more objective, less verbal ways

The feasibility of this solution largely depends on what tools you have available as a community.

One of the problems (though it's more of a symptom than a root cause) is that the user's disapproval is free-form, which allows it to take forms that are hostile and divisive to the community.

If possible, you can channel that into less confrontational form by changing the feedback from freeform text to StackExchange-like voting - either simplistic up/down votes on the commits; or even more complex scoring criteria, like that used in figure skating (0-10 for code style matching the project style; 0-10 for absence of bugs; 0-10 for resilience).

Doing this - if possible with the tools available to community - will allow you to solve the problem at least partially: the user still has the outlet to express their opinion of code quality, BUT that outlet is far less personalized and therefore leaves no bandwidth for verbal embellishments to carry the less-than-welcome verbal style of "X".

You can even try to tickle "X"'s vanity by offering a separate channel just for "X score", separate from other reviewers - that way they won't feel the typical Stack Overflow problem of an expert feeling that their on-merits downvote is meaningless because 10 people will offer sympathy upvotes, or simply not understand the subject matter enough to understand why the correct vote is "down" (_{I'm leaving aside the question of whether that problem is rooted in reality or overinflated ego :)}).

2. Arrange a PR handler for "X"

This approach is premised on "X" having a member of a community they trust a lot.

If they do, ask them to consider a PR arrangement: "X" can vent to the trusted member "P"; with the stipulation that "P" will faithfully publicly relay the substance of "X"'s opinion, sans the unwelcome form that opinion takes today.

3. Have a good influencer

This approach is premised on "X" having a member of a community they trust a lot and whose opinion they trust a lot. Let's call them "B"

As a particular real-life example, a community I'm a member of has several people with somewhat conflict prone personality (myself included), of whom at least 3 have a respected community member they are nearly always willing to listen to because they respect them greatly. It does not need to be a moderator - as a matter of fact a moderator would be more problematic in this role due to perception of authority overreach on "X"'s part.

When "X" says something out of line, it is "B"'s job to gently tell them "Dude, not cool!". Obviously, it's up to "X" to choose to listen to that admonition, but in personal experience, this approach works FAR better than admonitions from either community at large, or persons of formal authority in community. Intrinsic vs. Extrinsic motivation, as it were (the motivation here being, desire not to disappoint "B")

4. Address "X"'s concerns

Why is "X" railing against a poor quality code commit? There may be widely varied reasons. May be they just ate something wrong and feel ornery. May be they are Hermione A-type, who is offended by mere existence of poorer quality code in the universe. In those two cases, there's not much you can do to address their concerns. On the other hand, "X" may be ticked off for valid reasons:

• They are upset because it falls to "X" to fix the bugs in poor quality commits.

  Solution: Offer assurance that, if "X" finds a bug, someone else will be responsible for promptly fixing the bug, OR the commit gets unaccepted till that happens.

• They are using this as an attempt to assert authority, formal or informal.

  Solution: Give them authority which can be expressed in more objective way (for example see approach #1 above regarding numeric scoring). Or give them a Gold Badge of Quality - you'd be flabbergasted at how far a person will go for a meaningless Internet badge, including being nice :)

5. Incentivize "X"

We are on Stack Exchange here. Gamification and incentives absolutely must be considered as a valid approach.

It may be a bit harder to do in a coding project environment; but easier in other communities. Find a set of incentives to be nice for "X" to respond to.

• Do they need to do some annoying make-work as part of community participation? Offer to take it off them. If they really are a stellar enough contributor, it may be worth the special treatment.

• Do they have something they deeply wish that is in the community's power to offer? (a pony? Software feature being prioritized? Being called "Exalted Lord of Coding Evermore" daily in public? ). Consider granting this.

  The downside is that you're, in essence, rewarding poor behavior, which creates long term moral hazard. The upside is that you're keeping a valuable contributor sans their poor behavior.

It's completely up to you. You can choose between X publishing 'brilliant' code for the community or letting him be rude. These are the two options you can choose between.

If I was the moderator of that online community, I would immediately remove X. A community is supposed to be fun (it depends on the type of course, but the definition of fun could also be not being rude).

At some point, his rudeness will also make other members leave. That way other valued members may not be active in the community anymore.

I had a Minecraft server for a long time and also had to deal with these kinds of users that ruin the sphere of the community. A few users left the server because of his behaviour. This was one of the reasons I decided to stop with my Minecraft server. But if I decided not to, I would've banned the rude user. At some point you'll have to anyway.

But again, it's up to you.

You can choose between X publishing 'brilliant' code for the community or letting him be rude.

I answered a similar question on The Workplace about talented but disruptive employees.

My answer there (and here) is that you need to weigh up the benefit of having the the talented person on board with the cost of dealing with the disruption they bring. If the former out weighs the latter then they can stay, but, if over the long term they cause more pain than the benefits they bring, they have to leave.

Things you need to consider:

• Can you afford to give them special treatment and deal with the comments etc. from other community members who will (quite rightly) see this as favouritism?
• Do you want to change the rules of your community to "legalise" their behaviour?

Ultimately, if someone doesn't want to play by the rules you will have to remove them from the community. If you don't do this you will run the risk of other members leaving so in the end you won't have a community at all.

If your community is strong it will survive the removal of one of its members.

Does anyone here have any suggestion about how to proceed to get a community that, while not too PC at least doesn't scare a lot of people off due to abrasiveness?

I've been part of a team that dealt with a very similar situation, and based on that experience, here's my advice:

1. Decide on a standard for what constitutes acceptable behavior in your community
2. Acknowledge that, no matter what standard you choose, some people won't want to abide by it
3. Don't waste a scrap of effort trying to please those people. If they outright refuse to behave in the manner you expect of contributors, kick them out without hesitation.

In this case, it sounds like you think the user's posts are not appropriate - or in other words, you want to adopt the standard that behavior which is likely to drive away new contributors should not be tolerated, and you know that this user's behavior does not meet that standard. In that case, you need him to leave the community (or the part that involves interacting with new contributors), at least unless and until he can stop making these kinds of posts. The thing about behavioral standards is that they are set by how people actually behave, not really by any sort of written policy. If you give a good contributor a pass to violate the rules, other people lose respect for those rules and you'll have a harder time getting the rest of the community to follow them.

Besides, as you said, you think his behavior is driving away new and existing members, some of whom would be good contributors. A simple cost/benefit analysis tells you the same thing: get rid of this one guy for the health of your community. He may be perfectly nice in person, but that doesn't matter. It's his contributions to your community that drive people away - those members you're losing aren't going to think "oh, he's a nice guy in person, I'll just put up with him." For that reason, your decision of whether to let him be a part of your community should be based only on his contributions there. After all, if he were a perfectly nice poster but a horrible person to be around in real life, would you hold that against him?

An alternative choice would be to adopt a standard of behavior by which the user's rude responses are acceptable. Then people who are bothered by those comments will leave. If that's what you wanted, you would have to acknowledge that and not concern yourself with keeping those users around. But of course that does give your community a certain kind of reputation, and you've said you don't really want that.

As far as how you implement this in practice: depending on the level of activity in this community, you may need to have some moderators who can react to any problematic posts reasonably quickly. But in the long run, reacting quickly is probably less important than reacting decisively.

The problem here is two fold. Firstly "too PC" is very subjective and going from completely open to having any sort of community guidelines might be "too PC" for some people, X in particular from the sounds of it.

Your second problem is X's mentality towards the community. From what you've posted it he's good and he knows it, and he's got himself into a position where he either thinks he's running the project, or at least has a large overview over it.

As a community you need to lay down some basic common sense rules about language and behaviour. Don't make it aimed at X, but don't be surprised if he takes it personal. Always try to be polite when dealing with him and just point out that as a growing community it's time certain ground rules were laid out for everyone. If he can't even handle that then you may have to face losing X, some people just don't work well in a team.

If you can talk him round to accepting basic ground rules as not being too PC then you have a chance. You mentioned that several people have met X in real life and that he's pleasant, so if possible perhaps discussing this with him face to face might be a good idea. Simply explain that his jokes don't come off well and that his way scares off a lot of new members. Whilst their code might not be as good as his, with encouragement rather than beratings they will improve over time and become helpful members of the community.

Another option is to take away his ability to berate the newer members. Whilst your laying out the ground rules introduce a team responsible for monitoring new commits / pull requests. This team can be responsible for pointing out the poor code to newer members but in a politer way. If X asks why he's not on this team just let him know that his time is more valuable writing code and fixing bugs than reviewing commits. If he has got it into his head that he's overseeing the project he may insist, in which case you'll have to explain to him that his behaviour scares off newer members and that's why he's not on the team.

Regardless of what actions you do take, make sure you do it as a community and make sure that X has his opportunity to comment and oppose the changes as a member of the community so he doesn't feel isolated and that the community is against him. Keep the process open and let him see that the majority of the community want these newer members, want growth and want some basic ground rules on how you treat each other.