Condor Platform All articles
Engineering Culture

The Governance Gap: Building Moderation Systems That Protect Communities Without Destroying Moderators

Condor Platform
The Governance Gap: Building Moderation Systems That Protect Communities Without Destroying Moderators

Photo: NASA Headquarters / NASA/Joel Kowsky, Public domain, via Wikimedia Commons

The Policy Document Is Not the System

A great many open infrastructure communities have a code of conduct. Fewer have a functioning moderation system. The distinction matters enormously, and conflating the two is one of the most common governance errors that project leaders make.

A code of conduct is a statement of values and expectations. It describes what behavior the community considers acceptable and what it does not. That is necessary, but it is not sufficient. The actual work of community governance—receiving reports, investigating incidents, making decisions, communicating outcomes, handling appeals, and supporting the people who do all of the above—requires infrastructure that most communities have never deliberately designed.

The consequence of this gap is predictable. A small number of volunteers, typically the project's most committed community members, absorb an expanding and emotionally demanding workload with no rotation schedule, no formal support, and no defined boundaries. Eventually, they burn out. When they do, the community often loses not just its moderators but some of its most experienced contributors.

The Emotional Labor Dimension

Community moderation in technical spaces involves a category of work that the open infrastructure field has historically been reluctant to discuss directly: emotional labor. Moderators do not simply evaluate whether a comment violated a policy. They manage the distress of people who have been harmed by community behavior. They navigate the defensiveness of people accused of that behavior. They absorb the frustration of community members who believe decisions were made incorrectly. They carry the weight of incidents that do not resolve cleanly.

This work is genuinely difficult. It requires skills—active listening, de-escalation, the ability to hold competing perspectives simultaneously—that are not automatically possessed by people who are excellent engineers or researchers. And it is performed, in most open infrastructure communities, entirely without compensation, formal training, or structured peer support.

Projects that treat moderation as a purely procedural function, and moderators as interchangeable policy-enforcement agents, consistently underperform on both fairness and sustainability. The emotional dimension of the work is not a peripheral concern; it is central to whether the system functions.

Rotation and Redundancy as Structural Requirements

One of the most straightforward interventions available to open infrastructure projects is the implementation of a formal rotation schedule for moderation responsibilities. This is not a novel idea—it is standard practice in other high-stakes volunteer contexts, from crisis hotlines to community mediation programs—but it remains surprisingly rare in technical communities.

A well-designed rotation schedule accomplishes several things simultaneously. It prevents the concentration of moderation burden on a single person or small group. It ensures that knowledge of the community's governance practices is distributed across a broader set of contributors rather than held by a few individuals who may eventually leave. It creates natural intervals for moderators to step back, recover, and return with renewed capacity. And it signals to the community that moderation is a shared responsibility rather than a specialized function delegated to a permanent committee.

Redundancy is the structural complement to rotation. A moderation system that depends on any single individual being available is a fragile system. Projects that build explicit redundancy—ensuring that every moderation function can be performed by at least two or three people at any given time—are substantially more resilient to the inevitable disruptions of volunteer availability.

Designing Appeals Processes That Work

The appeals process is one of the most consequential and most frequently neglected components of community governance. When community members believe a moderation decision was incorrect, they need a credible path to challenge it. Without that path, grievances fester, trust erodes, and the community's perception of its governance as fair or arbitrary is shaped by the worst-handled cases rather than the best ones.

An effective appeals process has several characteristics. It is handled by people who were not involved in the original decision—this is a structural requirement, not merely a preference. It has a defined timeline, so that people waiting for a response are not left in indefinite uncertainty. It produces a written outcome that explains the reasoning behind the final decision, even when that decision is to uphold the original action. And it is genuinely capable of reversing decisions when the original process was flawed.

That last point deserves emphasis. An appeals process that exists on paper but never results in reversals is not a functional appeals process. Community members will quickly recognize it as performative, and their trust in the broader governance system will decline accordingly.

Mental Health Support as a Governance Investment

The idea that open infrastructure projects should invest in mental health support for their moderators may seem like an unusual governance recommendation. It is, in fact, one of the most practical ones available.

Moderation work in active communities regularly exposes volunteers to harassment, threats, and distressing content. The cumulative effect of this exposure, without structured support, produces exactly the burnout and attrition patterns that leave communities ungoverned. Projects that have implemented regular check-ins, peer support structures, and explicit permission for moderators to step back when they need to report significantly better moderator retention than those that treat such support as unnecessary.

Some larger open infrastructure projects have formalized this through partnerships with employee assistance programs or mental health resources designed for volunteer communities. Smaller projects have implemented more modest versions—a regular video call for the moderation team that is explicitly not about case review, a norm of checking in with each other before diving into difficult incidents, a clear and culturally supported expectation that stepping away temporarily is appropriate and will not be interpreted as abandonment.

Onboarding New Moderators Without Replicating Old Problems

Communities that successfully build sustainable moderation systems eventually face a new challenge: how to bring in new moderators without transferring the dysfunctional norms that led to burnout in the first place. This requires deliberate onboarding rather than informal apprenticeship.

Effective moderator onboarding includes explicit training in the community's governance philosophy, not just its policies. It includes structured exposure to past cases—both well-handled and poorly handled—so that new moderators can develop judgment from the community's history rather than starting from scratch. It includes clear communication about the support structures available and an explicit invitation to use them. And it includes a graduated responsibility model in which new moderators handle lower-stakes situations before taking on more complex cases.

The communities that have built the most durable governance systems share a common orientation: they treat moderation as skilled work that requires preparation, support, and ongoing development—not as a duty that any sufficiently committed volunteer can absorb indefinitely without assistance. That orientation, more than any specific policy or tool, is what separates governance systems that sustain communities from those that consume the people who try to run them.

All Articles

Related Articles

What Code Comments Cannot Carry: The Documentation Transfer Problem in Open Infrastructure

What Code Comments Cannot Carry: The Documentation Transfer Problem in Open Infrastructure

After the Founder: Why Leadership Transition Is an Architectural Problem, Not a Personnel One

After the Founder: Why Leadership Transition Is an Architectural Problem, Not a Personnel One

Self-Sufficient to a Fault: When Open Infrastructure Optimizes Itself Into Isolation

Self-Sufficient to a Fault: When Open Infrastructure Optimizes Itself Into Isolation