Community Rules Reference Card
Community rules reference card — five properties of enforceable rules, three essential rules, introduction checklist, rules-gap response, and quarterly audit
This page is a structured reference card for paid Slack community operators who want the community rules framework, enforcement-ready rule text, introduction checklist, gap-response protocol, and quarterly audit in scannable table form. It covers: a five-properties-of-enforceable-rules table (property, definition, enforceable example, non-enforceable example, why the non-enforceable version fails — specific, behavioural, consistent, graduated, operator-modelled); a three-essential-rules table (value-before-promotion, DM-consent, feedback-solicitation — specific requirement as written, enforcement trigger, wrong alternative, why it fails); a rules-introduction checklist (timing, framing, announcement format, content order, follow-up — recommended approach, what to avoid, why it matters); a rules-gap response table covering four situation types (behaviour without a written rule, apparent rule conflict, gap visible mid-incident, recurring gap pattern — first response, follow-up action, what not to do, outcome); and a five-question quarterly rules audit table (review question, what to look for, how to find it, action if yes). For the strategic reasoning behind what rules actually do, why most paid community rules fail, and why each property removes a specific enforcement failure mode — see the companion post: How to write community rules that members actually follow. The paid community moderation reference card covers the three-tier norm framework and four-step dispute resolution ladder that these rules plug into. This card is for the operator who understands the reasoning and needs the rule properties, enforcement-ready text, introduction checklist, gap protocol, and quarterly audit in quick-reference form.
TL; DR
Write rules that are specific (name a concrete action, not a value), behavioural (describe something observable), consistent (all members regardless of tenure), graduated (consequences on first, second, and escalated occurrences), and operator-modelled (demonstrated by how the operator participates). Start with three rules: value-before-promotion with a numeric threshold (three visible non-promotional contributions), DM-consent with visible in-thread consent required before moving to private DM, and feedback-solicitation with an explicit position stated in the document. Introduce rules before an incident, not after, using the codification frame (“we’re writing down how we’ve always operated”). When a situation is not covered by existing rules, DM-first, acknowledge the gap, then update the rules quietly after the private resolution — never during or immediately after a public incident. Review the rules quarterly against the private messages sent in the last three months.
Table 1 — Five properties of enforceable rules
A rule that fails any of the five properties is not enforceable as written — it is a statement of values or intentions that has no moderation basis. The single most common failure mode in paid community rules documents is writing rules grounded in value words (“respectful,” “professional,” “supportive”) that describe internal states rather than observable actions. These rules cannot be cited in a Step 1 DM and have the member agree that the observable action happened — which means they cannot be enforced without becoming arguments about intent. The diagnostic: can a member who reads this rule before posting know whether their planned action violates it without relying on interpretation of a word that could mean different things to different people? If yes, the rule passes the test. If no, rewrite it to describe a specific observable action.
| Property | Definition | Enforceable example | Non-enforceable example | Why the non-enforceable version fails |
|---|---|---|---|---|
| Specific | The rule names a concrete, observable action — not a value, orientation, or internal state. A specific rule describes something that can be pointed to after it happened: a post, a DM, a sequence of actions in a channel. It does not describe an intent the member had or an impression another member formed. | “No unsolicited direct messages about paid products, services, or consulting engagements to other members. Unsolicited means without visible in-thread consent from the recipient in a public channel before the DM is sent. Visible consent means a reply in a public thread indicating interest — not a reaction, not a connection request, not a prior private conversation.” | “Be respectful of other members’ time and attention.” | “Be respectful” describes an internal state that cannot be observed. When the operator cites it in a Step 1 DM, the member can respond that they were being respectful from their own perspective — which is technically true and impossible to disprove. The enforcement conversation becomes an argument about interpretation of intent rather than an application of a documented standard. Every moderation action grounded in a value word requires the operator to first win an argument about whether the member’s intent matched the value label before addressing the behaviour, and most members in good faith will dispute the label rather than the action. |
| Behavioural | The rule describes a specific sequence or category of observable actions. It describes what the member did, not what they intended, how they came across, or how another member felt about it. Behavioural rules survive enforcement conversations because both parties are referring to observable facts, not competing assessments of a subjective quality. | “Do not follow a first introduction in a public thread with a private DM mentioning paid products, services, or business engagements within 30 days of the introduction. A pitch DM requires that the recipient has indicated explicit interest in the topic in a public thread before the DM is sent.” | “Don’t be pushy or aggressive in your interactions with other members.” | “Don’t be pushy” requires the operator to make a judgment about the member’s communication style and intent — both of which the member will dispute in good faith because they did not experience themselves as pushy. The behavioural version describes a specific sequence of observable actions: did a first public introduction happen, and did a pitch DM follow within 30 days? Those actions either occurred in that sequence or they did not, regardless of the member’s intent. The operator can point to the introduction timestamp and the DM timestamp; the member cannot dispute either fact. |
| Consistent | The same rule applies to all members regardless of tenure, contribution history, reputation within the community, or their personal relationship with the operator. Consistency is less a property of the rule’s wording than a property of how it is applied, but the wording must not contain carve-outs that can be interpreted to exclude familiar or tenured members. | Rules are published in a pinned document and referenced in onboarding. When a founding member with 200 prior posts violates the value-before-promotion rule, the operator sends the same Step 1 DM with the same rule citation as they would send to a member who joined last week. The DM is identical in structure and tone regardless of the recipient’s history. | Tenured or high-reputation members receive a casual, informal mention in a private conversation about a violation; newer members receive a formal Step 1 DM citing the specific rule, for the same category of behaviour. | Every member in a small paid community observes the operator’s enforcement behaviour even without appearing to. When inconsistency is noticed — and it always is, even when no one says anything — the operator’s reputation for fairness is damaged permanently. The most concrete consequence: newer members stop contributing to discussions involving tenured members because they learn that social proximity to the operator provides protection from the standard. The community converts from a peer network into a social hierarchy, which reduces the contribution density that makes the community worth paying for. |
| Graduated | The rule specifies what happens on first, second, and escalated occurrences. Graduated consequences mean the operator enforces a documented process rather than making a unilateral judgment at each step. In paid communities specifically, first-offence removal of a paying member carries significant reputation risk; graduated rules protect both the member and the operator by ensuring proportionate, documented responses. | “Unsolicited promotional DMs: first occurrence — Step 1 private DM documenting the DM-consent standard with specific rule citation; second occurrence after the first documented DM — seven-day posting restriction in #resources and #showcase with written notice; third occurrence — membership review with documented escalation basis and refund decision.” | “Unsolicited promotional DMs will result in immediate removal from the community.” | Operators who write zero-to-removal consequences rarely apply them on first offence, and members who observe the gap between the written consequence and the actual consequence learn that the rules are not to be taken literally. When the operator eventually does remove someone for a first offence, the written consequence provides no procedural protection because it was visibly not applied in earlier cases. The graduated version is credible because each step is proportionate and documented. Credible consequences are enforced; incredible ones are not. |
| Operator-modelled | The operator’s own visible behaviour in the community demonstrates the standard before it is required of members. This is not a property of the rule’s wording; it is a property of how the operator participates. Members learn community norms through observation of the operator more reliably and durably than through reading any written document. | The operator posts with explicit context (“sharing this because three members asked about it privately — happy to answer questions publicly”), DMs members before correcting anyone in a public thread, and gives specific feedback that references a concrete action when responding to posts that invite it. The operator’s visible behaviour is the community’s primary norms demonstration. | The operator has a feedback-solicitation rule specifying that critique requires an invitation from the member who posted, but visibly offers unsolicited critique in public threads on other members’ work without solicitation. | When the operator’s behaviour contradicts the written rule, the community’s actual operating standard is the operator’s behaviour, not the text in the rules document. Members do not follow what the rules say; they follow what they observe the operator do. A rule the operator visibly violates is an instruction that applies to members but not to the operator — which is the most corrosive possible signal about how enforcement works in the community, and the one most likely to produce the “I was just doing what you do” dispute response. |
The five-property test is a rewrite test, not just a checklist. If a rule fails even one property, rewrite it — don’t add a footnote or clarifying sentence. A rule that is specific, behavioural, consistent, graduated, and operator-modelled can be written in two or three sentences. A rule that requires extensive qualification to approximate enforceability is a signal that the underlying standard has not yet been clearly defined.
Table 2 — Three essential rules
These three rules address the moderation situations that appear most frequently in paid communities in the 100–2,000 member range and are most commonly missing from or inadequately specified in existing rules documents. Each table row includes the specific requirement as written so the operator can copy, adapt, and test against the five-property framework before publishing. The wrong-alternative column shows what most operators write instead and why it produces the disputes the correctly-written version prevents. For the reasoning behind each rule — why the three-contribution threshold rather than one or two, why visible consent rather than just consent, why the feedback-solicitation rule requires an explicit position rather than a general guideline — see How to write community rules that members actually follow.
| Rule name | Specific requirement as written | Enforcement trigger | Wrong alternative | Why the wrong alternative fails |
|---|---|---|---|---|
| Value-before-promotion | “Members must make a minimum of three non-promotional contributions visible in the community’s public channels before any mention of external paid work, products, or services. Non-promotional contributions include: a substantive reply to another member’s post, a question asked in a public channel, or a resource share without an affiliate link or referral incentive. Promotional content includes: a link to a paid product or service, a mention of a service the member sells, an invitation to a paid event, or a referral to the member’s newsletter or paid community.” | Member posts a link to their paid product, mentions their consulting services, or shares a paid-event invitation in a public channel, and a review of their visible post history shows fewer than three qualifying non-promotional contributions. The trigger is a count of qualifying posts in visible channels — not a judgment about intent, not a holistic assessment of value. Both parties can audit the post history independently and reach the same count. | “Add value before promoting” or “contribute meaningfully before any self-promotion.” | Without a numeric threshold and a definition of what counts as a contribution, every enforcement conversation becomes a dispute. The member believes their previous posts qualified; the operator believes they did not; there is no shared standard to resolve the disagreement. “Three visible non-promotional contributions” is auditable — both parties can scroll the member’s post history and count. “Add value first” is not — one person’s “value” is another person’s “content marketing,” and the operator cannot enforce the rule without making a subjective judgment the member will always contest in good faith. Communities that find the three-contribution count produces problems usually discover that the underlying problem is not the count but the absence of the definition: without a definition of what qualifies, members count differently than the operator does. |
| DM-consent | “Direct messages about paid products, services, consulting engagements, business collaboration, or any offer requiring money or time from the recipient require visible consent from the recipient in a public thread before the member sends the DM. Visible consent means a reply in a public channel indicating interest in the topic — not a reaction, not a connection request, not a prior private conversation. A member who asks in a public channel whether anyone wants to discuss a collaboration topic, receives a public reply expressing interest, and then DMs the interested member is operating within this rule.” | Member sends a DM to another member about a paid product, service, or business proposition, and no public thread exchange is visible between the two members in which the recipient indicated interest in the topic before the DM was sent. The trigger is observable: the public exchange either exists in the community’s channels or it does not. The operator does not need to assess intent, relationship history, or the nature of the DM content. | “Don’t pitch in DMs” or “get permission before DMing about business.” | “Don’t pitch in DMs” leaves undefined what counts as a pitch: members who send soft-sell DMs after a brief warm-up introduction claim they were “just connecting,” not pitching, and the operator cannot point to a specific written definition. “Get permission before DMing” cannot be enforced because the operator cannot verify whether permission was given in a prior private conversation. The visible-consent requirement is specifically what makes the DM-consent rule enforceable: the public exchange is in the community’s channels, and the operator can see it. DM-consent violations are among the most disruptive early-member experiences in paid communities — new members who receive cold pitch DMs in their first week update their assessment of whether the community is worth staying in, and the operator never sees this as a cause of month-two churn because the members who leave rarely cite it as a reason. |
| Feedback-solicitation | Choose one of two positions and state it in the rules document. Position A: “Unsolicited critique and feedback on work, ideas, and posts is welcome in this community. You do not need to request critique before offering it. Direct, specific feedback on substance is encouraged; personal or dismissive commentary is not.” Position B: “Critique and feedback on work, ideas, and posts requires an explicit invitation from the member who posted. A post asking for thoughts, feedback, or opinions is an invitation. A post sharing a result, update, or win is not. If you want to offer critique on a post that does not invite it, ask first.” | Position A: No enforcement trigger for unsolicited critique itself; enforcement applies only if the critique becomes personal, dismissive, or violates the behavioural properties of the rule. Position B: Member offers substantive critique of another member’s post in a public thread, and the original post contained no explicit request for feedback, critique, or opinions. First occurrence: the member who critiqued has not previously been corrected on this standard. The enforcement trigger is the presence or absence of an explicit invitation in the original post, not the nature of the critique offered. | No written policy. The operator enforces reactively based on whether the recipient complained, stepping in when conflict surfaces and ignoring identical behaviour when the recipient says nothing. | Reactive enforcement of an unwritten feedback-solicitation standard means the operator makes decisions based on whether the recipient was upset rather than on a consistent rule. Two members can offer the same type of unsolicited critique in the same week; the operator corrects one because the recipient complained and ignores the other because the recipient said nothing. The member who received the Step 1 DM has a legitimate grievance: the standard was never communicated, and an identical action by another member was not corrected. This grievance is impossible to address without a written rule. The feedback-solicitation rule prevents the “I was just trying to help” dispute entirely: when the position is explicit and in the rules document, the member who offered unsolicited critique under Position B cannot claim they did not know. |
These three rules are not sufficient to cover all moderation situations — they cover the patterns most likely to appear first and most difficult to enforce without a written standard. Beyond them, the rules most worth writing are the ones corresponding to situations the operator has already addressed through private messages: patterns the community has actually produced rather than patterns the operator anticipates. A short rules document with three well-written rules does more for self-moderation than a comprehensive one with twenty rules that are too abstract to apply.
Table 3 — Rules-introduction checklist
Most paid community operators who decide to formalise their rules are doing so in a community that already has members and already has norms they have been informally enforcing. The introduction is not a policy shift; it is a communication. These five considerations determine whether members receive the rules as a neutral formalisation of existing standards or as a signal that something has changed or gone wrong. The most important is timing: rules introduced immediately after a public moderation event feel reactive and targeted regardless of framing, and that association is extremely difficult to reverse. For the full reasoning behind each consideration, see How to write community rules that members actually follow.
| Consideration | Recommended approach | What to avoid | Why it matters |
|---|---|---|---|
| Timing | Introduce rules before an incident, not after. Draft the document, set a publication date, and communicate it on that date regardless of whether any moderation events are currently active. A minimum two-week gap between the most recent visible moderation event and the rules announcement is sufficient to prevent the rules from being associated with the event. If the community is currently experiencing a moderation situation, handle the situation through private DMs first, then introduce the document on the scheduled date after the gap. | Posting the rules document immediately after a public moderation event. Framing the announcement as “after recent events, we’re clarifying our expectations” — even if you believe this sounds neutral. Rushing the document out “while the topic is on people’s minds.” | Rules introduced immediately after a visible moderation event are interpreted as a response to that event regardless of how they are framed. Members who witnessed the event read the new rules through the lens of what just happened and treat them as targeted rather than principled. Every member who was not directly involved in the event also reads them through that lens. The association is more durable than the rules themselves — members who join months later will hear the context from existing members, not just read the rules document. Rules introduced before any specific incident have no association to acquire. |
| Framing | Use the codification frame: “We’re formalising the standards the community has always operated by — not introducing new requirements. These are the norms you’ve seen applied informally, now written down so every new member starts with the same understanding.” This framing is accurate for most operators: the value-before-promotion, DM-consent, and feedback-solicitation rules being documented are almost always norms the operator has enforced informally through private messages. Writing them down changes where the standard lives, not what the standard is. | The restriction frame: “We need to establish some rules” (implies the community was previously ungoverned). The liability frame: “To protect all members, we are implementing a formal code of conduct” (signals the operator is primarily thinking about their own exposure, not the member experience). The response frame: “After recent events, we’re clarifying our expectations” (associates rules with a specific incident). | Members who have been in the community long enough to have observed the operator’s enforcement behaviour will recognise the codification frame as accurate and experience the rules document as a convenience — the standard they already knew, now accessible in writing. The restriction frame creates resistance from existing members who interpret the announcement as a policy shift and generate questions about what changed that the operator cannot answer without either pointing to an incident or claiming there was no change, both of which undermine the framing. The codification frame produces no such questions because it accurately describes the situation. |
| Announcement format | A brief post in #announcements: two to three sentences stating that you are formalising the community’s operating standards, a link to where the rules are posted (pinned in #start-here or a dedicated rules channel), and an invitation to ask questions in the replies thread. Nothing else. Members who want to read the rules will click through to the document. Members who have no questions will see a routine administrative update and continue as normal. | Reproducing the full rules text in the announcement post rather than linking to the rules document. A lengthy announcement post explaining the philosophy behind each rule, the reasoning for each decision, or assurances that “this doesn’t mean we don’t trust you.” Sending a DM blast to all members with the announcement text or a request to confirm they have read the rules. | A brief announcement signals that the operator treats this as a routine administrative update, which is the accurate characterisation. Lengthy announcements that explain and justify each rule signal that the operator is defensive about the decision, which makes members who were indifferent about the rules update their assessment toward concern. The assurance that “this doesn’t mean we don’t trust you” invites every member to ask whether they should now consider whether the operator trusts them, a question that would not have occurred to them before the assurance was offered. |
| Content order in the rules document | Begin the rules document with the rules: a numbered or bulleted list of specific, behavioural requirements, each described in one to three sentences in plain language. Philosophy, values, and context about the community’s purpose and operating principles belong after the rules as a following section or appendix — not before them. The document should begin with the first rule, visible in the first screen without scrolling. | Starting the document with a multi-paragraph introduction about the community’s values, its history, the operator’s approach to community building, or why the community exists. Placing a preamble or disclaimer (“these rules are intended to foster a welcoming environment where…”) before the rules that a member must scroll past to reach the specific requirements. Organising the document by principle rather than by rule. | Members who open the rules document to check a specific standard before posting need to find that standard immediately. A document that buries the rules under a preamble is functionally a document with no rules, because the members who most need to consult it in real time — those actively deciding whether their planned post is acceptable — will not scroll past three paragraphs to find the answer. A member who posts something that violates a rule they could not find in the document has a legitimate complaint about the document’s usability, not about their own behaviour. |
| Follow-up | Leave the announcement post and the rules document in place. Pin the rules in #start-here. Answer questions in the announcement replies thread if members ask. Do not send follow-up messages, reminders about the announcement, or elaboration on specific rules unless a member asks a specific question. The most effective follow-up is the operator’s own behaviour: operating consistently with the rules from the day of announcement makes them credible without any additional communication. | Sending follow-up messages explaining why specific rules were written the way they were. Announcing the rules a second time to ensure all members saw the first announcement. Prompting members to confirm they have read the rules or react to the announcement post to acknowledge receipt. Revisiting the announcement in a weekly digest summary (“a reminder that our community rules are now posted”). | Follow-up communication about the rules signals uncertainty about the reception, which makes members who had no opinion about the rules update their assessment toward concern. The announcement is complete when the document is posted and linked. Every follow-up message reopens the announcement as a topic of attention, extends the window during which members are actively thinking about the rules rather than about the community’s content, and creates an implicit suggestion that the initial announcement was not sufficient — inviting members to ask why the operator felt further emphasis was needed. |
Table 4 — Rules-gap response
Every rules document has gaps. Some are predictable; some emerge from combinations of behaviour that no set of rules anticipates. The four situation types in this table cover the most common gap-response scenarios in paid communities: behaviour without a written rule, apparent conflict between two existing rules, a gap that becomes visible mid-incident, and a recurring gap pattern that has appeared more than once. The protocol for all four is private-first — the same principle that governs the three-tier norm framework. The sequence — resolve privately, then codify — is not negotiable. Operators who reverse the sequence (codify publicly, then resolve privately) produce a class of dispute — public correction for an unwritten standard — that is difficult to recover from because it is genuinely unfair and members recognise it as such. The paid community moderation reference card covers the four-step dispute resolution ladder that gap-response DMs slot into as Step 1 actions.
| Situation type | First response | Follow-up action | What not to do | Outcome when handled correctly |
|---|---|---|---|---|
| Behaviour without a written rule | Send a private DM to the member. Acknowledge explicitly that the situation is not covered by the current written rules. Describe what you are observing, explain why it does not align with the community’s values even without a specific rule, and describe what you would like to see instead. Apply the same structure as a Step 1 DM: the specific behaviour, the relevant standard (stated as the community’s values rather than a named rule), and the operator’s expectation going forward. Acknowledging the gap is not a weakness — it is more trustworthy than an improvised claim that the behaviour violated a rule it did not technically violate, which the member will investigate and find inaccurate. | After the private resolution, draft the new rule that covers this category of behaviour using the five-property framework. Add it to the rules document in the next scheduled update — or immediately if the pattern is likely to recur soon. Log the addition date and the general pattern covered in the internal moderation record. Do not reference the specific member or incident in the log entry for the new rule. | Do not post a public announcement about the gap or the new rule while the specific situation is active. Do not reference the specific member or post when adding the new rule to the document. Do not wait until the next quarterly audit if the gap involves a pattern likely to recur within the next few weeks — write and add the rule immediately after the private resolution in that case. | The member receives clear private guidance about the community’s expectation without the reputational damage of a public correction for a standard that was not written down when they acted. The new rule enters the document as standing policy with no association to any specific incident. Members who later read the rule see a standard; they do not know what prompted it, which is the outcome that serves the community’s culture rather than its drama. |
| Apparent conflict between two existing rules | Treat the apparent conflict as ambiguity to be resolved through the specific facts of the situation, not as a genuine structural conflict requiring a public determination. Contact the member privately before making any determination about which rule applies or whether a violation occurred. In most cases, the full facts of the specific situation make clear which rule is relevant — apparent rule conflicts almost always dissolve when the operator has complete information rather than just the public-channel view of what happened. | Resolve the specific situation through the DM. Then examine the two rules for the structural ambiguity that produced the apparent conflict. Typically the fix is one of: adding a definition that clarifies which rule takes precedence in specific circumstances, adding a qualifying condition to one rule that distinguishes it from the other, or adding an explicit note such as “this rule does not apply when [other rule] is applicable.” Update the rules document quietly. | Do not post a public ruling about which rule takes precedence. Do not announce that you are “clarifying” a rules ambiguity, especially if the clarification would be clearly connected to a recent visible event. Do not apply both rules simultaneously to the same member for the same action — if two rules cover the same behaviour, only the more specific one applies, and the structural ambiguity is a document problem to be fixed, not a member-facing enforcement problem to be communicated. | The member receives guidance on the specific situation without being subjected to a public determination about a rules conflict that the operator identified in the course of trying to address their behaviour. The rules document is updated with clearer specification, reducing the probability of the same apparent conflict recurring. The operator discovers the structural flaw in the rules in a low-stakes context rather than in the middle of a community dispute where every member is watching. |
| Gap visible mid-incident | If a situation that reveals a rules gap is already in progress in a public channel, handle the immediate situation through private DMs to the relevant members using the Step 1 structure. Do not attempt to resolve the public situation by posting a new rule in the same thread or posting a general reminder in the channel before completing the private DMs. The private DM channel is the first and only response channel for the gap situation regardless of how publicly visible the triggering behaviour was. | Draft the new or updated rule during the minimum two-week gap after private resolution. Review the draft for the five properties. Add it to the rules document on a date not connected to the incident by timing. A quiet update to the document with no announcement is acceptable; a brief general #announcements note that the rules document has been updated is acceptable if the operator uses this format routinely. What is not acceptable is an announcement that is clearly triggered by the recent event. | Do not post a general #announcements reminder clearly triggered by the recent event (“friendly reminder about DM consent…” posted the same day as a visible DM-consent incident). This is a public call-out with plausible deniability, and the community reads it as such. Every member who saw the triggering behaviour knows the announcement is about that specific event, including the member involved, who now experiences a public correction that follows their private DM correction — the worst-case combination for member trust and retention. | The incident is resolved through private DMs, which preserves the involved member’s dignity and prevents the dispute from becoming a community event that other members feel obligated to process or take sides on. The new rule enters the document after sufficient time that it carries no visible association with the incident. When the next similar situation occurs, the operator can cite the specific written rule in the Step 1 DM rather than citing the community’s values, which reduces the probability of a dispute about whether the standard applies. |
| Recurring gap — same category of situation has appeared two or more times | By the second occurrence of the same type of situation without a written rule, the pattern has demonstrated it needs written coverage before the third occurrence rather than another gap-response DM. Review the DMs sent for both prior occurrences to identify the precise behaviour pattern that was addressed — the rule should cover that specific pattern, not a broader category that would inadvertently restrict behaviours that were not problematic. Write the rule using the five-property framework. | Add the new rule to the document during the next scheduled update or immediately if the pattern is recurring rapidly. A brief general update note in #announcements is appropriate when adding new rules as part of a scheduled update. Review the DMs sent for prior occurrences to determine whether those members need a brief follow-up DM noting that the relevant standard is now in the written document — typically a single sentence: “I’ve added [rule topic] to the community rules, which formalises the standard I mentioned in my message last month.” | Do not continue handling the third and subsequent instances of the same pattern as gap responses. Treating the third incident as “another rules gap” rather than an enforcement situation for the rule you should have written after the second incident is a process failure, not a rules gap. Do not write the rule only after a highly visible third incident makes the absence of a written standard publicly evident — the operator who responds to a recurring pattern with “we need to formalise our expectations around…” has communicated to the community that rules appear in response to escalating problems rather than in anticipation of them. | The recurring pattern is covered by a written rule before a third incident produces the community-visibility problem that recurring gap responses eventually generate. Subsequent instances are handled as standard Step 1 enforcement rather than gap responses, which is faster, better documented, and more consistent. The written rule enables the community’s new members to self-moderate before their first post in this category — which is the outcome gap-response DMs cannot produce, because gap responses are invisible to members who were not the direct recipient. |
Table 5 — Quarterly rules audit
A rules document calibrated to the community the operator had at founding becomes progressively less accurate as the community grows and its composition shifts. The quarterly audit is a thirty-minute review that keeps the document calibrated to what the community actually needs rather than what the operator anticipated at the time of writing. The five questions cover the two directions of rules drift: missing rules (patterns the community has produced that are not covered) and stale rules (provisions that cover situations the community has not produced). A shorter, tighter rules document that covers real patterns is more likely to be read by new members and more likely to enable self-moderation than a comprehensive document covering hypothetical edge cases. The Foothold community health check identifies the contribution distribution and engagement metrics that surface moderation pressure before it becomes visible in specific incidents.
| Review question | What to look for | How to find it | Action if yes |
|---|---|---|---|
| Are there patterns in my private DMs not covered by a written rule? | Categories of behaviour that prompted two or more private DMs in the last three months where the DM cited the community’s values rather than a named, written rule. Any DM that begins “we don’t usually…” or “in this community we prefer…” or “as a general guideline…” is evidence of an informal norm that has not been formalised. Two or more DMs citing the same informal standard is the threshold for writing a rule. | Review the last three months of private DMs sent to members. Group them by the type of behaviour addressed. For each group, check whether the behaviour is covered by a specific named rule in the current rules document. If a group has two or more instances and is not covered, it is a rule-writing candidate. | Write the rule using the five-property framework. Test it against the diagnostic before finalising: can a member who reads this rule before posting know whether their planned post violates it? Add the rule to the document and note the addition date in the internal moderation record. A brief #announcements note that the rules document has been updated is appropriate; naming what changed is optional but recommended if the new rule covers a behaviour pattern that is not intuitively obvious from the existing rules. |
| Are there rules that have never been invoked? | Rules that have not been cited in any Step 1 DM, public redirection, or Step 3 limit in the last twelve months. Rules that cover hypothetical edge cases that have not arisen in the community’s actual history. Rules inherited from other communities’ templates that do not correspond to patterns the operator has ever observed in this specific community. | Cross-reference the written rules against the internal moderation log. Any rule that does not appear in any log entry in the last year has either never been violated or covers a category of behaviour the community has not produced. Both cases warrant examination of whether the rule belongs in the document. | Examine whether the rule covers a plausible pattern likely to arise as the community grows, or whether it was written in anticipation of a problem that has not materialised and is unlikely to. Remove rules that cover patterns the community has not produced and that do not correspond to a growth-related risk. Retain rules that cover real but rare patterns — note in the internal record why the rule was retained despite zero invocations. A shorter document with rules calibrated to actual community behaviour is more likely to be read by new members than a comprehensive document that includes extensive coverage of situations that never arise. |
| Do members ask clarifying questions suggesting they misread a rule? | Posts in public channels asking for clarification about what is allowed in a specific context, where the answer should be derivable from the existing rules. Onboarding DMs from new members asking questions the rules document should answer. Step 1 DM replies from members who demonstrate they had a genuine, internally consistent but incorrect interpretation of the rule’s scope — as opposed to members who received the DM accurately and are disputing the decision. | Review public channel clarifying questions and #start-here replies from new members over the last three months. Review the replies received to Step 1 DMs, noting specifically the replies that express genuine surprise (“I thought the rule meant…”) rather than dispute (“I don’t think I violated…”). The distinction matters: genuine surprise indicates an ambiguous rule; dispute indicates a member who understood the rule and chose to test it. | Rewrite the ambiguous rule with greater specificity. Common fixes: add a definition of a key term the member was interpreting differently than the operator intended; add an explicit qualifying example (“for example, a reply to a channel post asking for tool recommendations counts as a non-promotional contribution; a reply that begins with a product recommendation does not”); add an explicit note about what the rule does not cover if the member’s misinterpretation was reasonable given the rule’s current wording. |
| Have informal exceptions accumulated? | Cases where the operator applied a rule differently for a specific member without documenting the exception or adjusting the rule. Common patterns: a founding member who has been allowed to promote without meeting the contribution threshold; a high-profile member whose DM pattern has not been addressed; a role type (sponsors, staff, affiliates) that has been given informal latitude not reflected in the written rules. | Review the most recent three months of Step 1 DMs and compare the members addressed to the visible behaviour of members not addressed for the same category of action. If the operator can identify members who exhibited the restricted behaviour and were not contacted, that is evidence of informal exceptions. The test is: would a new member observing both the rule and the unaddressed behaviour conclude that the rule applies to all members? | Eliminate the exceptions or formalise them. If a role type (sponsors, founding members, staff) has been given different latitude, write that carve-out into the rules explicitly so all members can see it and new members of that role know the standard from day one. If the exceptions were inconsistency rather than intentional latitude, begin applying the rule consistently from the review date forward. Do not send retroactive Step 1 DMs for the uncorrected instances — address only the next instance that occurs after the review date. The internal moderation record should note when consistent application resumed. |
| Has the community’s composition or purpose shifted in the last year? | A meaningful change in the ratio of practitioners to service providers; a shift in the primary topic focus that makes existing rules either over-broad (applying to behaviours that are now welcome) or under-specified (not covering new types of behaviour the shifted composition produces); a growth from under 200 to over 500 members, which typically requires different written expression of norms that were adequately governed by informal modelling at smaller scale. | Review the member list by join date, noting any shift in member profile (job function, industry, intent) over the last 6–12 months. Review the post types and channel activity in the most active channels to assess whether the content mix has shifted. Review the topics of Step 1 DMs — a shift in what the operator is most commonly addressing is evidence that community behaviour has changed in ways the existing rules do not adequately cover. | Rewrite rules calibrated to the previous composition for the current community. A community that has shifted from mostly practitioners to a significant proportion of service providers will need a more specific value-before-promotion rule with a clearer definition of what counts as promotion for the new member profile. A community that has grown substantially may need a more explicit DM-consent rule and a clearer feedback-solicitation position, because informal operator-modelling of the standard reaches a smaller percentage of total membership at 500 members than at 50 — formal written expression picks up the gap that informal modelling no longer covers at scale. |
The quarterly audit takes about thirty minutes. The internal moderation log — a simple record of Step 1 DMs sent, rule cited, date, and outcome — is what makes the audit possible in that time. Without a log, the audit requires reconstructing three months of memory, which takes longer and is less accurate. Start the log before you need the audit, not at the quarter when you first try to run it.
Frequently asked questions
What rules should a paid community have?
The three rules most paid communities need and rarely have in written, specific form: (1) A value-before-promotion rule with a numeric threshold — “three or more non-promotional contributions visible in the community’s public channels before any mention of external paid work, products, or services.” Not “add value before promoting,” which has no enforcement basis because it describes an orientation, not a threshold. The rule must define what counts as a non-promotional contribution and what counts as promotion. (2) A DM-consent rule with visible consent required — direct messages about paid products, services, or business require a public thread reply from the recipient indicating interest before the DM is sent. The visibility of the consent is what makes the rule enforceable: the operator can see whether the exchange occurred. (3) A feedback-solicitation rule with an explicit position — either unsolicited critique is welcome, or it requires an invitation from the poster. Both positions are defensible; neither an absent position nor an ambiguous one is. Beyond these three, the rules most worth writing are the ones corresponding to situations the operator has already addressed informally through private messages. The private messages sent in the last three months are the best source for identifying which rules the community actually needs next.
What makes a community rule enforceable?
An enforceable rule has five properties. Specific: names a concrete action, not a value. Behavioural: describes something observable that both the operator and the member can verify happened. Consistent: applies identically to all members regardless of tenure or relationship with the operator. Graduated: specifies what happens on first, second, and escalated occurrences so enforcement is a documented process, not a unilateral decision. Operator-modelled: demonstrated by the operator’s own visible participation before it is required of members. The single most useful test: can a member who reads this rule before posting know whether their planned post violates it? If the answer depends on interpretation of a word like “respectful,” “appropriate,” or “professional,” the rule is not enforceable as written. Rewrite it to describe a specific observable action. The value-before-promotion rule illustrates the rewrite: “add value before promoting” becomes “three or more non-promotional contributions visible in the community before any mention of external paid work” — the rewrite adds a threshold, a definition of visible, and a definition of the two categories of action, all of which were absent in the original and all of which an enforcement conversation requires.
How do you introduce rules to an existing community?
The frame that works is codification, not restriction: “We’re formalising the standards the community has always operated by — not introducing new requirements.” This frame is accurate in most cases: the rules being written down are the norms the operator has been informally applying. Timing matters as much as framing: introduce rules before an incident, not after. Rules that arrive immediately after a visible moderation event feel reactive and targeted regardless of framing, and that association is difficult to reverse. If the community is currently in a moderation situation, handle it through private DMs, then introduce the document after a two-week gap. The announcement should be brief: two to three sentences in #announcements, a link to the rules document, an invitation to ask questions. The document itself should begin with the rules — not a preamble about values and philosophy — so a member who opens it to check a specific standard before posting finds it immediately without scrolling. The most effective follow-up to the announcement is the operator’s own consistent behaviour from the day the rules are posted.
What do you do when a situation isn’t covered by your rules?
The default is DM-first: contact the member privately, acknowledge that the situation is not explicitly covered by a written rule, describe what you are observing and why it does not align with the community’s values, and describe what you would like to see instead. Acknowledging the gap is not a weakness — it is more trustworthy than claiming the behaviour violated a rule it did not technically violate. After the private resolution, update the rules to cover the gap. The sequence — resolve privately, then codify — is important. The temptation when a gap becomes visible is to post a new rule or a “friendly reminder” while the situation is still live. Even without naming a member, these posts are read by the community as targeted at the specific event: every member who saw the triggering behaviour knows the announcement is about it. Rules updated quietly after a private resolution carry no such association and enter the document as standing policy. For recurring patterns — two or more gap-response DMs for the same category of situation — write the rule before the next occurrence rather than continuing to handle each instance reactively. The quarterly rules audit is the systematic version of this process: reviewing private messages sent in the last three months to identify which patterns need written coverage, and reviewing existing rules that have never been invoked for possible removal.