Skip to main content

Moderating open source conversations to keep them productive

5 min read

Summary: Codes of conduct, community reporting, and tiered moderation tools keep open source discussions productive. Adopt a code of conduct through a pull request, then start with the least severe moderation tool that will de-escalate the conflict, from minimizing a comment up to blocking a user.

Table of contents
This is the fourth and final post in a series on successfully managing open source communities at scale.

Successful open source projects create a welcoming community by fostering productive conversations, promoting healthy collaboration, and de-escalating conflict when things get heated or off topic. Once you’ve set contributors up for success, automated common community-management tasks, and established a governance model, you should be prepared to moderate conversations in the repositories you maintain, to help build a strong community around your code.

Establish a Code of Conduct

Before you begin moderating, establish a code of conduct. Codes of conduct communicate expectations for behavior within your community, as well as how you will enforce those expectations when a contributor’s behavior diverges. While you don’t necessarily need to adopt a code of conduct on day one for small projects, as your project matures and your community grows, you’ll want to adopt a code of conduct, and adopt one before you need it. Not only does it signal to potential contributors that you will take action when necessary, it will reduce the appearance of bias when you respond to disruptive behavior.

Like open source licenses, a number of widely adopted codes of conduct already exist, and you adopt one by adding a CODE_OF_CONDUCT file to the root of your repository. This is best accomplished through a pull request, which often prompts a necessary conversation within your community, and allows you to adapt the code of conduct to your needs. On GitHub, if you visit your community profile, you should be prompted to choose from several popular code of conduct templates.

Allow community members to report comments

Before you can moderate disruptive behavior, you first need to learn about it. While it’s possible for maintainers of small projects to read every single comment and issue, as your project grows and matures, that quickly becomes untenable. Empower your community to flag unproductive comments for your review by opting-in to community reporting. Once you enable it, you’ll get a queue of community-flagged comments. Review them with the tiered moderation tools described below so you can respond in proportion to the behavior and, ideally, bring it back in line with community norms.

Moderating disruptive comments

The least severe tiered moderation response is minimizing a comment. Minimized comments are hidden by default when a comment thread loads, meaning viewers must opt-in to seeing the comment’s content. Hiding a comment is useful for reducing the screen real estate of off-topic or inappropriate comments, politely signaling to the author that such comments are not in line with community expectations.

If part of a comment contributes to the conversation but another part detracts, you can consider editing the comment to bring it in line with community norms, or for particularly egregious comments, you can delete it entirely.

Lock heated conversations

When an entire conversation is heated, unproductive, or violates your code of conduct, sometimes it’s best to lock the conversation entirely, either permanently or temporarily. Locking a conversation prevents anyone without write access to the repository from commenting or reacting on the issue. Doing so can force folks to step away from the conversation for a bit (and let emotions settle) so that things can get back on track, in the issue and across your repository.

Sometimes you might also lock an issue when a decision has been made and subsequent comments are not constructive. When you lock the conversation, you’ll be prompted to offer a reason, which appears in the issue timeline. Like minimized comments, this once again communicates to contributors what behavior is acceptable and what is not.

Limit interactions to force a cooldown

When disruptive behavior spills from one or two issues to your entire repository (or even across repositories), consider limiting interactions. Interaction limits are the next more aggressive moderation tier, and allow you to restrict who can comment or open issues and pull requests to established users, to those that have previously contributed to your repository, or only to those with write access. Similar to locking conversations, interaction limits are intended to enforce a temporary cooldown period when things get heated.

Block disruptive users

The final and most aggressive form of moderation is blocking a disruptive user. Blocking a user prevents them from interacting with your repositories in any way. This ban can be permanent, or if a first or second infraction, ideally temporary to allow for self-rehabilitation of their behavior. When you block the user, you could do so silently to avoid conflict, or if you’d like to, you can notify the user that they’ve been blocked, with a link to the offending content and/or your code of conduct. In a perfect world, disruptive comments would be a misunderstanding or lack of understanding of community norms, meaning a “time out”, along with specifics about the deviation, could create more constructive community contributions, moving disruptive contributors into productive contributors.

A code of conduct, community reporting, and GitHub’s tiered moderation tools won’t make every thread pleasant. They do give you a proportionate response to each kind of disruption, and that’s what keeps a growing community welcoming.

Keep reading

Ben Balter

I'm Ben Balter, and I write here about developer platforms, product and engineering leadership, open source, and showing your work. I spent over a decade building developer platforms at GitHub. For five years I was a product manager for trust and safety, shipping 500+ features and the API endpoints behind them to 50M+ developers. I also led a bottom-up rewrite of GitHub Pages and wrote the open source library behind GitHub's license detection, and my open source projects have hundreds of millions of downloads. I wrote Open and Async, the playbook for remote and distributed teams, and shipped a Model Context Protocol (MCP) server alongside it so agents can query it directly. More about the author

Follow along: Bluesky LinkedIn

Originally published June 15, 2021 View revision history

This page is open source Help improve this article on GitHub

Keyboard shortcuts

Search

  • / or ⌘ K Open search
  • ↓ or j ↑ or k Move through results
  • Enter Open the selected result
  • Esc Close search

Go to

  • g then h Home
  • g then p All posts

This page

  • y Copy link to this page
  • ? Show this list