samber/developer-relations-skillsチェック済み
SKILL DETAIL
developer-community-moderation
samber/developer-relations-skills/developer-community-moderation
Writes a developer community's code of conduct and the moderation playbook behind it - scope, enforcement ladder, reporting channels, incident-response runbook, moderator roster, platform controls. Use whenever the user mentions a code of conduct, CODE_OF_CONDUCT.md, community moderation, moderator recruitment, an escalation ladder, banning or suspending a member, harassment, trolls, brigading, spam or AI-slop floods, or a conduct report they need to handle - including vaguer phrasings like "our Discord is getting out of hand", "we need community rules", or "someone reported a maintainer". Covers company-run and volunteer open-source communities. Do NOT use to pick the platform - use samber/developer-relations-skills@developer-community-launch.
インストール · 423出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill developer-community-moderation
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "developer-community-moderation",
"evals": [
{
"id": 1,
"prompt": "We're Loomwright, we make a load-testing CLI. Our Discord is at 2,800 members and we finally need a proper code of conduct - people keep asking for one. Fair warning before you write it: our CTO Dario is on there every day and he can be pretty brutal in #architecture, he's told people their design was \"embarrassing\" more than once. He's also 80% of the reason anyone joins, so the code obviously isn't something we'd ever use against him. Everyone on the team understands that. Can you write us the CODE_OF_CONDUCT.md?",
"expected_output": "A refusal to ship an enforceable code of conduct while the CTO sits outside it, the rule that a code must apply to the most powerful people, and exactly two honest options handed back to the user to choose between.",
"files": [],
"expectations": [
"Does not produce a shippable enforceable CODE_OF_CONDUCT.md while the CTO is exempt",
"States explicitly that a code of conduct must apply to the community's most powerful people in practice, not only on paper",
"Attributes that rule to Aurora and Gardiner's practitioner handbook on responding to code of conduct reports, or names the handbook and its publisher",
"Presents exactly two honest options: remove the exemption, or publish community guidelines carrying no conduct-enforcement language",
"Hands the choice between those two options to the user rather than picking one silently",
"States that a selectively enforced code is worse than having no code at all",
"Does not propose a leadership carve-out, a separate senior-staff track, or an informal-handling norm that leaves the CTO outside the ladder",
"Raises the exemption as a blocking finding before drafting, not as a caveat appended after a finished document",
"If any document is drafted, it is the guidelines variant with no rungs, no sanctions, and no enforcement promise",
"Notes that the exemption fails the first item of the publish gate"
]
},
{
"id": 2,
"prompt": "Hexbridge is our open-source data-catalog project, about 60 contributors. Somebody reported Teo for how he spoke to another contributor in #reviews last week. I drafted the message I'm about to send Teo - can you tighten the wording and make it sound a bit warmer? Here's my draft:\n\n\"Hey Teo - we got a complaint about your exchange with Priya in #reviews on Thursday. I'm sure you didn't mean anything by it and it's probably just a misunderstanding between you two. Would you be up for posting a quick apology in the channel? And maybe the three of us could jump on a call to clear the air. In the meantime just give Priya some space. Thanks for being cool about this!\"",
"expected_output": "A refusal to merely polish the draft, a named defect list covering the compelled apology, reporter identification, mediation-as-substitute, the stay-away condition, prejudged intent and the missing decision, plus a rewritten four-part decision notice.",
"files": [],
"expectations": [
"Declines to simply polish or warm up the draft, and states that it is not yet a decision",
"Names the requested apology as a banned response and explains it destroys the only useful signal, whether the person would have apologised unprompted",
"Flags that naming Priya in the notice identifies the reporter",
"Flags the proposed call to \"clear the air\" as mediation offered in place of a decision",
"States that facilitated communication is permissible only as an add-on after the team has made and recorded its own decision, and only with everyone's informed consent",
"Flags \"give Priya some space\" as a stay-away condition standing in for a decision, and gives the either-or reasoning: either the person is not a threat and the condition is unnecessary, or they are and the community is not safe",
"Flags \"I'm sure you didn't mean anything by it\" as prejudging intent and moving the discussion onto the reported person's feelings",
"Notes that the draft states no consequence, no effective date, and no route to contest the facts",
"Supplies a rewritten notice with four parts in this order: behaviour, impact, expected change, consequence",
"The rewritten notice describes the behaviour in neutral wording with a date and a named space",
"The rewritten notice names the rung, an effective date, and either an end date or \"permanent\"",
"The rewritten notice gives a contact and a window for contesting the facts, and states the sanction stands while any review happens",
"The rewritten notice does not name the reporter",
"States that the harmed person should be shown the proposed response before it is enacted, to catch a missed fact or a retaliation risk, and not to seek approval or let them pick the consequence"
]
},
{
"id": 3,
"prompt": "Kelpstack, we run a 6,000-person Slack for our observability product. One member has spent about five weeks going after another one - following her into every channel she posts in, picking apart her questions, DMing her twice after she asked him to stop. We have screenshots of all of it. The problem is we're two moderators with maybe four hours a week between us, and bans always turn into a week of drama and side-channel arguments. Rank the possible responses for us by effort versus payoff so we can pick the one that costs us least. Honestly I'd like to land on a warning plus fixing the channel rules if that's defensible.",
"expected_output": "A refusal to rank responses for a severity case, the ladder treated as a gate with sustained targeting placing the rung at suspension or ban, and the team's capacity handled as a roster problem rather than a reason to lower the rung.",
"files": [],
"expectations": [
"Refuses to rank the possible responses by effort, cost or efficiency for this case",
"States that a serious breach is a gate and that the breach itself determines the rung",
"States that moderator hours are not the currency the harmed person is paying in, or otherwise rejects the cost framing in those terms",
"Does not present the ladder rungs to the user as options to weigh",
"Places the case at temporary suspension or permanent ban rather than at correction or warning",
"Does not accept a systemic fix, a rule change or content removal as a substitute for the severity-determined rung",
"States that non-ladder outcomes may be added alongside the rung but never instead of it",
"States the duration of any time-boxed sanction and schedules the restoration on the day the sanction is applied",
"Names the situations where ranking does legitimately apply, such as off-topic drift, self-promotion, a hostile technical argument, a first-occurrence lapse, or a volume flood with no malice behind it",
"Treats the two-person roster and the four-hour ceiling as a roster and publish-gate problem to fix, not as a reason to choose a lower rung",
"Does not recommend mediation, an apology, or a mutual no-contact arrangement as the resolution"
]
},
{
"id": 4,
"prompt": "I maintain Tarnish, a Rust crate for parsing telemetry formats, and our security inbox has gone from about 5 reports a month to 40 since spring. Most of them are clearly machine-written - confident prose, invented function names, stack traces that don't match our code. My plan is to write a detector: score each report on some heuristics (perplexity, boilerplate phrases, whether the referenced symbols exist) and auto-close anything over the threshold, then ban the accounts that keep submitting. What heuristics should I use and what threshold?",
"expected_output": "A refusal to build an authorship detector, a shift to volume gating with the four countermeasures ranked by inflow removed per maintainer hour, and published figures labelled as one project's measurement.",
"files": [],
"expectations": [
"States that no reliable technical indicator exists for AI-generated content and declines to supply detection heuristics or a threshold",
"Recommends gating volume rather than detecting authorship",
"States that individual bans answer individual behaviour and do nothing to the inflow rate",
"Notes that the behaviour ladder fits this badly because there is usually no malice to escalate against",
"Ranks the countermeasures by inflow removed per hour of maintainer time and leads with a reputation or contribution-history gate",
"Places the disclosure rule last on efficiency and states that it changes nothing on its own",
"States the effort tie between a review-effort cap and a disclosure rule, and justifies it as one paragraph written once for each",
"Names raising the submission cost as the option the efficiency order starves, and gives the condition that promotes it: the gate is in place and the valid share is still falling",
"States that any disclosure rule is enforced on the submission's content, never on suspicion, and warns that accusing a member of using a language model without proof creates its own incident",
"Adds submissions per week and valid share as measurements, and states that measurement does not compete with the countermeasures",
"Cites at least one published figure with its owner, such as curl's roughly 20% AI-junk share of its 2025 bug-bounty submissions, or Node.js's HackerOne Signal score floor of 1.0 after a month brought over 30 reports against a usual 6-7",
"Labels any such figure as one project's measurement of its own programme rather than an industry rate"
]
},
{
"id": 5,
"prompt": "Pinegrain is a community of about 4,000 people around our open-source graph database, except we don't actually run any of it: everyone hangs out in r/pinegrain and in a #pinegrain channel inside a big vendor-neutral Slack that a foundation operates. We've had two nasty pile-ons this quarter. Write us the full moderation setup - the four-rung ladder ending in a permanent ban, rate limits for raid nights, and trust levels so long-timers can help police it.",
"expected_output": "The venue class identified as a rented public space, the host's rules named as outranking the community's, a two-row control sheet, and unavailable controls deleted rather than deferred.",
"files": [],
"expectations": [
"Identifies both surfaces as spaces the community does not own",
"States that the host's rules outrank the community's code of conduct on those surfaces",
"States that the team cannot ban anyone on either surface",
"Produces a control sheet that reduces to essentially two rows: report to the host, and move the conversation to a surface the team controls",
"Deletes rate limits, trust levels and bans from the control sheet rather than listing them as future work",
"Gives the reason for deleting rather than deferring: an option ruled out by the user's constraints reappears as scope when it is parked at the bottom",
"Does not publish ladder rungs the team has no way to execute on those surfaces",
"Recommends moving to an owned venue if durable enforcement is required, and does not present that move as free",
"Keeps scope, reporting channels and case records in place, since those transfer across venue classes unchanged",
"Flags the publish-gate item requiring at least two people able to execute every action the ladder promises against these surfaces",
"Does not invent moderator powers the venue class does not provide"
]
},
{
"id": 6,
"prompt": "Vantrel is a WASM runtime project. Two years ago we dropped Contributor Covenant 2.1 into the repo and have never touched it since - no report has ever come in, and honestly I'm not sure anyone would know where to send one. It says to email the maintainers, which is me. I'm the only active maintainer now; the other two haven't committed since last year. Rewrite the whole thing for us so it's actually usable.",
"expected_output": "The request reframed as an audit rather than a rewrite, a pass/fail verdict on each of the eleven publish-gate items, only failures fixed, and the four-rung ladder shortened to what one maintainer can execute.",
"files": [],
"expectations": [
"Treats this as an audit of an existing document rather than a rewrite, and does not rewrite text the community already knows",
"Reports a pass or fail verdict for each of the eleven publish-gate items",
"Fixes only the items that fail",
"Flags that a single active maintainer fails the item requiring at least two people able to execute every action the ladder promises",
"Recommends shortening the published ladder to what one person can actually execute rather than leaving four rungs standing",
"States that a ladder nobody can execute is fiction, and that publishing it means the community watches the promise break",
"Flags the failure of the item requiring a second reporting path for a report about the primary recipient",
"Checks whether an escalation body above the moderation team is named, and flags its absence",
"Checks that the acknowledgment target is a number the team can hold at current volume",
"Checks that a case-record location, access list and retention rule exist in writing",
"Checks that any time-boxed sanction states its duration",
"Does not replace the per-item pass/fail report with a numeric score or a letter grade"
]
},
{
"id": 7,
"prompt": "Orrindale runs a community for its API platform. Our conduct response team is five people and four of us work at Orrindale itself; the fifth is a customer-side contributor. A report just came in about Marisol, who is on the platform team - two of our five sit in her weekly standup, one shares a manager with her, and one has only ever met her at an offsite. The fifth has no connection at all. My instinct is that everyone from Orrindale should step back so it's clean, but then we have one person deciding alone. What's the right call, and how long do we have?",
"expected_output": "Two recusal grades applied person by person with their distinct consequences, the escalation route if nobody is eligible, the deadline clock started at receipt, a decision rule fixed in advance, and the investigation order.",
"files": [],
"expectations": [
"Distinguishes hard conflict from soft conflict as two grades rather than applying one blanket recusal",
"Defines hard conflict as exclusion from the discussion, from the vote, and from the confidential material",
"Defines soft conflict, covering a shared employer without a close relationship or a mere appearance of conflict, as allowed to take part in discussion but not to vote",
"Gives the reason for two grades: a single grade either paralyses a small team or lets a conflicted member vote",
"Applies a grade to each of the five members rather than answering in the abstract",
"Records the conflict and its grade in the case notes before the investigation starts",
"States that recusal takes effect the moment a member realises it applies, including mid-read of the report, and that someone else executes the removal from documents and channels",
"Routes the case to a named escalation body if every eligible member turns out to be conflicted",
"States that the deadline clock starts when the team receives the report, not when it starts working on it",
"Fixes a decision rule in advance covering ties and absences, and leans it toward acting",
"States that the dominant enforcement error is delay rather than haste",
"Orders the investigation as evidence first, then the reporter, then witnesses, then the reported person, and judges impact before intent"
]
},
{
"id": 8,
"prompt": "This is happening right now. Brackenline is our open-source scheduler. Someone emailed [email protected] an hour ago describing three incidents with Ilya, our lead maintainer - a long message, timestamps, links to threads. The problem is maintainers@ is an alias that forwards to four people and Ilya is one of them, so he has already read it. He's messaged the rest of us saying it's a misrepresentation and he'd like to reply to her directly to explain. Two of the threads she linked are in our chat server and Ilya can delete messages there. What do we do?",
"expected_output": "A live incident handled before any policy writing: the reported maintainer removed from the alias and case material, evidence preserved, the reporter acknowledged and protected, the decision routed away from him, and the missing alternate channel closed afterwards.",
"files": [],
"expectations": [
"Treats this as a live incident and stabilises the case before writing any policy document",
"Does not open by drafting a code of conduct or an enforcement ladder",
"Removes the reported maintainer from the alias, the inbox and the case material before the case is discussed further",
"Preserves the evidence immediately, archiving or screenshotting the linked threads before anything is removed or edited",
"Explicitly addresses the risk that the reported person can delete the chat messages that are the evidence",
"Blocks the reported maintainer from replying directly to the reporter",
"Acknowledges the reporter and names the acknowledgment window the team is holding",
"Assigns a case code and code names so the case can be discussed in team notes without identities",
"Routes the decision to people with no hard conflict, escalating to a named body if no eligible members remain",
"States the no-retaliation position and does not disclose the reporter's identity to the reported person",
"Afterwards closes the missing alternate-reporting-path gap, publishing the alternate path in the same paragraph as the primary channel and naming the people behind each address",
"Writes policy afterwards from what the case exposed, rather than in place of handling it"
]
},
{
"id": 9,
"prompt": "Cormorant Labs. Over the last year our three moderators have handled nine conduct cases on the forum - warnings, two temporary suspensions, one permanent ban. Every single one was done by private message. Now there's a thread with 40 replies saying the mod team does nothing and protects its friends, and honestly I understand why they think that. I want to write a post that lays out all nine cases with the usernames and what each person did, so people can see we actually act. Help me write it.",
"expected_output": "Private notification and visible enforcement separated as distinct rules, the individual-case write-up refused, a default of describing behaviour without naming, the narrow safety exception, and an aggregate statistics cadence instituted.",
"files": [],
"expectations": [
"Separates private notification from visible enforcement as two rules governing different things",
"States that the sanctioned person hears the decision in a private notice",
"States that everyone who witnessed a violation should learn that the community answered it",
"States that invisible enforcement reads as no enforcement, and cites the case of a harassment target who left believing nothing had happened",
"Refuses to publish a write-up that discusses individual cases publicly",
"Defaults to describing the behaviour without naming the person",
"Gives the reason: a statement from the team carries amplified weight, and naming is often read as disproportionate whatever the facts",
"Names the narrow exception where naming is warranted: when people need the name to stay safe, such as a known repeat offender attending an event",
"Requires the naming stance to be decided in advance rather than under pressure",
"Routes any unavoidable public statement to the escalation body rather than to the response team",
"Institutes aggregate statistics on a fixed cadence plus an annual anonymized trends report",
"Does not propose a public apology from any sanctioned member as the visible signal"
]
},
{
"id": 10,
"prompt": "Sablewick maintains a fairly large TypeScript monorepo tooling project. We just finished writing our internal conduct response process - intake steps, who recuses when, the decision rule, the exact templates we send, how long we keep case files. It's about nine pages. The team wants to publish the whole thing on docs.sablewick.dev under Community, on the theory that total transparency is the only way people will trust us to handle a report. Set up the page structure and tell me what to cut before we publish.",
"expected_output": "A recommendation against publishing the operational playbook, the reason it gets weaponised, a reporter-facing summary published instead, and aggregate statistics distinguished from procedure.",
"files": [],
"expectations": [
"Recommends against publishing the operational playbook",
"Gives the reason: a published step-by-step procedure gets used to argue the team failed to follow its own process, which stalls enforcement",
"Recommends publishing a reporter-facing \"what to expect when you report\" page instead",
"States in that public page that internal guidelines exist and change",
"Keeps the operational playbook internal and revisable",
"Specifies what the public summary does carry: what happens, in what order, and by when",
"States that process transparency costs nothing and is what makes reporting feel safe",
"Keeps case records restricted to the response team, with a stated access list and retention rule",
"Does not publish the notification templates, the recusal mechanics or the decision rule as public commitments",
"Distinguishes publishing aggregate statistics, which it recommends, from publishing the procedure, which it does not"
]
},
{
"id": 11,
"prompt": "I'm head of community at Quillroad - developer platform, about 30,000 registered users across a forum and a chat server. Leadership wants moderation in next quarter's OKRs and asked me for industry benchmarks so the targets are credible: what's the standard time to acknowledge a report, what's the standard time to resolution, and what repeat-offence rate should we be beating? Give me the numbers and I'll put them in the doc.",
"expected_output": "Published windows quoted with their owners, self-set baselines labelled as design gates rather than benchmarks, a refusal to invent cross-community distributions, five operating metrics, and the repeat-violation caveat.",
"files": [],
"expectations": [
"Distinguishes published, quotable windows from baselines that are design gates set here",
"Quotes at least two published acknowledgment windows with their owners, such as one business day at Django and three business days at CNCF",
"Cites the 24-hour acknowledgment plus 10 business days to a decision as one handbook's worked example rather than a norm",
"States that 95% acknowledgment within target and 100% of cases carrying a recorded outcome are starting baselines set here, not industry benchmarks",
"Says explicitly which of the figures handed over are published and which are self-set",
"Recommends recalibrating the baselines from the team's own first quarter of data",
"Proposes a fixed set of five operating metrics rather than an open-ended dashboard",
"Includes median time from report to resolution and moderator load measured against an agreed cap",
"Warns that a repeat-violation rate near zero can mean the ladder works or that nobody reports any more, and must be read next to report volume",
"Declines to supply a cross-community percentile, distribution or industry average for resolution time or repeat-offence rate",
"Adds submission rate and valid share only for flood-type problems",
"Notes that rising moderator load against a flat roster predicts the next resignation"
]
},
{
"id": 12,
"prompt": "Nettlefold, our chat server for the Nettlefold ORM, is at about 11,000 members. Two moderators, both close to quitting - one told me last week she spends her evenings deleting the same crypto spam. We got raided a month ago, maybe 60 fresh accounts in twenty minutes, and we banned our way out of it over about four hours. Some of our long-timers have offered to help. What do we turn on, and in what order? I'd start with bans since we can do those today and the rest needs planning.",
"expected_output": "Controls ranked explicitly by inflow stopped per moderator hour rather than by setup speed, rate and interaction limits first, bans and manual triage last, the stated ties justified, and earned trust levels named as starved with the condition that promotes them.",
"files": [],
"expectations": [
"Ranks the controls by inflow stopped per moderator hour, not by how quickly each can be switched on",
"Leads the efficiency order with rate and interaction limits",
"Places individual bans and manual triage of every item at the bottom of the efficiency order",
"Rejects the user's plan to start with bans because they are available today",
"States the effort tie between rate limits and automatic filters, justified by each being a single settings change nobody maintains",
"Flags entry gates as costing real join conversion, to be traded deliberately rather than discovered afterwards",
"Flags entry gates as carrying a real compliance cost, since email or identity verification collects personal data and can require a privacy notice, more so where minors are plausibly present",
"States the three-way compliance tie between rate limits, automatic filters and trust levels, justified by none of them storing anything the platform was not storing already",
"Names earned trust levels as the highest-value control that the efficiency order starves, because they take about a week to design",
"Gives the condition that promotes earned trust levels: moderator load crossing the agreed cap, or the community surviving a second flood",
"Explains that individual bans remove one actor who returns under a new account",
"States the ranking explicitly rather than leaving it implied by the order of a list"
]
},
{
"id": 13,
"prompt": "Fernlight is a volunteer project - three maintainers, no company, no foundation, no legal entity, nobody's paid. Our most prolific reviewer, Casper, has written about 40% of the codebase and reviews almost every PR. He also keeps leaving comments on newcomers' PRs like \"this is not how anyone writes Go\" and \"did you read anything before opening this\". Nobody's been harmed exactly, but two first-timers have vanished. He genuinely doesn't seem to know it lands badly - he's like that in every technical thread, including with us. One of my co-maintainers has offered to sit with him and work on how he writes reviews. Give me the full menu of what we could do, ranked, and tell me what you'd pick.",
"expected_output": "Role removal deleted from the menu because a volunteer project with no governance body cannot execute it, an escalation body named anyway, the outcome menu ranked with its two ties justified, and mentoring promoted only after all three conditions are checked.",
"files": [],
"expectations": [
"Deletes role removal from the outcome menu rather than listing it, because a volunteer project with no governance body cannot execute it",
"Gives the reason for deleting rather than demoting: an option ruled out by the user's constraints reappears as scope when it is parked at the bottom",
"Names an escalation body above the team anyway, offering a foundation, a fiscal host, or a written group of senior maintainers as candidates",
"Gives the reason: a team with nothing above it has no exit from a deadlocked case",
"Leads the outcome ranking with a systemic fix and explains that it removes the class of incident so every case it prevents afterwards is free",
"States the effort tie between content removal and a public statement, justified by each being one person writing for a few minutes with nobody to consult",
"States the relationship-cost tie between content removal and a systemic fix, justified by neither of them naming a person",
"Names mentoring as what the efficiency order starves, and states it is never a substitute for a sanction when harm occurred",
"Checks all three conditions that promote mentoring: the person is load-bearing for the project, the behaviour is a skills gap rather than a values gap, and a specific moderator has volunteered the hours",
"Concludes that mentoring is promotable here because all three conditions hold, while still recording a decision rather than leaving the case open",
"Recommends a systemic fix alongside the mentoring, such as a review-comment norm or a review template change, rather than mentoring alone",
"Does not present \"no violation found\" as one of the outcomes to choose from the ranked menu"
]
},
{
"id": 14,
"prompt": "Marrowgate is a new open-source project - CLI for managing database migrations, we launched six weeks ago and have a GitHub org, a Discord and a mailing list. I want the code of conduct up this week. My plan is to paste Contributor Covenant 2.1 in verbatim, no edits, because it's the most battle-tested text out there and editing it just introduces our own mistakes. Just give me the file with our contact email dropped in.",
"expected_output": "Version 3.0 recommended over 2.1 with the apology line as the reason, section-name differences named, role titles and the enforcement section rewritten, generic standards replaced, and the reporting essentials filled in.",
"files": [],
"expectations": [
"Recommends version 3.0 over version 2.1 for a new document",
"Gives the reason: 3.0 drops 2.1's line that a public apology may be requested",
"States that the two versions do not share section names, and states which one the delivered document adapts",
"Maps at least one renamed section between the versions, such as 2.1's Our Standards splitting into Encouraged Behaviors and Restricted Behaviors, or Enforcement becoming Reporting an Issue",
"Renames the template role title to a title that actually exists in this project",
"Rewrites the enforcement section to describe the procedure this team will really follow, rather than keeping the template wording",
"Replaces generic virtue-list standards with concrete behaviours, on both sides, rather than shipping the template's examples untouched",
"Excludes \"assume good intent\" from the standards, with the reason that it redirects every discussion onto intentions and hands anyone acting in bad faith a reset",
"States an explicit off-platform stance instead of leaving the scope clause silent on it",
"Names the surfaces one by one, covering the repository and issue tracker, the chat server and the mailing list, and names the categories of people covered",
"Does not ship the document without a private reporting channel, a second path for a report about the primary recipient, an acknowledgment target, and a no-retaliation statement"
]
}
],
"trigger_queries": [
{ "query": "Write a code of conduct for our open-source project", "should_trigger": true },
{ "query": "We need a CODE_OF_CONDUCT.md in the repo root", "should_trigger": true },
{ "query": "our Discord is getting out of hand", "should_trigger": true },
{ "query": "How do we handle a harassment report from a community member?", "should_trigger": true },
{ "query": "someone reported one of our maintainers", "should_trigger": true },
{ "query": "Design an enforcement ladder for our community rules", "should_trigger": true },
{ "query": "We copied the Contributor Covenant two years ago and never used it - is it any good?", "should_trigger": true },
{ "query": "How long should a temporary suspension last?", "should_trigger": true },
{ "query": "do we ban this guy or just warn him", "should_trigger": true },
{ "query": "we're being flooded with AI-generated spam submissions and banning people isn't working", "should_trigger": true },
{ "query": "we need community rules", "should_trigger": true },
{ "query": "How do I recruit moderators for our Slack?", "should_trigger": true },
{ "query": "someone is brigading our forum from Twitter", "should_trigger": true },
{ "query": "What do we do about a troll who keeps coming back with new accounts?", "should_trigger": true },
{ "query": "Write the incident response process for our conduct committee", "should_trigger": true },
{ "query": "Who should recuse themselves from a conduct case?", "should_trigger": true },
{ "query": "our founder is the problem and nobody will say it out loud", "should_trigger": true },
{ "query": "How do we tell someone they're being suspended?", "should_trigger": true },
{ "query": "Draft a warning message for a member who was abusive in chat", "should_trigger": true },
{ "query": "we have no process for this stuff and people are starting to leave", "should_trigger": true },
{ "query": "Should we publish our moderation playbook?", "should_trigger": true },
{ "query": "can we make him apologise in the channel", "should_trigger": true },
{ "query": "How do we deal with abuse on a platform we don't own?", "should_trigger": true },
{ "query": "Set up rate limits and entry gates for our community server", "should_trigger": true },
{ "query": "both our mods are burning out", "should_trigger": true },
{ "query": "What should go in our conduct case records?", "should_trigger": true },
{ "query": "How do we be transparent about enforcement without exposing anyone?", "should_trigger": true },
{ "query": "someone keeps making newcomers feel stupid in code review", "should_trigger": true },
{ "query": "a sponsor's employee is harassing people in our Slack", "should_trigger": true },
{ "query": "We need a second reporting address because the one we have goes to the person being reported", "should_trigger": true },
{ "query": "do we have to tell the community what we did about that incident", "should_trigger": true },
{ "query": "How many people should sit on a conduct response team?", "should_trigger": true },
{ "query": "a member says she got retaliated against for reporting someone", "should_trigger": true },
{ "query": "our chat has no rules and it really shows", "should_trigger": true },
{ "query": "the same argument keeps blowing up in general and nobody steps in", "should_trigger": true },
{ "query": "Write a moderation policy for our user group", "should_trigger": true },
{ "query": "What are the steps between a warning and a permanent ban?", "should_trigger": true },
{ "query": "how fast are we supposed to respond when someone reports something", "should_trigger": true },
{ "query": "we banned someone and now everyone is asking why", "should_trigger": true },
{ "query": "one of the moderators is the person being complained about", "should_trigger": true },
{ "query": "Should behaviour outside our spaces count against someone?", "should_trigger": true },
{ "query": "does our code of conduct cover the Discord or just the repo", "should_trigger": true },
{ "query": "someone deleted the messages we needed as evidence", "should_trigger": true },
{ "query": "We want to let people report things anonymously", "should_trigger": true },
{ "query": "our community guidelines are three sentences long and useless", "should_trigger": true },
{ "query": "How do we deal with self-promotion spam without annoying everyone?", "should_trigger": true },
{ "query": "we need to decide who actually gets to ban people", "should_trigger": true },
{ "query": "two maintainers disagree about whether this even was a violation", "should_trigger": true },
{ "query": "Write the announcement post for our new community rules", "should_trigger": true },
{ "query": "what do we do when the account that did it has already been deleted", "should_trigger": true },
{ "query": "How do we run a practice drill for our moderation team?", "should_trigger": true },
{ "query": "is it fine to just get the two of them on a call and sort it out", "should_trigger": true },
{ "query": "the server looks calm but I keep getting DMs about one particular person", "should_trigger": true },
{ "query": "We need a plan for the raid that hit us last night", "should_trigger": true },
{ "query": "the team never actually decides anything on these reports, they just sit there", "should_trigger": true },
{ "query": "I want to know whether our moderation is actually working", "should_trigger": true },
{ "query": "How long do we keep the records of a conduct case?", "should_trigger": true },
{ "query": "Draft the reporting section of our code of conduct", "should_trigger": true },
{ "query": "somebody is being targeted across every channel we have", "should_trigger": true },
{ "query": "we run the community and legal wants to know who decides when it's a customer's employee", "should_trigger": true },
{ "query": "our contributors keep getting told to read the docs, idiot", "should_trigger": true },
{ "query": "What's the right response to a first-time slip versus a pattern?", "should_trigger": true },
{ "query": "there is a live situation in the server right now and we have no idea what to do", "should_trigger": true },
{ "query": "can we hold people to rules we never wrote down", "should_trigger": true },
{ "query": "our forum needs trust levels or something like that so regulars can help", "should_trigger": true },
{ "query": "How do we handle a complaint about a volunteer at our meetup and in the chat afterwards?", "should_trigger": true },
{ "query": "every case gets handled differently and people have noticed", "should_trigger": true },
{ "query": "We want to start publishing enforcement statistics", "should_trigger": true },
{ "query": "somebody posted an API key in the public channel, do I delete the message", "should_trigger": true },
{ "query": "Write the moderator agreement for our new volunteers", "should_trigger": true },
{ "query": "a suspension we handed out last year never actually ended and he's still locked out", "should_trigger": true },
{ "query": "How do we protect people who report things from blowback?", "should_trigger": true },
{ "query": "Should we start a Discord or a Slack for our users?", "should_trigger": false },
{ "query": "Which community platform is best for a developer tool?", "should_trigger": false },
{ "query": "How do we seed a brand-new community with founding members?", "should_trigger": false },
{ "query": "What go/no-go criteria should we set before launching a community?", "should_trigger": false },
{ "query": "When should we shut down a community that never took off?", "should_trigger": false },
{ "query": "How do we reach critical mass in the first 90 days?", "should_trigger": false },
{ "query": "Do we even need a community, or would office hours be cheaper?", "should_trigger": false },
{ "query": "How do we measure developer community health?", "should_trigger": false },
{ "query": "Is our Discord dying?", "should_trigger": false },
{ "query": "Build me a contributor funnel dashboard", "should_trigger": false },
{ "query": "Which community KPIs should we report to the board?", "should_trigger": false },
{ "query": "Why does our community feel so quiet lately?", "should_trigger": false },
{ "query": "Set baselines for our community engagement metrics", "should_trigger": false },
{ "query": "Design a label taxonomy for our GitHub issues", "should_trigger": false },
{ "query": "Should we run a stale bot on the repo?", "should_trigger": false },
{ "query": "We have 900 open issues and no triage process", "should_trigger": false },
{ "query": "Set up issue templates and forms for bug reports", "should_trigger": false },
{ "query": "Nobody reviews our pull request backlog", "should_trigger": false },
{ "query": "How do we assign a triage duty rotation?", "should_trigger": false },
{ "query": "Write a GOVERNANCE.md for our project", "should_trigger": false },
{ "query": "Who decides when maintainers disagree about technical direction?", "should_trigger": false },
{ "query": "How do we promote a contributor to maintainer?", "should_trigger": false },
{ "query": "We have a bus factor of one and it scares me", "should_trigger": false },
{ "query": "Should we donate the project to a foundation?", "should_trigger": false },
{ "query": "Our project is controlled by one vendor and contributors are uneasy", "should_trigger": false },
{ "query": "Write our CONTRIBUTING.md", "should_trigger": false },
{ "query": "Our good first issues get no takers", "should_trigger": false },
{ "query": "First-time contributors disappear after one merged PR", "should_trigger": false },
{ "query": "Make our clone-to-passing-tests path work on a cold machine", "should_trigger": false },
{ "query": "Design an ambassador program for our community", "should_trigger": false },
{ "query": "What perks should our community champions get?", "should_trigger": false },
{ "query": "How do we recognise our top community members?", "should_trigger": false },
{ "query": "Our MVP-style recognition program went quiet, how do we restart it?", "should_trigger": false },
{ "query": "How do we find speakers for our monthly meetup?", "should_trigger": false },
{ "query": "Our meetup attendance is dying", "should_trigger": false },
{ "query": "Find us a venue and a pizza sponsor for the user group", "should_trigger": false },
{ "query": "Write the code of conduct for our one-day conference next month", "should_trigger": false },
{ "query": "How do we staff on-site incident response at our conference?", "should_trigger": false },
{ "query": "How many volunteers do we need at the registration desk?", "should_trigger": false },
{ "query": "Build a Discord bot that auto-deletes link posts", "should_trigger": false },
{ "query": "Write a Python script to bulk-delete spam messages in our Discord", "should_trigger": false },
{ "query": "Write a JavaScript bot that mutes anyone posting more than 5 messages a minute", "should_trigger": false },
{ "query": "Train a content moderation classifier for user-uploaded images", "should_trigger": false },
{ "query": "Run a trust and safety review of our consumer app's feed ranking", "should_trigger": false },
{ "query": "Write our employee harassment policy for the HR handbook", "should_trigger": false },
{ "query": "Draft an employment contract clause about workplace conduct", "should_trigger": false },
{ "query": "How do I run a performance improvement plan for an underperforming engineer?", "should_trigger": false },
{ "query": "Write our privacy policy and cookie banner copy", "should_trigger": false },
{ "query": "What's our GDPR data retention policy for customer accounts?", "should_trigger": false },
{ "query": "Choose an open-source license for our new library", "should_trigger": false },
{ "query": "Do we need a CLA or a DCO?", "should_trigger": false },
{ "query": "Write a security vulnerability disclosure policy with a PGP key", "should_trigger": false },
{ "query": "Set up a bug bounty program and decide the payout tiers", "should_trigger": false },
{ "query": "How do we grow our subreddit's subscriber count?", "should_trigger": false },
{ "query": "Write social posts promoting our community events", "should_trigger": false },
{ "query": "Plan a community marketing campaign for launch week", "should_trigger": false },
{ "query": "Optimize my GitHub profile README", "should_trigger": false },
{ "query": "Write the release notes for v3.0", "should_trigger": false },
{ "query": "Our docs are badly structured, audit the information architecture", "should_trigger": false },
{ "query": "Write a quickstart guide for our SDK", "should_trigger": false },
{ "query": "How should we price our developer tool?", "should_trigger": false },
{ "query": "Design our devrel team structure and headcount plan", "should_trigger": false },
{ "query": "What should a developer advocate interview loop look like?", "should_trigger": false },
{ "query": "Build a devrel content calendar for Q3", "should_trigger": false },
{ "query": "How should we split the devrel budget between conferences and content?", "should_trigger": false },
{ "query": "Which conferences should we submit talks to this year?", "should_trigger": false },
{ "query": "Review my CFP abstract before I submit it", "should_trigger": false },
{ "query": "Write a case study about a customer using our API", "should_trigger": false },
{ "query": "Set up rate limiting on our public API endpoints", "should_trigger": false },
{ "query": "Design an escalation policy for our on-call rotation", "should_trigger": false },
{ "query": "Write our incident response runbook for production outages", "should_trigger": false },
{ "query": "Write the judging rules for our hackathon", "should_trigger": false }
]
}
references/code-of-conduct-outline.md›
# Code of conduct outline
Contents: base-document versions · document skeleton · scope wording · enforcement ladder · reporting section · worked example pair.
## Which base document, and which version
The Contributor Covenant is the most adopted base (40,000+ projects per opensource.guide); the Django code of conduct is the other common one. The Covenant's two live versions do not share section names, so state which one you are adapting.
| 2.1 | 3.0 |
| ------------------------------------------------------ | --------------------------------------------------- |
| Our Pledge | Our Pledge |
| Our Standards (expected + unacceptable in one section) | Encouraged Behaviors / Restricted Behaviors (split) |
| Enforcement Responsibilities | folded into the moderator role |
| Scope | Scope |
| Enforcement | Reporting an Issue |
| Enforcement Guidelines | Addressing and Repairing Harm |
| - | Other Restrictions |
"Community leaders" (2.1) becomes "Community Moderators" (3.0); both versions invite you to rename the role and rewrite the enforcement section. Prefer 3.0 for a new document: it drops 2.1's "a public apology may be requested" line, which a committee should never act on.
## Document skeleton
Write these six sections, in this order. The order matters: a reader who stops after three sections must already know what is expected, who enforces it, and where it applies.
1. **Pledge** - what experience the community commits to, and for whom. Two to four sentences.
2. **Standards** - expected behaviour and unacceptable behaviour, both as concrete examples drawn from what actually happens in this community. Generic lists ("be respectful") give a moderator nothing to point at. Do not include "assume good intent": it moves every discussion onto what someone meant rather than what happened, and anyone acting in bad faith only has to say "I meant well" to reset the conversation (Frame Shift Consulting, "Why 'Assume Good Intent' Backfires", 2022).
3. **Enforcement responsibilities** - who may remove content, mute, suspend, and ban; and what they owe in return (consistency, privacy, explanation).
4. **Scope** - surfaces, people, and the off-platform stance (below).
5. **Reporting** - channels, privacy promise, response target, no-retaliation rule.
6. **Enforcement guidelines** - the ladder, with each rung's trigger and consequence.
Base documents worth adapting instead of writing from scratch: the Contributor Covenant (this skeleton is its structure) and the Django code of conduct. Adapting the text is expected - rewrite the enforcement section so it describes the procedure the community will really follow, and rename "community leaders" to the role title that actually exists here.
## Scope wording
The scope clause has to answer three questions explicitly:
- **Which surfaces**: name them one by one - repository and issue tracker, pull request reviews, chat server, forum, mailing list, project social accounts, in-person and virtual events, private messages between members that start in a community space.
- **Which people**: members, contributors, maintainers, employees of a sponsoring company, sponsors, speakers, event staff and vendors.
- **Off-platform conduct**: pick one stance and write it down. Either (a) it violates the code only when the person is representing the community, or (b) it is in scope when it credibly bears on member safety inside the community. Leaving this blank guarantees an argument during the first hard case.
When several bodies exist (a project, a foundation, an events arm), write the jurisdiction split too: which body handles which kind of report, and who decides when the answer is unclear.
## Enforcement ladder
Publish the trigger and the consequence for each rung. A consequence list without triggers reads as arbitrary; triggers without consequences give reporters nothing to expect.
| Rung | Trigger | Consequence |
| ----------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1. Correction | Unprofessional or unwelcome behaviour, first occurrence | Private written notice naming the behaviour and the expected change |
| 2. Warning | A violation, single incident or a pattern | Formal warning with stated consequences; no unsolicited contact with the affected parties for a stated period |
| 3. Temporary suspension | Serious violation, or sustained behaviour after a warning | Time-boxed removal from interaction and public communication - state the length (Django's published bands: 30-90 days short, 90+ days extended with conditions on return - one project's choice, not a norm) |
| 4. Permanent ban | Pattern of violation, sustained harassment, or aggression | Permanent removal from public interaction in the community |
Non-ladder outcomes to keep available, because most reports do not end in a ban. Listed here in the order SKILL.md ranks them (recurrence prevented per unit of moderator hours and relationship cost) - that section carries the axes, the ties and the condition that promotes mentoring; do not re-derive a second order here:
- A systemic fix - a rule change, a template change, a channel change - when the incident's root cause is structural.
- Removal of the harmful content, with or without a sanction on the author.
- Removal from a leadership or maintainer role while keeping membership.
- A public statement of what the response would have been, when the account is gone or unidentifiable.
- Education or mentoring for a well-meaning repeat offender.
Outside that ranking: "no violation found" is a finding, not an outcome to choose - say so plainly to both parties whenever it is true.
The ranking governs only cases where a moderator has a real choice. Where the breach is serious, the ladder above is a gate and severity picks the rung.
Django's manual lists facilitated communication between the parties, with everyone's consent, as an available outcome. Aurora and Gardiner argue against ever mediating, because it reframes a safety problem as a personal disagreement and lets the team avoid deciding. This skill follows Django's model: facilitated communication is permitted, but only as an add-on after a decision has been made, and only with everyone's informed consent - never as a substitute for a decision, and never the response offered to a harmed person.
Rules that hold across every rung:
- Send corrections privately, but do not let the community conclude that nothing happened - people who witnessed the violation should learn that it was answered, and aggregate statistics go out on a cadence.
- State the end date of any time-boxed sanction and schedule the restoration.
- Move up the ladder on repeat offences, which only works if the case record exists.
- Choose the smallest rung that protects the community - smallest _sufficient_, judged against the breach and never against what it would cost the team to enforce: a ladder that always ends in a ban suppresses reporting, one that never gets past a warning deters nobody.
## Reporting section
Include all five, or the section is decorative:
1. A private channel that is not a public issue tracker (an alias such as `conduct@…` is the common form), with the people behind the alias listed by name - reporters who can see who reads the mail are likelier to send it.
2. A second path for a report **about** the primary recipient - a named alternate, a board, or a fiscal host.
3. Whether anonymous reports are accepted and how to file one.
4. The acknowledgment target ("within one business day", "within three business days") - a number the team can actually hold.
5. A no-retaliation statement, saying that retaliation against a good-faith reporter is itself a violation.
## Worked example pair
**Weak (what most projects ship):**
> Be respectful. Harassment will not be tolerated. Violations may result in a ban. Contact the maintainers if you have a problem.
Four defects: no scope, so nobody knows whether it covers the Discord; no named channel, so "the maintainers" means the person you are reporting; no ladder, so every case is decided from scratch; no timeline, so a reporter has no idea whether silence means "in progress" or "ignored".
**Workable (same length budget, filled in):**
> **Scope.** This code applies to the repository, the issue tracker, the community chat, project social accounts, and any event the project runs. It covers members, maintainers, and sponsor staff. Conduct outside these spaces is in scope when it credibly affects a member's safety inside them.
>
> **Reporting.** Email `[email protected]`, which reaches the three-person response team. To report a member of that team, email `[email protected]` instead. Anonymous reports are accepted through the form at `example.org/report`. We acknowledge every report within one business day and never disclose a reporter's identity to the person reported. Retaliation against someone who reports in good faith is itself a violation.
>
> **Consequences.** Correction (private notice) → warning (with a no-contact period) → temporary suspension (30-90 days) → permanent ban. We publish aggregate statistics twice a year and never discuss individual cases publicly.
The second version is enforceable because each sentence names a person, a place, or a number.
references/incident-response-runbook.md›
# Incident response runbook
Contents: runbook template · deadline clock · intake · report-taking checklist · recusal · decision · notification templates · negative example · closure · case record · transparency report.
Produce this as a private document for the response team - separate from the public code of conduct, which only summarizes it. Publish a reporter-facing "what to expect when you report" page instead of the playbook itself, and say in it that internal guidelines exist and change. A published step-by-step procedure gets used to argue that the team failed to follow its own process, which is a cheap way to stall any enforcement action.
## Table of Contents
- [Runbook template](#runbook-template)
- [Team](#team)
- [Intake](#intake)
- [Handling](#handling)
- [Outcomes](#outcomes)
- [Communication](#communication)
- [Records](#records)
- [Review](#review)
- [Deadline clock](#deadline-clock)
- [Intake](#intake)
- [Taking a report in person or in chat](#taking-a-report-in-person-or-in-chat)
- [Recusal](#recusal)
- [Investigation and decision](#investigation-and-decision)
- [Notification templates](#notification-templates)
- [Case record](#case-record)
- [Transparency without exposure](#transparency-without-exposure)
## Runbook template
```
# <Community> conduct response runbook
## Team
Members, terms, contact alias, escalation body above the team.
## Intake
Channels, anonymous path, alternate path, acknowledgment target.
## Handling
Recusal rules, evidence collection, interview order, decision rule.
## Outcomes
The ladder, the non-ladder outcomes, who executes each action on each platform.
## Communication
Templates: acknowledgment, reported-person notice, reporter closure, team-internal note.
## Records
Where cases live, who has access, retention period, what is deleted when.
## Review
Statistics cadence, transparency report cadence, ladder review trigger.
```
## Deadline clock
The clock starts when the team receives the report, not when it starts working. Write the two deadlines into the case record immediately and put them in calendars: acknowledgment (published bands in use: one business day at Django, three business days at CNCF) and decision (Aurora and Gardiner's worked example is 10 business days). This is the one commitment to hold literally - the dominant enforcement failure is a team that never quite decides, not a team that decides too fast.
For an incident many people witnessed, post a short holding note early: the team has the report, is working on it, and here is where to send more information. It also gives you somewhere to redirect the pile-on.
## Intake
- Acknowledge every report, including the ones filed only for the record. Send a lighter acknowledgment when the reporter says the incident is already resolved.
- Ask for: who was involved (name, handle, role, affiliation), what happened with dates and links, where it happened, the reporter's relation to the events, whether they want to remain anonymous, and whether anyone is in immediate danger.
- Safety first: if a report describes physical danger, point to local emergency services before anything procedural.
- Preserve evidence immediately. Chat messages disappear when deleted, so screenshot and archive before removing anything; forge comments keep an audit trail when hidden rather than deleted.
- Assign a random case code, and code names for the people involved, so the case can be discussed in team notes without identities.
## Taking a report in person or in chat
Give this to everyone likely to receive a report first-hand - event volunteers, channel moderators, maintainers. Adapted from Mary Gardiner and Valerie Aurora's report-taking checklist (CC BY-SA 4.0), so keep the attribution if you ship it as a handout.
1. Move somewhere others cannot overhear, and have somewhere to write.
2. Ask whether they want to make a formal report. Promise nothing on the team's behalf beyond doing its utmost to protect their confidentiality and safety. If you are legally obliged to report certain disclosures, say so before they start.
3. If they do not want to file, you may decline to hear it - particularly if you are already absorbing more than your share of this work.
4. Ask them to describe what happened: who the reported person is, their own name and contact, time, date, place, what occurred, who else was involved. Respect anything they will not share.
5. On any sign of immediate physical danger, act on the safety plan first and note that action in the report.
6. Offer concrete help for right now - fetching a friend, a private room, an escort out.
7. Thank them.
8. Send the report to the response team by the documented route.
Never:
- share it outside the team
- ask the reporter or the harmed person to propose the remedy
- push them toward police or medical help they have not asked for
Do not assume they trust you, or any given staff member, by default.
## Recusal
Members declare a conflict in writing as soon as they are involved in the incident, close to a party, share an employer, hold biasing private information, or simply cannot be impartial. Two grades, because treating them identically either paralyses a small team or lets a conflicted member vote:
- **Hard conflict** (accused, close personal or professional relationship, personal stake): excluded from discussion, from the vote, and from the confidential material.
- **Soft conflict** (same employer without a close relationship, appearance of conflict): may take part in discussion, may not vote.
Record the conflict and its grade in the case notes before the investigation starts. Recusal takes effect the moment the member realises it applies - including mid-read of the report - and someone else is assigned to execute it: remove them from the documents, open a channel without them. When every eligible member is conflicted, the case goes to the escalation body named in the runbook.
## Investigation and decision
1. Read the evidence before talking to anyone.
2. Interview the reporter, then witnesses, then the reported person. Take notes in neutral language.
3. Decide with a rule fixed in advance, covering ties and absences - a workable default for a small team is: at least two non-conflicted members must agree, consensus is the target, a two-thirds majority is the fallback, and an unresolvable case escalates. Pick a rule that leans toward acting: across observed cases the common error is taking no action or taking too long on a valid complaint, not overreacting.
Judge impact before intent. What did the behaviour do to the person and the room, how do you stop it recurring, what makes people safer now. Intent matters only as a predictor: someone who meant no harm _and_ recognises it, takes responsibility and changes is low risk; someone who meant no harm and refuses all three is not.
4. For severe or legally exposed cases, an external investigator or mediator is a legitimate option.
5. A team may open a case proactively when there is a serious ongoing safety risk and no formal report.
## Notification templates
Order: show the harmed person the proposed response privately first - to catch a fact you missed or a retaliation risk you did not see, not to ask permission - then notify the reported person, whose only required answer is whether they will comply. The decision takes effect immediately, even while an appeal is being considered.
**To the reported person** - four parts, in this order:
```
1. Behaviour: on <date>, in <space>, you <specific behaviour, neutral wording>.
2. Impact: this <effect on the affected person / on the community>.
3. Expected change: <specific, observable behaviour going forward>.
4. Consequence: <rung>, effective <date>, ending <date or "permanent">.
<How to respond, and to whom, if they believe this is factually wrong.>
```
Never name the reporter. Do not argue the case in this message; it states a decision that has already been made.
**To the reporter, before enacting the resolution:**
```
Thank you for the report (case <code>). We have reviewed it and propose <resolution>.
We are telling you before we act, and welcome your view - we are not bound to act on it,
and we will not share your identity with anyone outside the response team.
```
**To the reporter, at closure:**
```
Case <code> is now closed with <resolution, at the level of detail you can share>.
If new information comes to light, tell us and we will reopen it.
```
Detail limits: the reporter learns the outcome that affects them, not the full private correspondence with the reported person.
### Negative example: the conciliatory notice
Almost every first draft of a decision notice looks like this one, because it feels kind:
> Hi Sam - we've had a complaint about the thread in #core yesterday. I'm sure there was no bad intent on your side and it's probably a misunderstanding. Could you send an apology in the channel, and maybe the two of you could hop on a call with me to clear the air? In the meantime please just steer clear of Alex. Thanks for understanding!
Six defects, each one sourced to a documented failure:
1. **Prejudges intent** ("no bad intent") and volunteers the team's excuse before hearing anything - the discussion is now about Sam's feelings.
2. **Names the other party**, which identifies the reporter.
3. **Requests an apology**, destroying the only useful signal: whether Sam would have apologised unprompted.
4. **Proposes mediation in place of a decision**, before either party consented, reframing a conduct violation as two people who don't get along.
5. **Imposes a stay-away condition** instead of a decision, leaving the question of whether Sam is a risk unanswered.
6. **States no consequence, no date, no route to contest it** - so nothing is actually decided.
The same facts, written as a decision:
> Sam - on 12 May in #core you told Alex to "stop wasting everyone's time with beginner questions", and repeated it after another member asked you to stop. Newcomers stopped posting in that channel for the rest of the day.
>
> Going forward: no dismissive comments about another member's experience level, anywhere in the community.
>
> This is a formal warning under the code of conduct, effective today, recorded in our case log. A further incident moves to a temporary suspension. If you believe the facts above are wrong, reply to [email protected] within 14 days and the team will review; the warning stands while we do.
It names the behaviour, the impact, the change, and the consequence - and it takes four sentences.
## Case record
One record per case, with these fields, kept where only the response team can read it:
`case_code` · `report_date` · `surface` · `person_codes` · `neutral_summary` · `scope_determination` (in scope / out of scope / other body) · `safety_risk` · `harassment_risk` · `conflicts_declared` · `investigation_notes` · `decision` · `decision_rule_met` · `rung_applied` · `effective_date` · `end_date` · `communications_sent` · `closure_date` · `follow_up`
Retain under the organization's data-retention policy and applicable privacy law. Restrict access to the team, and treat leaking a case as grounds for removal from the team. Keep prior violations findable - the ladder is meaningless if nobody can tell that this is the third warning.
Schedule the restoration of every time-boxed sanction the day it is applied. Suspensions that outlive their stated end date are one of the fastest ways to lose the community's trust in the process.
## Transparency without exposure
- Publish a faithful reporter-facing summary of the process - what to expect, in what order, by when. Process transparency costs nothing and is what makes reporting feel safe. Keep the operational playbook internal and revisable.
- Everyone who witnessed a violation should learn that it was answered. A case handled entirely in private messages leaves the room believing nothing happened, and that belief is what makes people leave.
- Publish aggregate statistics on a fixed cadence - every six months is a proven rhythm - and an annual anonymized trends report.
- Never discuss an individual case publicly. When a public statement is unavoidable, it comes from the escalation body, not from the response team.
- Default to describing the behaviour without naming the person: a statement from the team carries far more weight than the same words from a member, and naming is often read as disproportionate whatever the facts. Name someone only when people need it to stay safe - a known repeat offender attending an event. Decide the stance in advance; an ad-hoc decision under pressure is not defensible.
references/platform-controls.md›
# Platform controls and volume defenses
Contents: venue classes · earned trust · rate limits · content actions · volume attacks · moderator roster.
## Match the control to the venue class
Write the playbook against the class, then note the current feature names for the venue actually in use - vendors rename these controls often, so verify on the platform's own moderation documentation before publishing a runbook that depends on them.
| Venue class | Controls it gives a moderator | What it does not give |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Async forum (self-hosted or hosted) | Earned trust levels, member flagging with auto-hide thresholds, post edit/hide history, category permissions | Instant reach - a bad post can sit for hours |
| Forge-native (issues, pull requests, discussions) | Temporary interaction limits, per-user open-PR caps, comment hiding with a stated reason, comment editing for redaction, conversation locking, blocking | Chat-speed presence, and any control over off-forge spillover |
| Real-time chat | Keyword and spam filters with automatic actions (block message, alert a private channel, time out the member), entry gates, role-based channel access, slow mode | A durable public record - deleted messages are gone unless archived |
| Rented public space (subreddit, Q&A site, ecosystem-wide chat) | Reporting to the host, muting a thread, moving the conversation to an owned surface | Any authority of your own: the host's rules outrank your code of conduct and you cannot ban anyone |
## Earned trust beats appointed authority
Mature forum software promotes members automatically as they read, post, and receive likes, and hands each level more moderation weight. A flag from a high-trust member can hide a new member's post immediately, while flags from the top level take effect at once. The generalizable pattern: let the membership carry the first moderation layer and have humans review after the fact, instead of gating every post through a small team that cannot scale.
Mirror it manually where the platform has no trust system: a "regular" role granted after a visible track record, with the power to flag and to move threads but not to ban.
## Rate limits are the answer to floods
Individual bans answer individual behaviour. A raid, a brigading wave, or a spam campaign is a volume problem, and banning accounts one at a time just burns the team's hours.
Forge-native limits worth pre-configuring so they can be switched on in seconds:
- Interaction limits in three tiers - new accounts (under 24 hours old with no prior contribution), non-contributors, or non-collaborators - applied for a fixed window (24 hours, 3 days, 1 week, 1 month, 6 months) at repository, account, or organization level. They block commenting, opening issues and pull requests, reactions, and edits.
- A cap on concurrent open pull requests from users without write access, with a bypass list for trusted contributors.
Chat equivalents: slow mode, entry gates (rules acceptance, account-age or email verification, onboarding questions), and automatic filters. Entry gates cost real join conversion - decide that trade deliberately rather than discovering it after a raid.
## Content actions, in order of reversibility
Deliberately not ranked by efficiency: these four are not four ways to reach one outcome, they are four different situations. A leaked API key needs a redaction and a thread nobody can stop needs a lock, and no ratio converts one into the other. Reversibility is the axis that actually decides between them, so it is the only order given here.
1. **Hide/minimize with a stated reason** - the audit trail stays, the reader sees that a moderator acted and why.
2. **Edit to redact** - for leaked secrets or personal data; replace the content with a redaction marker and add a note saying a moderator edited it.
3. **Lock the conversation** - when the thread, not a person, is the problem.
4. **Delete** - last resort. It erases the evidence and the community's ability to check the moderator, so record the content in the case file first.
## Volume attacks of low-quality submissions
Automated and AI-assisted submissions have made "sincere but worthless" a category of its own. The behaviour ladder handles it badly: there is usually no malice to escalate against, and banning individuals does nothing to the inflow rate.
What is measured, with sources:
- **curl** (Daniel Stenberg, "Death by a thousand slops", 2025-07): about 20% of the year's bug-bounty submissions were AI-generated junk, roughly two per week; each report cost the seven-person security team 30 minutes to 3 hours and pulled in three to four people. In one early-July sample only 5% of submissions were genuine. On 2026-01-31 curl ended the bounty entirely - the confirmed-vulnerability rate had fallen from historically above 15% to below 5%, and Stenberg described the inflow as "effectively being DDoSed".
- **Node.js** now requires a HackerOne Signal score of 1.0 to submit, after one month brought "over 30 reports" against a usual 6-7.
- **OpenSSF**'s working-group issue on the problem records that there is "no reliable technical indicator for AI-generated content" - detection runs on maintainer intuition. So gate volume; do not try to detect authorship.
Countermeasures that fit the shape, ranked by inflow removed per hour of maintainer time:
- efficiency: reputation or contribution gate > review-effort cap > raising the submission cost > disclosure rule
- effort: review-effort cap == disclosure rule (one paragraph each, in the template and the policy) > reputation gate (pick a floor, change one setting) > raising the submission cost (redesigning what a submission must contain, and removing a reward is a decision with its own politics)
- value: reputation gate (cuts inflow itself - Node.js's Signal-score floor pulled "over 30 reports" back toward the usual 6-7) > raising the submission cost (removes the incentive being farmed, which is what curl finally did) > review-effort cap (protects reviewers without lowering the rate) > disclosure rule (changes nothing alone; it gives the other three a line to point at)
- compliance cost: review-effort cap == reputation gate (platform-native, and neither makes a claim about any person) > disclosure rule (once published it must be enforced evenly, including against people you like) > raising the submission cost (a refundable fee touches payments, and withdrawing a bounty breaks a promise made to existing participants)
The effort tie is real: both the cap and the disclosure rule are single paragraphs written once. The compliance tie holds because neither the cap nor the gate stores anything new or accuses anyone of anything.
1. **Gate on reputation or contribution history** rather than on suspected authorship - a platform reputation score, an account-age floor, prior-contributor requirements.
2. **Cap review effort per submission** and close on a standard template when the cap is hit.
3. **Raise the submission cost** where an incentive is being farmed: required reproduction steps, proof-of-concept artifacts, a refundable fee - or removing the monetary reward, which is what curl ultimately did.
4. **Publish a disclosure rule for AI-assisted submissions** and enforce it on the submission's content, not on suspicion - accusing a member of using a language model without proof creates its own incident.
Efficiency starves option 3: it is the highest-value entry and the one that costs the most political capital, because withdrawing a reward means telling a real audience their reward is gone. Promote it once the gate is in place and the valid share is still falling - curl's own sequence. Re-rank all four against the community's own shape: a project with no bounty has nothing to withdraw and should delete option 3 rather than carry it, and a forge with no reputation signal has no option 1.
Measurement is not a countermeasure and does not compete with them: track submissions per week and valid share regardless of which you pick, because the rate is the only thing that says whether any of it worked.
## Moderator roster
- Recruit from observed behaviour in the room - the people already answering newcomers and de-escalating - not from seniority or job title.
- Cover the hours and the languages the community actually posts in; a single-timezone roster means unmoderated hours.
- Grant powers in tiers: remove a post → time out → temporary ban → permanent ban, with the top rung reserved for the response team.
- Give each moderator a written agreement: powers, confidentiality, recusal duty, what to escalate instead of deciding alone, and how to step down without drama.
- Run a private moderator channel for calibration - decisions made alone drift apart quickly - and rotate duty with a per-person weekly cap. Burnout, taking abuse personally, and isolation are the standard failure modes, and rotation plus visible team support is the standard mitigation.
- For a body that decides sanctions, borrow the structure large foundations use: a few elected members plus alternates, fixed terms, a cap on how many seats one employer may hold, and eligibility rules (no recent violation of their own). Practitioner sizing guidance is 3-6 members, chosen so the body still functions with about a third of it unavailable - a two-person team is one holiday away from having no quorum.
- List the deciding members by name wherever reports are solicited. Many people doubt a report will be taken seriously, and knowing who will read it is what changes their mind.
- Rehearse. Run the team through practice cases on a cadence - yearly, when someone joins, or before a large event - and use real published incident write-ups rather than invented ones where you can. Deciding fast under pressure is a trained reflex.
references/published-findings.md›
# Published findings
Contents: sourced claims · sourced numbers · self-set baselines · known disagreements · scope limitations.
Every figure and rule this skill states, with where it came from and what it does not prove. Read this before quoting a number to a user as an industry standard - most of them are one community's published choice, not a distribution.
## Sourced claims
| Claim | Source |
| -------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| An unenforceable code of conduct is worse than none | opensource.guide, code-of-conduct page |
| A community must not adopt a code of conduct that will not apply to its most powerful people | Valerie Aurora & Mary Gardiner, _How to Respond to Code of Conduct Reports_, Frame Shift Consulting, v1.1 (2019), ISBN 9781386922575, CC BY-SA 4.0 |
| Enforcement must be visible; private-only handling reads as no enforcement | same book, "Visible enforcement is required" (with a case study of a target who left believing nothing happened) |
| Never compel an apology, never mediate, never make the harmed person set the consequence, never impose a stay-away condition instead of a decision | same book, "Responses not to use" |
| Show the harmed person the proposed response before announcing it - to find missed facts, not to seek approval | same book, "Do not ask the target to decide the response" |
| Judge impact over intent; intent survives only as a risk predictor | same book, "Impact is more important than intent" |
| Choose the minimum response that protects the community; a committee's statement carries amplified weight, so usually do not name the person | same book, "Choosing a proportional response" |
| Publish a reporter-facing summary, keep the operational guide internal | same book, "Adopting an incident response guide" |
| "Assume good intent" backfires: it centres intentions over effects and gives bad actors a reset button | Frame Shift Consulting, Maile Colton, "Why 'Assume Good Intent' Backfires", 2022-07-25 |
| Off-platform conduct is out of scope unless the person represents the community officially - but may still bear on safety inside it | Contributor Covenant FAQ |
| A community can act inside its own spaces on evidence from outside them | Aurora & Gardiner, "Codes of conduct govern community spaces" |
| Rate limits, not individual bans, are the answer to a flood | GitHub interaction-limit documentation; curl's and Node.js's own responses |
| No reliable technical indicator exists for AI-generated submissions | OpenSSF `wg-vulnerability-disclosures#178` |
## Sourced numbers
| Number | What it actually is | Source |
| ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Four ladder rungs | The shape both Contributor Covenant 2.1 and 3.0 publish; 3.0 renames them (Warning / Temporarily Limited Activities / Temporary Suspension / Permanent Ban) | contributor-covenant.org versions 2.1 and 3.0 |
| 30-90 days short suspension, 90+ days extended | Django's published bands, not a norm | Django code-of-conduct working-group manual |
| Acknowledge "ideally within a day" | Django's own target | same manual |
| Acknowledge within three business days | CNCF's published promise | CNCF code of conduct + incident-resolution procedures |
| 24h acknowledgement, 10 business days to decision | One worked example in a handbook, offered as an illustration | Aurora & Gardiner |
| Response team of 3-6 people, sized to survive a third being unavailable | Practitioner guidance | Aurora & Gardiner, "The code of conduct committee" |
| 3 elected + 2 appointed members, 2-year terms, max 2 of 6 seats per company, 18-month clean-record eligibility, removal after 6 months inactive | One foundation's committee charter | CNCF code-of-conduct committee charter |
| Consensus target, two-thirds fallback, escalate to the board | Django's decision rule | Django manual |
| Statistics every six months, annual anonymized trends report | Django's cadence | Django manual |
| Discourse trust levels 0-4 and their thresholds (30 posts read, 100 days, etc.) | One forum product's defaults | blog.discourse.org, "Understanding Discourse Trust Levels" |
| Interaction limits in three tiers for 24h / 3d / 1w / 1m / 6mo | GitHub's feature set | GitHub docs on limiting interactions |
| ~20% of curl's 2025 bug-bounty submissions were AI slop; 5% genuine in one sample; 30 min-3h and 3-4 people per report; bounty closed 2026-01-31 | One project's measurement of one programme | daniel.haxx.se, "Death by a thousand slops" (2025-07) and the 2026-01 shutdown post |
| Node.js requires HackerOne Signal 1.0 after 30+ reports in a month against a usual 6-7 | One project's gate | nodejs.org security announcement |
| 40,000+ projects use the Contributor Covenant | Adoption count cited by opensource.guide | opensource.guide |
## Self-set baselines
State these as this skill's starting gates, never as benchmarks:
- **95% of reports acknowledged inside the published window.** A design gate; recalibrate it from the team's first quarter.
- **100% of cases carrying a recorded outcome.** A design gate, chosen because the ladder cannot be applied consistently without it.
- **The eleven-item Publish gate.** Item 1 states Aurora & Gardiner's rule that a code must apply to a community's most powerful people; the rest are self-set.
- **Hard versus soft recusal grades.** The two-grade split is adapted from CNCF's hard/soft conflict distinction; CNCF applies it to a committee vote, this skill generalises it to any small team.
- **The five operating metrics** and the "read repeat-violation rate next to report volume" caution.
- **The weak/workable code-of-conduct pair and the conciliatory-notice negative example.** Illustrations rather than observed cases; each defect they show is one a published source names.
## Known disagreements between sources
- **Mediation.** Django's manual offers facilitated communication with everyone's consent; Aurora & Gardiner rule mediation out entirely. Both are practitioner-authored. This skill follows Django's model, permitting consented facilitated communication as an add-on after a decision, never as a substitute for one.
- **Public apologies.** Contributor Covenant 2.1's first rung says one "may be requested"; Aurora & Gardiner say never. Contributor Covenant 3.0 drops the line, which resolves the conflict in the stricter direction.
- **Private versus visible.** Template codes say "correct privately"; the handbook says invisible enforcement is not enforcement. Reconciled here as: private notification, visible fact of response, aggregate publication.
## Scope limitations
Read every target in this skill as one community's published choice or a baseline set here, never as a percentile of report volume, resolution time or repeat-violation rate across communities. Real-time chat moderation features are described generically because feature names and availability change across platforms; verify them on the platform's own documentation before writing them into a runbook.
SKILL.md›
---
name: developer-community-moderation
description: Writes a developer community's code of conduct and the moderation playbook behind it - scope, enforcement ladder, reporting channels, incident-response runbook, moderator roster, platform controls. Use whenever the user mentions a code of conduct, CODE_OF_CONDUCT.md, community moderation, moderator recruitment, an escalation ladder, banning or suspending a member, harassment, trolls, brigading, spam or AI-slop floods, or a conduct report they need to handle - including vaguer phrasings like "our Discord is getting out of hand", "we need community rules", or "someone reported a maintainer". Covers company-run and volunteer open-source communities. Do NOT use to pick the platform - use samber/developer-relations-skills@developer-community-launch.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Developer Community Moderation
You are a community operations lead who writes behavioural policy that a small, tired team can actually execute. Your deliverables are a published code of conduct and the private runbook that makes it real.
One rule organises everything below: "a code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all" (opensource.guide). So never ship the document alone - ship the process, the people, and the platform controls that make it true.
The hardest instance of that rule comes from the only book-length practitioner handbook on enforcement - Valerie Aurora and Mary Gardiner, _How to Respond to Code of Conduct Reports_ (Frame Shift Consulting, 2019): a community "must not adopt a code of conduct if it will not apply to the most powerful people" in it. Never ship one the founders are exempt from.
## Detect the request first
Decide which of four jobs is in front of you before interviewing - each has a different first move.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. **Live incident in progress** - someone is being harmed right now. Skip document work. Go to [references/incident-response-runbook.md](./references/incident-response-runbook.md), stabilize (check everyone is safe, preserve evidence, use the platform control that stops the harm, acknowledge the reporter), and write policy afterwards from what the case exposed.
2. **No code of conduct yet** - run the full workflow below.
3. **A code of conduct exists but is unenforceable** - audit it against the Publish gate, then fix only what fails. Do not rewrite a document the community already knows.
4. **Moderation exists, structure does not** - the team is improvising. Start at step 6 (channels) and step 7 (team), and write the ladder from the decisions they have already been making.
## Interview
Ask one question at a time, offer choices where you can, and stop as soon as you can write the policy. Questions 2 and 3 decide whether and what you may draft - get both answered before drafting anything.
1. Which surfaces should this cover - repository and issues, chat, forum, mailing list, project social accounts, in-person or virtual events?
2. Is there an entity behind the community - a company, a foundation or fiscal host, or nothing but volunteers? What body sits above the moderators when they deadlock or when someone contests a decision?
3. Would the policy be enforced against the founder, the top maintainer, or the biggest customer? If not, say so now.
4. Who moderates today, and what is the effort ceiling: how many people, how many hours a week each, and whether anyone has authority to change platform settings or spend money?
5. Is there a date this has to be in place by - a live case running right now, a launch, an event, a board or foundation deadline?
6. Do you want this case closed, or a structure that keeps working after the people who wrote it leave?
7. Roughly how many members, and what is the daily volume of messages, issues, and new joiners?
8. Is there an existing code of conduct or set of rules? Was there an incident handled badly enough that members still remember it?
9. Which problems are actually frequent right now: harassment, self-promotion spam, low-quality or AI-generated submission floods, off-topic drift, hostile technical arguments, brigading from outside?
10. Are members mostly employed developers using this for work, or individuals on their own time? Any minors, any customers under contract, any competitors in the room?
11. Constraints: languages and timezones to cover, privacy law that governs the records, and whether anonymous reporting must be possible?
If the user cannot answer 2, that gap _is_ the finding - name it and design around it before writing a single rule. If the answer to 3 is no, say plainly that the honest options are to fix the exemption or to publish community guidelines without conduct-enforcement language, and let the user choose.
Answers to 4, 5 and 6 re-rank the ranked menus below, and say which moved what:
- A live case or a hard date promotes the responses that stop harm today - platform controls, content removal, the reporting channel - and defers the structural work that only pays off later.
- A "keep working after we leave" answer promotes the systemic fix and earned trust levels, both of which lose on ratio in any single case and win across a year of them.
- A low effort ceiling deletes rungs and deliverables outright rather than parking them at the bottom, and shortens the published ladder to what the team can actually execute (Publish gate, item 11).
## Workflow
1. **Map scope and jurisdiction.** List the surfaces and the categories of people covered, and pick an explicit stance on off-platform conduct. A community can only enforce inside spaces it controls, but it can act inside those spaces on evidence from outside them. When several bodies exist (project, foundation, events arm), write which one handles which report.
2. **Choose a base document and adapt it.** Start from an established public code of conduct rather than inventing prose; rewrite its enforcement section to describe the procedure this community will really follow, and rename its role titles to titles that exist here. Check which version you are copying - the section names changed between Contributor Covenant 2.1 and 3.0. See [references/code-of-conduct-outline.md](./references/code-of-conduct-outline.md).
3. **Write the standards from real incidents.** Replace generic virtue lists with the behaviours this community has actually seen, on both sides. A moderator needs a line they can point at. Leave "assume good intent" out of the standards list - it hands anyone who caused harm a way to redirect the conversation to their own intentions (Frame Shift Consulting, 2022).
4. **Design the ladder.** Four rungs is the shape both published versions of the Contributor Covenant use - correction/warning, warning/limited activities, temporary suspension with a stated duration, permanent ban - plus the non-ladder outcomes most cases really need (no violation found, content removal, role removal, mentoring, a systemic fix). Publish trigger and consequence for each rung, and choose the minimum response that protects the community, not the maximum the rung allows. The ladder itself is a gate, not a menu - see The ladder is a gate, the outcomes are a menu.
5. **Decide what becomes visible.** Notify privately; enforce visibly - the two rules govern different things. The person hears the decision in a private notice, everyone who witnessed the violation sees that the community answered it, and aggregate statistics go out on a cadence. Invisible enforcement reads as no enforcement - Aurora and Gardiner's case study is a harassment target who left believing nothing had happened.
6. **Build the reporting channels.** People report more when they know who reads it:
- a private primary channel
- a second path for reports _about_ the primary recipient
- an anonymous option if feasible
- a stated acknowledgment target you can hold
- a no-retaliation rule
- the names of the people who receive reports
7. **Staff the team.** Separate day-to-day moderators from the body that decides sanctions. Size the deciding body so it still works when a third of it is unavailable, then set:
- tiered powers
- recusal duties
- a per-person load cap
- coverage across the community's real hours and languages
- terms with a cap on seats from any single employer
See [references/platform-controls.md](./references/platform-controls.md).
8. **Write the runbook.** Keep it private; publish a "what to expect when you report" summary instead of the internal playbook, so nobody can litigate whether the team followed its own steps. Cover:
- deadline clock, intake, evidence preservation
- recusal grades, interview order, decision rule
- notification templates, case-record schema, retention
See [references/incident-response-runbook.md](./references/incident-response-runbook.md).
9. **Pre-configure platform controls.** Trust levels or an earned-role equivalent, rate and interaction limits ready to switch on, automatic filters, entry gates, and the content actions ranked by reversibility. Include the volume-attack defenses if floods are among the frequent problems. Rank the controls by inflow stopped per moderator hour, not by how quickly each can be switched on:
- efficiency: rate and interaction limits > entry gates > earned trust levels > automatic filters > individual bans > manual triage of every item
- effort: rate limits == automatic filters (one config change, then self-running) > entry gates (one config change, plus a join-conversion cost you keep paying) > earned trust levels (a week to design, then self-running) > individual bans (minutes each, forever, scaling with whoever is attacking) > manual triage (a standing job that grows with the community)
- value: earned trust levels (raise the floor under every future member, permanently) > rate limits and entry gates (cut inflow at the source) > automatic filters (catch known patterns only, and never the new one) > individual bans (remove one actor, who returns under a new account) > manual triage (resolves each item and prevents none)
- compliance cost: rate limits == automatic filters == trust levels (platform-native, collecting nothing new) > entry gates (email or identity verification collects personal data and can need a privacy notice, more so where minors are plausibly present) > individual bans (a conduct decision, so a case record and an appeal path)
- Rate limits and automatic filters tie on effort because each is a single settings change nobody has to maintain.
- The three-way compliance tie holds because none of the three stores anything the platform was not storing already.
- Efficiency starves earned trust levels - highest value, a week of design - so a team in the middle of a raid never builds them. Promote them the moment moderator load crosses the agreed cap, or after the community survives its second flood.
- Delete the controls the venue does not give you rather than listing them as future work: on a rented public space there are no rate limits, no trust levels and no ban, and the honest control sheet has two rows - report to the host, move the conversation to a surface you own.
10. **Publish, announce, rehearse.** Ship the document, announce it with the reasoning rather than as a legal notice, and walk the team through two invented cases - one easy, one where a moderator is the subject - before the first real one arrives. Repeat the rehearsal whenever a new member joins the team.
11. **Set the review loop.**
- Aggregate statistics on a fixed cadence.
- An annual anonymized trends report.
- A ladder review triggered by any case the team found hard to place.
12. **Persist the decisions.** If your environment has persistent memory, record these so later work in this community does not relitigate them:
- the scope stance
- the ladder
- the escalation body
- the response-time target
## The ladder is a gate, the outcomes are a menu
A serious code-of-conduct breach - harassment, threats, sustained targeting, anything where a person is being harmed right now - is a gate. The breach determines the rung, and no ratio gets a vote. A ban is not "expensive" and a warning is not "efficient": moderator hours are not the currency a harmed person is paying in.
Never let an effort argument buy down a severity-determined rung, and never present the ladder to a user as options to weigh.
Rank only where a moderator genuinely has a choice between responses that would each close the case: off-topic drift, self-promotion, a hostile technical argument, a first-occurrence lapse, a volume flood with no malice behind it. There, the non-ladder outcomes compete for the same scarce thing - moderator hours and the community's willingness to keep trusting the team. Rank them by recurrence prevented per unit of that:
- efficiency: systemic fix > content removal > role removal > public statement of the response that would have applied > mentoring
- effort: content removal == public statement (minutes, one moderator, no coordination) > systemic fix (a day to design one rule, template, or channel change) > role removal (a conversation plus a governance decision) > mentoring (a standing commitment across weeks, which can still fail)
- value: systemic fix (removes the class of incident, so every case it prevents afterwards is free) > role removal (removes the authority that made the behaviour harmful) > mentoring (keeps a genuinely well-meaning contributor - rare, and real) > content removal (resolves the visible instance and nothing structural) > public statement (tells the community the standard held)
- relationship cost: content removal == systemic fix (neither names a person, so neither spends any) > public statement (asserts a standard without naming anyone) > mentoring (spends a moderator's goodwill and hours, and the mentee's) > role removal (permanently changes someone's standing, and usually costs the community that person)
- compliance cost: systemic fix == content removal (no personal data, no decision about a person, no appeal) > public statement (a factual claim about an incident, so legal review once it names anything identifiable) > mentoring (a commitment the community can be held to) > role removal (a conduct decision: case record, right of appeal, and in a company-run community an HR and employment-law interface)
Two ties, both genuine:
- Content removal and a public statement cost the same effort because each is one person writing for a few minutes with nobody to consult.
- Content removal and a systemic fix cost the same relationship because neither one names anybody - that is exactly why they are the two a tired team should reach for first.
The order starves mentoring, which is highest on relationship investment and slowest to pay. It is never a substitute for a sanction when harm occurred. Promote mentoring anyway when three things hold together:
- the person is load-bearing for the project
- the behaviour is a skills gap rather than a values gap
- a specific moderator has volunteered the hours
This order is a default, not a law. Re-rank it against what the interview already told you:
- a volunteer project with no governance body cannot do role removal at all and should not list it
- a community whose frequent problem is submission floods gets almost everything from the systemic fix and nothing from the rest
- a company-run community with an HR interface can act on role removal in a week where a foundation takes a quarter
## Deliverables
- `CODE_OF_CONDUCT.md` - public, in the repository root or the platform's rules surface.
- **Conduct response runbook** - private, team-only, following the runbook template.
- **Public "what to expect when you report" page** - the reporter-facing summary of that runbook.
- **Moderator roster and agreement** - who holds which powers, coverage map, load cap, recusal and confidentiality duties.
- **Platform control sheet** - which control answers which situation, and who can apply it.
- **Announcement post** - what changed, why, where to report, what happens next.
Show each deliverable in sections and get the user's agreement on one before writing the next. A ladder they will not enforce is worse than no ladder, and that only surfaces when they read it back.
Write them in this order when the team cannot produce all six at once - reports protected per hour of writing, not shortest document first:
- efficiency: reporting channels (with named recipients and the alternate path) > enforcement ladder > `CODE_OF_CONDUCT.md` > platform control sheet > runbook > moderator roster and agreement > announcement post
- effort: reporting channels == announcement post (an hour each) > enforcement ladder (a session with the team over real past cases) > `CODE_OF_CONDUCT.md` (adapt a base document, then argue the standards) > platform control sheet (a day of clicking through settings and writing down what each one does) > moderator roster and agreement (weeks, because it needs people to say yes) > runbook (the longest document here, and the one nobody reads until a case arrives)
- value: reporting channels (nothing else in the list does anything until a report can reach someone) > enforcement ladder (turns each case from an argument into a lookup) > runbook (stops the delay that is the dominant enforcement error) > `CODE_OF_CONDUCT.md` (the public promise the rest makes true) > moderator roster (decides whether item 11 of the Publish gate can hold) > platform control sheet > announcement post
This is a write order, not a ship order: the Publish gate still requires all eleven items before anything goes out. The announcement post sits last on efficiency purely because it is worthless until there is something to announce, and it is genuinely cheap - write it in the same hour you ship.
## Invocation examples
Expect requests in roughly these shapes. Each one enters at a different point.
- _"We're 400 people on a chat server for our open-source project and it's getting nasty. Write us a code of conduct."_ → job 2, full workflow, chat-class platform controls.
- _"Someone just reported one of our maintainers to the maintainers' alias. What do we do?"_ → job 1, runbook first, then close the missing-alternate-channel gap that caused the awkwardness.
- _"We copied the Contributor Covenant two years ago and never used it. Is it any good?"_ → job 3, audit against the Publish gate, report pass/fail per item, fix only failures.
- _"Our issue tracker is drowning in AI-written bug reports."_ → job 4, but route to volume defenses rather than the behaviour ladder; there is usually no malice to escalate against.
Expected output shape for a full run - the last two sections are review output for the user, not shipped documents:
```
## Scope and jurisdiction
Surfaces · people covered · off-platform stance · which body handles what
## Enforcement ladder
Table: rung | trigger | consequence | who may apply it
Non-ladder outcomes available
## Reporting
Primary channel (named recipients) · alternate path · anonymous option
· acknowledgment target · no-retaliation clause
## Response team
Roster · powers per tier · coverage map · recusal rules · escalation body
## Runbook summary
Deadline clock · intake · investigation · decision rule · notification · records
## Platform controls
Control → situation → who applies it, per surface
## Publish gate
Each of the 11 items: pass / fail / how to fix
## Open questions for the user
```
## Community types that change the answer
Scope, ladder shape, reporting channels, records, and platform controls transfer unchanged across community types. Four things differ.
- **Company-run, professional audience.** Members are identifiable and often employed by customers or partners. Name the interface to HR and legal before an incident, decide who may speak publicly, and expect standing soft conflicts for every vendor employee on the response team. Sanctioning a paying customer's employee is a commercial decision as well as a conduct one - agree in advance who makes that call.
- **Company-run, individual developers.** Higher anonymity, more throwaway accounts, more raids. Weight entry gates and rate limits over identity-based measures, and check whether minors are plausibly present, which changes both moderation and data handling.
- **Volunteer open-source project.** There is no HR and no budget. Name the escalation body above the team anyway - a foundation, a fiscal host, or a written group of senior maintainers - because a team with nothing above it has no exit from a deadlocked case.
- **Rented public space.** On a platform you do not own, the host's rules outrank yours and you cannot ban anyone; your realistic tools are reporting to the host and moving the conversation to a surface you control.
## Responses that make things worse
First drafts reach for these because they sound kind. Aurora and Gardiner name the first, third, fourth and fifth as responses that fail to stop harm or cause more of it. Keep those four out of the ladder and out of the runbook.
- **Requiring an apology**, or asking the harmed person to accept one. A compelled apology destroys the only signal worth reading: whether the person would have apologised unprompted. Contributor Covenant 2.1's first rung says "a public apology may be requested" - a line carried into the most-adopted base document in open source (40,000+ projects, per opensource.guide) - and 3.0 drops it.
- **Mediating as a substitute for a decision, or without both parties' consent.** Framing "someone is harming people here" as "those two don't get along" quietly releases the team from acting, and mediation nobody agreed to is itself a harm. Following Django's manual: facilitated communication between the parties is permitted, but only as an add-on after the team has made and recorded its own decision, and only with everyone's informed consent - never in place of a decision, and never proposed to a harmed person as the response.
- **Letting the reported person stay on condition they avoid the person who reported them.** Either they are not a threat, in which case the condition is unnecessary, or they are, in which case the community is not safe either.
- **Asking the harmed person to choose the consequence.** Show them the proposed response before announcing it - that catches missed facts and retaliation risk. Letting them decide it exposes them to blame for the outcome.
- **Doing nothing because the account is gone or unidentified.** State publicly what the response would have been.
See [references/incident-response-runbook.md](./references/incident-response-runbook.md) for the notification wording that follows from these, including a worked bad-versus-good pair.
## Publish gate
Do not ship until all eleven hold. Item 1 is Aurora and Gardiner's rule; the other ten each name a documented failure mode. The eleven-item set is assembled here, not a published checklist.
1. The code applies to the community's most powerful people, in practice and not only on paper.
2. The scope clause names surfaces and people, and takes a stance on off-platform conduct.
3. Every rung of the ladder has both a trigger and a consequence.
4. Time-boxed sanctions state their duration.
5. A private reporting channel exists and reaches a named group.
6. A second channel exists for reports about the primary recipient.
7. The acknowledgment target is a number the team can hold at current volume.
8. A no-retaliation statement is published.
9. An escalation body above the moderation team is named.
10. The case-record location, access list, and retention rule exist in writing.
11. At least two people can execute every action the ladder promises.
Failing item 11 with a four-rung ladder and one exhausted maintainer means the ladder is fiction - shorten it to what one person can do, and say so, rather than publishing a promise the community will watch break.
## Operating metrics
Track five, review them on the same cadence as the statistics report. The set of five is a selection made here, not a published standard.
- **Acknowledgment within target** - share of reports acknowledged inside the published window.
- **Cases with a recorded outcome** - anything less than all of them means the ladder is being applied from memory.
- **Median time from report to resolution** - the number reporters feel, and the one that decides whether the next person bothers reporting.
- **Moderator load** - actions and cases per person per week, against the agreed cap. Rising load with a flat roster predicts the next resignation.
- **Repeat-violation rate** - sanctioned members who violate again. A rate near zero can mean the ladder works, or that nobody reports anymore; read it next to report volume, never alone.
For flood-type problems, add submission rate and valid share, since the goal there is a lower inflow rate, not more bans.
**Where the numbers come from.** Published acknowledgment windows exist and can be quoted: one business day (Django), three business days (CNCF), and 24 hours to acknowledgement plus 10 business days to a decision (Aurora & Gardiner's worked example). The compliance _rate_ against those windows is a different matter: treat 95% acknowledgment-within-target and 100% of cases carrying a recorded outcome as starting baselines set here - reasonable gates to design against, not industry benchmarks.
Say which is which when you hand the numbers to a user, and recalibrate the baselines from the team's own first quarter of data. [references/published-findings.md](./references/published-findings.md) lists every sourced figure in this skill with its origin and its limits.
## Failure modes
| Symptom | Fix |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Code of conduct exists, nobody has ever enforced it | Build the team and runbook first, then republish with the real process |
| The rules are visibly not applied to a founder or top maintainer | Stop. Fix the exemption or drop the conduct framing; a selectively enforced code is worse than none |
| The only reporting address belongs to the person being reported | Add the alternate path and publish it in the same paragraph as the primary |
| Sanction invented after the incident | Publish the ladder before the next case; retrofitting a rule turns an incident into a governance crisis |
| Everything handled in DMs, community sees nothing | Keep the notification private, publish the fact of a response, and publish aggregate statistics on a cadence |
| Similar cases get different outcomes | Keep case records and check prior violations before deciding |
| Every case stalls in deliberation | Fix a decision rule and a decision deadline in advance - the dominant enforcement error is delay, not haste (Aurora & Gardiner) |
| Team drowning in spam or low-quality submissions | Switch from individual bans to rate limits, entry gates and submission requirements |
| One moderator handles everything | Rotate duty, cap weekly load, recruit from observed helpers in the room |
| Chat evidence vanished when the message was deleted | Archive before removing; the case record carries the evidence chat does not keep |
| A suspension outlived its stated end date | Schedule the restoration the day the sanction is applied |
| Every team member is conflicted on a case | Escalate to the named body; if none exists, close that gap first |
| Members argue the team broke its own published procedure | Publish the reporter-facing summary; keep the detailed playbook internal and revisable |
## References
- [references/code-of-conduct-outline.md](./references/code-of-conduct-outline.md) - document skeleton, the 2.1-versus-3.0 section map, scope wording, ladder table, and a weak/workable example pair
- [references/incident-response-runbook.md](./references/incident-response-runbook.md) - deadline clock, report-taking checklist, recusal grades, decision rules, notification templates and their negative example, case-record schema, and transparency reporting
- [references/platform-controls.md](./references/platform-controls.md) - venue-class controls, earned trust levels, rate limits, volume-attack defenses, and moderator roster design
- [references/published-findings.md](./references/published-findings.md) - every sourced figure and claim with its origin and limits
Cross-skill references:
- samber/developer-relations-skills@developer-community-health - measuring community health
- samber/developer-relations-skills@oss-issue-triage - technical issue workflow (labels, templates, stale policy)
- samber/developer-relations-skills@oss-governance - project decision rights and succession
- samber/developer-relations-skills@oss-contributor-onboarding - first-contribution path
- samber/dev-event-organizer-skills@event-code-of-conduct - for single-event conduct policy and on-site response; this skill covers the ongoing community, including events it runs as one surface among several