Moderation on a code collaboration platform

GitHub’s content moderation strategy is built around a simple premise: the platform exists for software collaboration, and moderation should reflect that. Developers rely on each other’s code, often linking projects together in complex dependency chains. Removing content isn’t just about taking down a post—it can break builds, disrupt forks, and stall work across dozens of downstream projects. That reality shapes how GitHub approaches enforcement.

The platform’s stated priorities are threefold: put developers in charge of moderating their own projects, make enforcement actions fair and transparent, and apply the least restrictive fix wherever possible. GitHub has shared these principles in policy discussions, at tech conferences, and in its contributions to the Santa Clara Principles on Transparency and Accountability, which define baseline standards for how platforms handle content moderation. The updated principles are expected this December.

Maintainers as first-line moderators

Much of the moderation on GitHub happens at the repository level, where owners and maintainers are best positioned to judge what belongs in their projects. Community norms vary widely across projects—what’s acceptable in one repo may violate the rules of another—and maintainers understand that context better than any central team could.

GitHub encourages maintainers to set clear expectations and use the available tooling to enforce them:

  • Document expectations: A README describes the project and collaboration norms. A CONTRIBUTING file explains how people can get involved. A CODE_OF_CONDUCT spells out what participation is allowed. When a contributor violates those standards, maintainers can point to the documentation as the basis for moderation.
  • Use moderation tools: Blocking users, locking conversations, and limiting comments are built-in options that take less time than manual review.
  • Delegate moderation authority: Repository owners can grant trusted collaborators specific privileges to help moderate, sharing the workload without giving up control.

Rights-based enforcement

When GitHub staff do intervene, the approach is grounded in international human rights law, including freedom of expression and rights of association and assembly. Those rights carry limitations—hate speech, harassment, doxxing, sexually obscene content, incitement to violence, disinformation, and impersonation are all restricted under GitHub’s Acceptable Use Policies.

The enforcement philosophy is straightforward: take the narrowest possible action, allow appeals, and disclose what was done. In practice, that means acting at the repository level rather than the account level when that’s sufficient to address the violation. GitHub’s transparency reports describe this as restricting content “in the narrowest way possible” and frame the appeals process as “a key component of fairness”—users can refute a violation or address it to get content or accounts reinstated.

Context is especially important on a code platform. A text file or image that looks problematic in isolation might be an integral part of a legitimate software project. Because projects fork, link, and incorporate each other’s work, any content restriction can ripple across the platform in ways that aren’t immediately obvious. That interdependency is why GitHub says it must be judicious about removals and why it favors minimal interventions.

Developers and platform regulation

GitHub is frequently grouped with social media companies in regulatory proposals, despite being a fundamentally different kind of platform. Much of GitHub’s content is user-generated, which pulls it into rules aimed at other services. Those rules can have unintended consequences for developers and for open-source ecosystems that depend on code availability.

Developers themselves have an opportunity to shape these policy discussions. GitHub suggests that developers can help policymakers understand how proposed regulations would actually affect software collaboration and can flag unintended consequences. The company invites developers to reach out on Twitter or through its public developer policy repository for help framing those conversations.