A code of conduct sets behavior expectations, report paths, and enforcement responsibilities for an open source project community.
An open source code of conduct is a public policy that sets expectations for behavior in a project community. It explains where the rules apply, how reports can be made, who handles them, and what kinds of responses are possible when behavior harms the community.
A code of conduct is not a substitute for moderation, governance, or maintainers who are willing to act. It is useful when the project connects the words to reporting channels, enforcement responsibility, privacy handling, and visible community norms.
What a code of conduct does
A code of conduct gives contributors a shared baseline before conflict occurs. It can name expected behavior, unacceptable behavior, reporting options, enforcement responsibilities, and possible consequences. It can also show that maintainers recognize community work as part of the project, not a distraction from code.
The policy helps different people in different ways. New contributors can see what behavior is expected before joining. Maintainers have a reference point when a thread becomes hostile. Moderators can explain why an intervention happened. Users can understand that project spaces are not unlimited debate forums.
The strongest codes of conduct avoid vague promises. They say which spaces are covered, which role receives reports, how privacy is handled, and how decisions are made. Without those details, the policy may look serious while leaving every hard decision undefined.
What it does not solve alone
A code of conduct does not guarantee safety, inclusion, legal compliance, or conflict-free collaboration. It does not automatically create a moderation team, train maintainers, or provide a fair appeal process. It also cannot replace platform rules on services such as GitHub, GitLab, mailing-list hosts, chat platforms, forums, or event venues.
Projects should avoid treating adoption as the finish line. The real test is whether participants know how to report a problem and whether the project can respond consistently. A project with no capacity to read reports, protect private information, or make difficult decisions should address that capacity gap before promising more than it can deliver.
This does not mean small projects should avoid codes of conduct. A short, honest policy can still help. It should match the project's size and say what maintainers can realistically do.
Scope: where the policy applies
Scope answers a practical question: which spaces count as project spaces? Issues and pull requests are obvious for many software projects, but the community may also use discussions, mailing lists, chat rooms, documentation repositories, translation platforms, forums, release meetings, social media accounts, and events.
Contributor Covenant 2.1 describes scope across community spaces and official representation. A project using that template still needs to decide what official representation means for its own community. For example, a maintainer speaking from a personal account may not be the same as a maintainer using a project account.
Scope should be easy to find. Link the code of conduct from the README, CONTRIBUTING guide, community profile, event pages, and chat welcome messages where relevant. A policy hidden in the repository root may not reach the places where problems happen.
Examples and expectations
Examples help participants understand the standard. Useful examples include respectful disagreement, constructive feedback, welcoming newcomers, staying on topic, avoiding harassment, not publishing private information, and accepting correction when behavior causes harm.
Examples should not be treated as an exhaustive list. A person can harm a community in ways not named exactly in the document. The policy should give maintainers enough room to act while still making expectations understandable.
Avoid language that turns every disagreement into a conduct violation. Technical disagreement, design criticism, and release debate are normal in open source. The line is crossed when behavior becomes harassment, targeted abuse, intimidation, private-information exposure, or a pattern that prevents others from participating.
Reporting paths
A reporting path should answer who receives reports, how to contact them, what information helps, whether reports can be private, and what happens if the report concerns someone on the enforcement team.
For a small project, the path may be one private email address monitored by two trusted maintainers. For a larger project, it may be a conduct committee, foundation process, or platform reporting path. The project should not direct sensitive reports into a public issue unless that is genuinely appropriate for the situation.
Reporters should not have to confront the person they are reporting. They should also not be asked for unnecessary personal details. Useful information includes the channel, date, people involved, links or screenshots where safe to share, and the behavior that caused concern.
Enforcement responsibility
Enforcement responsibility means someone can decide what happens after a report. That role may belong to maintainers, moderators, a conduct committee, a foundation group, or a platform team depending on the project.
The code of conduct should not leave responsibility implied. If maintainers receive reports, say so. If a committee handles reports, name the committee or process. If platform rules control some outcomes, make that boundary clear. A repository owner may be able to lock a thread; a foundation may control event sanctions; a chat platform may control account suspension.
Responsibilities also need backup. If only one person receives every report, the process is fragile and may fail when that person is unavailable or involved in the report.
Privacy and transparency
Conduct reports often include sensitive context. Public transparency matters, but it should not expose reporters, private evidence, or unnecessary personal details. A project can publish a brief outcome or moderation note without revealing the full report.
The right level of disclosure depends on severity, channel, safety risk, and project norms. A public thread lock may need a short public reason. A private harassment report may need private handling and only a limited public outcome, if any.
Privacy also applies to the accused person. A fair process avoids public pile-ons and gives people a chance to understand the concern where appropriate. Serious threats, harassment, or legal exposure may require platform escalation or qualified professional advice.
Contributor Covenant versus custom policies
Many projects adopt the Contributor Covenant because it is a known template with behavior standards, scope, enforcement responsibilities, and enforcement guidelines. It can be a practical starting point for projects that do not want to write policy language from scratch.
A custom policy may be better when a project has unusual spaces, foundation rules, regional legal requirements, a large event program, or an existing governance process. Custom does not mean better by default. It means the project accepts responsibility for maintaining the text and explaining the process.
Whether using a template or custom policy, the project still needs a reporting contact, enforcement role, privacy expectation, and connection to moderation practice. Copying policy text without filling those operational gaps is incomplete.
How to add one responsibly
Start by choosing a policy that fits the project. Read the current text, identify placeholders, and decide who can enforce it. Then publish it in a visible location and link it from the project's main contribution paths.
Before announcing it, answer these questions:
- Which project spaces are covered?
- Who receives reports?
- What happens if a report involves that person?
- Which moderation actions are available?
- Which decisions are public, private, or platform-controlled?
- How can someone ask for review of a decision?
Do not surprise a community with a policy that nobody can enforce. If the project has maintainers, moderators, or a steering group, they should understand their roles before adoption.
Common failure modes
The most common failure is adopting a code of conduct without a report path. The second is publishing a report path that goes to one unavailable maintainer. Another is claiming broad enforcement while having no moderation authority in the channels where community interaction happens.
Other failure modes include inconsistent enforcement, public handling of private reports, unclear appeals, treating technical disagreement as conduct by default, ignoring repeated low-level hostility, and letting powerful contributors avoid consequences.
A code of conduct can also fail by being too hidden. If new contributors only discover it after a conflict, it is not doing preventive work.
Fit the policy to project scale
A single-maintainer library, a large desktop application, a foundation project, and a conference-connected project do not need identical procedures. The smaller project may only need a clear report address, backup contact, and moderation authority. The larger project may need a conduct team, private intake process, appeal path, and coordination with event or foundation rules.
Scale should not become an excuse for having no process. Even a small project can say who receives reports and what happens if that person is involved. The point is to match promises to capacity.
As the project grows, review the policy against real community spaces. New chat rooms, events, translations, sponsorship, or working groups can create conduct situations the original policy did not anticipate.
The review should also check whether contact addresses, alternate contacts, and moderation permissions still work. A policy can become stale even when the text still looks current and professionally written.
Stale process details can fail exactly when a serious report needs a fast, trusted path.
Code-of-conduct element map
| Element | Reader question answered | Responsible role | Privacy implication | Failure mode |
|---|---|---|---|---|
| Scope | Where does it apply? | Maintainers or governance group | Low unless reports are involved | Covered spaces are unclear |
| Behavior examples | What is expected? | Community leaders | Low | Standards are too vague |
| Report path | How do I report? | Named contact or team | High | Reports go public or nowhere |
| Enforcement role | Who decides? | Maintainers, moderators, or committee | Medium to high | Nobody can act |
| Outcomes | What can happen? | Moderators or governance group | Medium | Responses feel arbitrary |
| Appeal or review | Can a decision be reconsidered? | Governance or conduct group | High | Decisions lack accountability |
Code-of-conduct readiness checklist
Before relying on a code of conduct, confirm that:
- The policy is linked from the main contribution paths.
- Covered spaces are named clearly.
- Reporting contact details work and have backup.
- Reports involving an enforcement person have an alternate route.
- Moderation actions are proportional to severity and repeat behavior.
- Private information is handled carefully.
- Platform rules and project rules do not contradict each other.
- The policy connects to governance and moderation roles.
A useful code of conduct is practical before it is symbolic. It tells people what behavior the project expects and gives maintainers a way to respond when those expectations are broken.