Managing Conflict

Conflicts in software projects almost always involve people, not code. Two contributors submit competing implementations of the same feature. Someone argues about every design decision but never ships anything. A long-time contributor starts missing deadlines without explanation. These situations are uncomfortable to address, which is why most managers don't address them until they've gotten much worse.

The key insight is that doing nothing is not neutral: it signals to everyone watching that the behavior is acceptable.

What to Do

When someone on your team or among your contributors is causing problems, work through these steps in order. Most situations resolve at step three or four; reaching step seven means you have a serious problem, but it also means you have documentation.

Make sure you are not guilty of the same sin.: You won't get far complaining that a contributor is rude in code reviews if your own reviews have the same tone. Check yourself first.
Check your expectations.: Are you certain the other person knows what standard they are supposed to meet? If your contribution guidelines don't specify what a good commit message looks like, you can't reasonably be frustrated when someone writes "fix stuff". Document expectations first, then enforce them.
Check the situation.: Is something else going on? Someone who has been reliable for a year and suddenly goes quiet may be dealing with something you don't know about. Ask directly but leave room: "I've noticed you've been less active lately. Is everything okay? Is there anything blocking you?" gives them space to explain without feeling interrogated.
Document the issue.: Write down specifically what happened and why it falls short of expectations. Vague frustration ("they're just difficult") doesn't help you or anyone else. "In the last three pull requests, the contributor dismissed review feedback without explanation and merged without approval" is actionable.
Check whether others see the same thing.: If you are the only person having this experience, you may be missing context. If multiple people have the same concern, that's important information—both for addressing the issue and for deciding how urgently to act.
Talk with the person directly.: Have a private conversation before escalating. State what you have observed, not what you have concluded. "I noticed that the last two PRs were merged without waiting for review" is better than "you keep ignoring the review process." Then give them a chance to respond before deciding on next steps.
Escalate if the problem continues.: One serious offense or a repeated pattern after a direct conversation warrants escalation. In a workplace context this means your HR department or your manager. In an open-source community context it means invoking the Code of Conduct process. Do this sooner rather than later: people who act in bad faith count on others giving them another chance until the situation becomes impossible to address.

Toxic Contributors

Research software projects regularly attract contributors who argue about everything but finish little, or who are technically skilled but consistently hostile in review. They are a significant drain on maintainers [Aurora2019].

The standard advice—be patient, assume good faith, try harder—is often wrong when applied to people who have already demonstrated a pattern. A more useful frame: you are running a community, and the health of that community is your responsibility. Allowing one person to make others feel unwelcome costs you multiple contributors and damages the project far more than losing one difficult person does.

When a contributor's behavior is affecting others, you can:

Document and warn.: Issue a formal warning citing specific incidents. The purpose is not punishment but clarity: the person now knows exactly what is expected and that continued violations will have consequences.
Restrict access.: On platforms like GitHub you can require that a particular contributor's pull requests be approved before they are merged, or that all their comments be moderated. Use these tools before banning.
Remove them.: If the behavior continues after a warning, remove the contributor's access to the project. This is easier if your Code of Conduct says clearly that the maintainers reserve this right, which is another reason to have one.

None of this needs to be permanent. People sometimes come back later in a better frame of mind and make genuine contributions. But you don't owe anyone indefinite chances to disrupt your project.

When the Whole Team is Dysfunctional

Occasionally the problem isn't one person but the dynamics of the whole group. Individuals who work fine separately somehow produce a team that is worse than the sum of its parts.

If you are managing the team, the first step is to acknowledge that the problem exists. The second is to look for structural causes: Are roles unclear? Are decisions being made without input from the people who have to implement them? Is there a history that's producing resentment nobody is naming directly?

Sometimes the answer is to reset team structure, redistribute work, or bring in a mediator. The worst thing you can do is hope the situation improves on its own. It almost never does.