← Governance

The Honest Code of Conduct

This is the Code of Conduct for the Honest project: the framework, the book, the methodology, the curriculum, the certification, and any other component that operates under the Honest name and trademark.

The Code is short on purpose. It says exactly what it means and nothing more. It is designed to be read in full by every contributor and to be understood without specialized training in dispute resolution. If you have read it, you know what is expected of you and what is expected of the moderators.

Some sections of this Code are immutable. They are marked clearly. Immutable sections cannot be amended, expanded, weakened, or reinterpreted by any future maintainer, working group, governance body, or commercial licensee. Any attempt to do so is a breach of the project’s Constitution and triggers the trademark revocation provisions of the Foundation Charter.

Our goal

Build software that prevents hidden mutable state in the code, and create open materials that let other developers do the same.

That is the mission, in full. Everything in this Code exists to serve it. If a proposed action or enforcement does not advance the mission, the project does not take it.

What we expect

What is not okay (the enumerated violations) — IMMUTABLE

The following list of prohibited behaviors is the complete list of conduct that constitutes a violation of this Code. Behaviors not on this list are not violations. No moderator, working group, or governance body, present or future, may take an enforcement action against a behavior that is not explicitly listed below. The list cannot be expanded.

  1. Sending unwanted private messages to a contributor after they have asked the sender to stop. The contributor’s request to stop must be explicit and documented. Repeated contact after such a request constitutes harassment.
  2. Posting another person’s private information (real name if pseudonymous, home address, workplace, family members, immigration status, medical information) without their consent. Doxxing.
  3. Threats of physical harm, sexual violence, or property destruction, directed at any person, in any project venue.
  4. Repeated personal insults directed at a specific contributor in a project venue. Insults must be directed at the person rather than at their work, and they must be repeated after the recipient has objected. A single sharp remark in technical discussion is not a violation; sustained personal attacks are.
  5. Submitting code that the contributor knows or has reason to believe contains malicious payloads, undisclosed dependencies, supply-chain attacks, or backdoors. Knowingly malicious contributions.
  6. Impersonating another contributor or claiming credit for another contributor’s work. Identity fraud or attribution fraud.
  7. Spam or sustained off-topic posting that disrupts active technical discussion in project venues. This applies to genuine spam (bulk irrelevant content) and to sustained derailment of technical threads, not to occasional digressions.

That is the complete list. Seven enumerated violations. No more will be added by moderation discretion or by reinterpretation. The list can only be amended through the constitutional amendment procedure, and Article III of the Constitution prohibits adding violations of any of the categories listed in the “What is explicitly out of scope” section below.

What is explicitly out of scope (the jurisdiction limits) — IMMUTABLE

The Code of Conduct does not apply to, and no enforcement action may ever cite:

No enforcement action may ever cite any of the categories above as the basis for a sanction. This jurisdiction limit is immutable.

The reason this section exists is straightforward: every documented pattern of OSS governance capture has used one or more of the categories above as the entry point. By foreclosing these categories explicitly and immutably, the Code closes the attack surface that has produced governance failures across the open-source ecosystem over the past decade.

Honest is not a substitute for law enforcement — IMMUTABLE

Honest project moderators have no police powers, no legal authority, no investigative capacity, and no jurisdiction over the lives of contributors outside project venues. The seven enumerated violations exist because those specific behaviors interfere with the project’s mission inside project venues. They do not exist because the project is trying to substitute for the legal systems of the jurisdictions in which contributors live.

If a contributor believes a behavior is harmful, the question that determines the appropriate venue for redress is whether that behavior is illegal in the relevant jurisdiction.

If the behavior is illegal in the contributor’s jurisdiction (criminal harassment, stalking, threats, doxxing where it is criminalized, child endangerment, fraud, identity theft, distribution of intimate imagery without consent, and similar conduct), the appropriate remedy is the law enforcement and judicial system of that jurisdiction. The contributor should report it to law enforcement first. Honest moderators may also take action under the enumerated violations if the behavior also constitutes a violation listed in this Code, but the law enforcement path is primary and the project’s action is secondary, additive, and limited by what is actually in this Code. Honest moderators are not police. They cannot compel testimony, gather evidence, issue subpoenas, conduct interviews, or impose legally-binding sanctions. Anyone who needs those powers needs the people who actually have them, which is to say, the police.

If the behavior is not illegal in the contributor’s jurisdiction, Honest will not invent a private legal regime to address it. The project is not in the business of policing behavior that the actual legal systems of the actual jurisdictions where contributors live have decided not to criminalize. If a behavior is offensive but lawful, the project’s response is the same as the legal system’s response: do nothing within the project’s enforcement powers, beyond whatever the contributor can do for themselves with the tools the project’s venues provide (block, mute, ignore, refuse to respond, leave the channel).

Contributors who believe a behavior should be illegal but is not are welcome to advocate for legal change through their own democratic processes, in their own jurisdictions, in the venues where laws are actually made. The Honest project is not such a venue and will not become one. The project does not adjudicate disputes about what the law should be. It enforces a closed list of seven specific violations against behavior in its own venues, and nothing more.

This principle has direct consequences for the procedural requirements that follow. The “public evidence required” rule, the “specific enumerated violation cited” rule, and the “right of public reply” rule are not bureaucratic obstacles; they are the structural expression of the principle that Honest enforcement is bounded by its own narrow mandate, not by the open-ended demands of any contributor who believes the project should protect them from behavior the legal system has not protected them from.

If you are reading this and you believe Honest is “failing to protect” you from a behavior that is not on the enumerated list and not illegal in your jurisdiction, you are correct that the project will not act. That is not a flaw in the project. That is the project working as designed. The project is not your private legal system, and if you need a legal system, the public ones are the venue. If the public ones are not adequate to your need, the answer is to advocate for legal change in those public systems, not to demand that Honest become a substitute.

This principle is immutable. No moderator, working group, governance body, or commercial licensee, present or future, may interpret this Code as authorizing enforcement against behavior that is not on the enumerated list. The project is not, will not become, and cannot be amended into, a private police force.

How enforcement works (the procedural requirements) — IMMUTABLE

When a possible violation is reported, the following procedure applies. No moderator may deviate from it. The procedure is immutable.

  1. Public evidence is required. Every enforcement action must cite the specific quoted statement, comment, message, or commit that constitutes the violation, with its original context preserved, posted publicly along with the enforcement decision. Enforcement actions citing “a pattern” or “multiple complaints” without specific quoted evidence are forbidden. The complainant’s identity may be anonymized in the public record; the evidence may not be.
  2. The cited evidence must match an enumerated violation. The enforcement decision must cite which of the seven enumerated violations the evidence constitutes, by number. Enforcement decisions that fail to cite a specific enumerated violation are invalid and have no force.
  3. Right of public reply. A contributor who is subject to an enforcement action has the right to a public reply, posted in the same venue as the enforcement decision, with equal prominence, within 30 days of the decision. The reply may include their version of events, additional context, or their disagreement with the decision. The moderators have no editorial control over the reply.
  4. Sanctions are tiered and proportionate. First-time violations of categories 4, 6, or 7 (insults, impersonation, spam) result in a private warning. Repeat violations or violations of categories 1, 2, 3, or 5 (harassment, doxxing, threats, malicious code) may result in temporary suspension of project privileges. Permanent bans require either a violation of category 3 (threats) or repeated violations after multiple warnings. Permanent bans must be unanimously agreed by the entire moderation team and are subject to appeal to the Foundation.
  5. Moderation actions are reviewable. Any contributor sanctioned under this Code may appeal to the Foundation that holds the trademark. The Foundation has authority to overturn any enforcement action that fails to meet the procedural requirements above, including the requirement to cite specific evidence and a specific enumerated violation. The appeal process is documented in the Foundation Charter.
  6. Enforcement records are public. Every enforcement action ever taken under this Code is logged in a public registry maintained by the Foundation. The registry includes the cited evidence, the enumerated violation cited, the sanction applied, the contributor’s reply (if any), and any appeal outcome. The registry cannot be deleted or selectively pruned.

These six requirements together constitute the procedural floor for all enforcement under this Code. Moderators may not act with less procedural rigor than this. They may not act on subjective criteria. They may not act in secret. They may not act without evidence. They may not act without citing the specific rule the evidence violates.

Moderator misconduct — IMMUTABLE

Moderators are not above this Code. They are bound by it more strictly than any other contributor, because the procedural requirements that apply to ordinary contributors apply doubly to the people who hold enforcement power. The most likely source of governance violations in any open-source project is its own moderation team acting on subjective criteria and protected by its own colleagues. This section closes that attack surface explicitly.

Moderators are subject to the seven enumerated violations with the same force and the same evidentiary standards as any other contributor. A moderator who threatens, doxxes, repeatedly insults, submits malicious code, impersonates another contributor, or spams may be sanctioned up to and including permanent ban from the project, regardless of their role.

In addition, moderators are bound by six further violations that apply specifically to the exercise of their moderation role. These violations exist only for people acting in a moderation capacity, and only in connection with that capacity:

  1. Taking enforcement action against a behavior that is not on the list of seven enumerated violations in the “What is not okay” section. A moderator who sanctions a contributor for “tone,” “patterns of behavior,” “creating an unwelcome environment,” “implicit harassment,” off-project speech, personal political views, refusal to use particular pronouns or terminology, or any other category that the jurisdiction limits exclude, has committed misconduct, regardless of how strongly the moderator believes the sanction was justified, and regardless of how many other moderators agreed with them.
  2. Failing to cite specific quoted evidence and a specific enumerated violation by number in an enforcement decision. A moderator who acts on “a pattern,” “multiple complaints,” “concerning interactions,” or any other vague basis without identifying the specific quoted statement that constitutes the violation, and the specific numbered violation it constitutes, has committed misconduct.
  3. Denying, editing, hiding, suppressing, or interfering with a sanctioned contributor’s right of public reply. The right of reply is structural and cannot be revoked by moderation discretion. A moderator who interferes with it has committed misconduct.
  4. Removing, deleting, hiding, or selectively pruning entries in the public registry of enforcement actions. The registry is the institutional memory of the moderation team’s decisions. It cannot be revised by the same people whose decisions it records. A moderator who alters it has committed misconduct.
  5. Retaliating against a contributor for filing a report, filing an appeal, or publicly criticizing a moderation decision. Public criticism of moderation is explicitly out of scope for this Code (see the jurisdiction limits) and cannot be the basis for any sanction. A moderator who sanctions a contributor for filing a report, filing an appeal, or criticizing the moderation team has committed misconduct.
  6. Coordinating with other moderators or external parties to evade the procedural requirements of this Code. Group decisions to act on subjective criteria, to suppress evidence, to deny replies, to coordinate retaliation, or to conceal misconduct are themselves misconduct by every moderator who participated in them. There is no safety in numbers.

These six additional violations apply only to moderators and only when acting in a moderation capacity. They are immutable and may not be amended, weakened, narrowed, reinterpreted, or worked around by any procedure.

Reports of moderator misconduct go to the Foundation, not the moderation team

A moderation team cannot impartially investigate its own members. Reports of moderator misconduct are therefore filed directly with the Foundation that holds the Honest trademark, bypassing the project’s moderation team entirely. The Foundation’s trustees have the authority and the duty to:

Reports of moderator misconduct should include the same elements as any other report (specific quoted evidence, venue, date, citation of which of violations 8 through 13 the evidence constitutes). The reporter’s identity is protected from disclosure to the implicated moderator until and unless the Foundation determines that the report has merit and the substance proceeds to a determination, at which point standard right-of-reply procedures apply to the implicated moderator.

Sanctions available against moderators found to have committed misconduct

The Foundation’s authority to apply these sanctions cannot be overridden by the project’s governance body, by any working group, by any commercial licensee, or by the moderation team itself.

What happens when a project governance body refuses to enforce a Foundation finding

A Foundation finding of moderator misconduct is binding on the project. If the project’s governance body refuses to act on a Foundation finding — refuses to remove a moderator the Foundation has determined committed misconduct, refuses to recognize a Foundation-imposed sanction, or attempts to reinstate a moderator the Foundation has barred — the project governance body has itself committed a violation of the immutable provisions of this Code, and the Foundation has the authority and the duty to revoke the project’s right to use the Honest trademark.

This is the structural protection of last resort. A moderation team that has captured the project and refuses to discipline its own members, supported by a project governance body that refuses to override them, loses the project’s right to operate under the Honest name. The captured project either reverts to compliance or has to fork under a different name. There is no third option.

This sequence — moderator commits misconduct → Foundation finds and sanctions → project governance refuses to comply → trademark revoked — is the full chain of enforcement against captured moderation. Each step is independently load-bearing. The sequence cannot be broken by any procedure short of forking the project under a different name.

Why moderators are held to a higher standard than ordinary contributors

The asymmetry is deliberate and structural. An ordinary contributor who violates the Code can be sanctioned by moderators using the procedural floor. A moderator who violates the Code can sanction themselves, conceal their own misconduct, retaliate against anyone who reports them, and use their authority to entrench their position. The procedural protections that protect ordinary contributors from moderator overreach become meaningless if moderators are not themselves held accountable.

The six additional violations and the Foundation-routed enforcement procedure together ensure that moderation power is checked by an independent body that has both the authority and the structural independence to override captured moderators. Without this layer, the rest of the Code’s protections are aspirational. With it, they have teeth.

Maintainer misconduct — IMMUTABLE

Maintainers are not above this Code either. The role of maintainer (the people who control the project’s technical direction by deciding what code gets merged, what features get accepted, and what standards apply) is a separate failure mode from moderator capture and requires its own enforcement layer. Where moderators capture by sanctioning contributors out of the project, maintainers capture by refusing to merge contributions from contributors they ideologically disagree with, applying technical standards selectively, or making technical direction decisions in private. The pattern shows up in parallel to moderator capture in many comparable projects, sometimes with the same individuals occupying both roles, sometimes with maintainer capture as the primary attack vector.

Maintainers are subject to the seven enumerated violations with the same force and the same evidentiary standards as any other contributor.

In addition, maintainers are bound by six further violations that apply specifically to the exercise of their maintainer role:

  1. Refusing to merge a contribution on grounds unrelated to the technical merits of the contribution. A maintainer who rejects a pull request because of the contributor’s political views, personal characteristics, off-project speech, or “tone” in the contributor’s commit messages or PR description has committed misconduct. Rejection on technical grounds (the code is wrong, the design is incompatible, the tests do not pass, the contribution does not fit the project’s published technical standards, the contribution would weaken the immutable governance provisions) is not misconduct. Rejection on non-technical grounds is.
  2. Applying the project’s technical standards selectively based on the contributor’s identity, affiliations, or perceived alignment. A maintainer who applies looser standards to contributions from preferred contributors and stricter standards to contributions from disfavored contributors has committed misconduct, regardless of how the maintainer characterizes the difference. Technical standards must be applied consistently, with the same rigor, to every contribution from every contributor.
  3. Merging changes that violate the immutable provisions of the Constitution, the Code of Conduct, or the Foundation Charter. A maintainer who approves a pull request that, for example, weakens the immutable governance documents, removes the trademark notice, or amends a clause that the Constitution prohibits from being amended has committed misconduct, even if the merge is procedurally legitimate at the technical level.
  4. Failing to publish technical decisions in a venue where they can be reviewed by the contributor base. Maintainer decisions about the project’s technical direction (architectural changes, deprecations, breaking changes, choice of dependencies, choice of platforms, security policy changes) must be visible in a venue contributors can read and respond to. Decisions made in private channels or off-project venues that affect the project’s direction without contributor visibility are misconduct.
  5. Removing, suspending, or stripping the privileges of another maintainer without documented reasons that meet the project’s stated criteria for maintainer removal. Coordinated removal of dissenting maintainers is one of the most common capture tactics. Removal of a maintainer must be documented, must cite specific conduct that meets the project’s published criteria, must allow the removed maintainer a right of public reply equal to the right of reply for sanctioned contributors, and must be reportable to the Foundation as potential misconduct.
  6. Coordinating with other maintainers or with external parties to evade the procedural requirements of this section, to suppress reports of maintainer misconduct, or to prevent the Foundation from receiving such reports. Group decisions to enforce on non-technical grounds, to suppress dissenting maintainers, to make technical decisions in private, or to conceal misconduct are themselves misconduct by every maintainer who participated in them.

These six additional violations apply only to maintainers and only when acting in a maintainer capacity. They are immutable and may not be amended, weakened, narrowed, reinterpreted, or worked around by any procedure.

Forking is not maintainer misconduct

A maintainer who unilaterally forks the project, builds a competing version, and tries to redirect community attention to the fork has done something the project’s source code license explicitly permits and that the FOSS tradition has always recognized as legitimate. Forking is the fundamental escape valve of every FOSS license. It is not misconduct under any circumstances. A maintainer who can persuade the community to follow them to a fork has won the argument; the right response is to lose the community, not to use governance to prevent the fork. The Honest project respects the right to fork as absolute and does not use trademark, governance, or any other mechanism to discourage forks of the open materials. (The trademark is a separate question: a fork cannot use the Honest name without a trademark license, which is exactly the structure that lets the Foundation revoke licenses from captured projects. But the source code, the methodology, the curriculum, and the governance documents are all forkable under their respective open licenses, and any maintainer who believes a fork is the right answer is entitled to make one without fear of retaliation under this Code.)

Reports of maintainer misconduct go to the Foundation, not the maintainer team

Maintainers cannot impartially investigate their own members. Reports of maintainer misconduct are filed directly with the Foundation that holds the Honest trademark, bypassing the project’s maintainer team entirely. The Foundation’s trustees have the authority and the duty to:

Reports of maintainer misconduct should include the same elements as any other report (specific evidence — quoted PR comment, link to the rejected contribution with the maintainer’s stated reason, link to the private channel where the decision was made, screenshot of the unilateral removal action — venue, date, citation of which of violations 14 through 19 the evidence constitutes). The reporter’s identity is protected from disclosure to the implicated maintainer until and unless the Foundation determines that the report has merit and the substance proceeds to a determination.

Sanctions available against maintainers found to have committed misconduct

The Foundation’s authority to apply these sanctions cannot be overridden by the project’s governance body, by any working group, by any commercial licensee, or by the maintainer team itself.

What happens when a project governance body refuses to enforce a Foundation finding

A Foundation finding of maintainer misconduct is binding on the project. If the project’s governance body refuses to act on a Foundation finding — refuses to remove a maintainer the Foundation has determined committed misconduct, refuses to recognize a Foundation-imposed sanction, or attempts to reinstate a maintainer the Foundation has barred — the project governance body has itself committed a violation of the immutable provisions of this Code, and the Foundation has the authority and the duty to revoke the project’s right to use the Honest trademark.

This is the same chain of last-resort enforcement that applies to moderator misconduct. The two enforcement paths are independent (a project can have moderator capture without maintainer capture or vice versa) but the consequences for refusing to comply with Foundation findings are identical.

Why maintainers are held to a higher standard than ordinary contributors

The asymmetry is the same as the moderator asymmetry, applied to the technical decision-making role. An ordinary contributor whose contribution is rejected has the right to file an appeal and to ask the Foundation whether the rejection met the project’s published technical standards or whether it constituted maintainer misconduct under one of violations 14 through 19. A maintainer who rejects on non-technical grounds, then conceals the rejection in private channels, and uses their authority to remove dissenting voices from the maintainer team, has captured the technical direction of the project as completely as a moderator who sanctions contributors out of the project. The procedural protections that protect ordinary contributors from maintainer overreach become meaningless if maintainers are not themselves held accountable.

The six additional violations and the Foundation-routed enforcement procedure together ensure that maintainer power is checked by an independent body that has both the authority and the structural independence to override captured maintainers. Without this layer, the technical-direction-capture attack surface is wide open and the rest of the Code’s protections become irrelevant to the actual technical governance of the project.

Reporting

Read this section carefully before filing any report.

If the behavior you want to report is a crime in your jurisdiction, contact law enforcement first. Not Honest. Not “in addition to” Honest. First. Honest moderators are not police, have no investigative powers, cannot compel evidence, and cannot offer the protections that actual law enforcement can. If you have been threatened, stalked, doxxed, defrauded, or subjected to any other criminal conduct, the venue for redress is the legal system of your jurisdiction. Honest is not. You may file a report with Honest after you have contacted law enforcement, and Honest may take action under one of the enumerated violations if the conduct also constitutes one of those specific listed behaviors, but the law enforcement path is primary and the Honest path is secondary.

If the behavior you want to report is not a crime in your jurisdiction, ask yourself whether it is on the explicit list of seven enumerated violations in the section above. If it is not on the list, Honest will not act, and filing a report will produce no enforcement outcome. The project’s scope of enforcement is the enumerated list and only the enumerated list; behaviors that are unpleasant, offensive, “uncivil,” or that “create an unwelcome environment” are not on the list, are not violations, and will not be enforced against. This is intentional. See the immutable sections above.

If the behavior is on the enumerated list and you wish to file a report, send it to the moderators at: [email address to be designated when the project goes public].

Reports should include:

Reports without specific evidence cannot result in enforcement action and will not be processed. Reports citing behaviors that are not on the enumerated list cannot result in enforcement action and will not be processed. Reports demanding action for behavior that is “implied,” “patterned,” “tonal,” or “creating an unwelcome environment” without identifying a specific enumerated violation will be acknowledged and refused.

This is not bureaucratic obstruction. It is the procedural floor that prevents the project’s governance from being captured by anyone who believes it should police behavior outside its narrow mandate.

If you ever feel physically threatened or believe someone is in real danger, stop reading this document and contact law enforcement immediately. Honest cannot help you with physical danger. Honest can only act on the seven enumerated violations after the immediate danger is being handled by people who actually have the power to handle it.

Amendment procedure

The amendable portions of this Code (the “Our goal” preamble, the “What we expect” section, the “Reporting” section, and this “Amendment procedure” section itself) may be amended by the project’s governance body, with the consent of the Foundation that holds the trademark, following the procedure documented in the Constitution.

The immutable sections (enumerated violations, jurisdiction limits, enforcement procedure) cannot be amended by any procedure. They can only be replaced by forking the project under a new name, surrendering the right to use the Honest trademark, and starting a new community.

This is not a rhetorical commitment. It is enforceable through the Foundation Charter, which binds the trademark holder to revoke the project’s right to use the Honest name if the immutable sections are amended, weakened, or reinterpreted. See FOUNDATION_CHARTER.md for the enforcement mechanism.

Why this Code is structured this way

If you are reading this and finding the immutable sections unusual, you are not wrong. Most Codes of Conduct in modern open-source projects are deliberately broad, deliberately vague, and deliberately discretionary. They are written that way because their authors want maximum latitude to address whatever situations arise.

This Code is written the opposite way for a specific reason: maximum latitude for moderators is the attack surface that produces governance capture. Every case of an OSS project being captured by a small group of activists with their own agenda has used broad language and discretionary enforcement to do the capturing. If the project’s authors care about the project’s future more than they care about moderation latitude, they will write a Code that constrains moderators rather than empowering them.

This Code constrains moderators. It does so deliberately. It does so as the load-bearing defense against capture. The constraints are immutable because mutable constraints are not constraints at all; they are simply the current consensus of whoever holds the moderation seats today, which can be replaced tomorrow by a consensus that says the opposite.

The cost of this design is that the project cannot use moderation to address every kind of harm a contributor might experience or believe they have experienced. That cost is real and the project accepts it. The benefit is that the project cannot be captured by anyone who wants to use moderation as a weapon against the contributors who advance the mission. That benefit is the entire point.

Build great software together, advance the mission, and let disagreements be technical disagreements. Everything else is out of scope.