Community Terms of Service and Guidelines — Minimum Required Rule Design

What Happens When You Run Without Rules

Most communities start moving before any rules are in place. When numbers are small, the operator’s personality and ambient atmosphere can smooth over most tensions — but as the community grows, “atmosphere” alone stops working.

Three problems arise most commonly in communities without rules in place.

1. Decisions depend on individuals, and responses are inconsistent: A comment gets approved one week, and the same type of comment is rejected the next by a different moderator. Without a standard, every call is personal.

2. Bans and warnings look “emotional”: When someone is removed for “making the atmosphere worse” with no rule to point to, other members think “that could happen to me.” Psychological safety drops, and self-censorship increases.

3. Operators burn out: Having to think from scratch every time a problem occurs is the most exhausting pattern an operator can face. Without records, the same dilemmas recur with the same mental load.

Setting up rules is not “strengthening control” — it’s the process of moving judgment from individuals into systems. Both members and operators find the existence of rules reassuring.

The Difference Between Terms of Service and Guidelines

The first concept to understand in community rule design is the division of roles between terms of service and guidelines.

Put simply: terms of service are the document for worst-case scenarios; guidelines are the document for ideal-case scenarios.

Both are necessary. Terms of service alone produce a “list of prohibitions” — they can’t build community culture. Guidelines alone leave you without a clear basis to act on serious violations. Having both working together gives you both “defense” and “cultural design.”

What to Include in Terms of Service

Draft terms of service to the minimum viable standard — “this much and it works.” The items to include vary with scale and context, but these five are the foundation.

1. Explicit Prohibited Actions

List the specific behaviors that result in suspension or removal. Aim for concrete actions, not abstract descriptions.

Minimum prohibited actions to include:

• Defamation, personal attacks on other members
• Unauthorized disclosure of personal information (name, contact details, affiliation)
• Spam (unsolicited promotion or solicitation)
• Discriminatory language, harassment (on the basis of gender, nationality, beliefs, etc.)
• Posting or sharing illegal content

2. Disclaimer

State clearly that information and advice exchanged between members does not carry an operator guarantee. This is especially important for “reliability of professional advice” and “products or services recommended by members.” A clear disclaimer prevents disputes before they start.

3. Copyright and Content Ownership

Specify who holds copyright on content members post (text, images, audio, etc.). The most practical arrangement is usually: “Copyright belongs to the poster, who grants advance permission for sharing and quotation within the community.” If the operator uses community-wide content (recordings, meeting notes, etc.), document those rules as well.

4. Handling of Personal Information

State how information collected at enrollment (email, name, profile, etc.) is used, stored, and whether it is shared with third parties. Depending on the platform, a reference to the platform’s own privacy policy may suffice — but any information the community collects independently (surveys, event attendance data, etc.) needs to be addressed separately.

5. Withdrawal and Removal Conditions and Procedures

Document both voluntary withdrawal procedures and the conditions under which the operator may remove a member. Go beyond “what violations lead to removal” and address “what happens to content and data after removal” and “is there an appeals process.”

What to Include in Community Guidelines

Guidelines are the document that tells participants “what kind of place this community is.” Center them on recommendations rather than prohibitions, so that a member who reads them can picture how to behave.

Recommended Behaviors

Good examples:

• “When asking a question, sharing what you’ve already tried helps others give more specific answers.”
• “When you disagree, check the other person’s intent before pushing back.”
• “Actively welcome and greet new members joining for the first time.”

Writing “it helps if you do X” rather than “you must do X” draws out self-directed behavior from participants. The art of writing guidelines that guide rather than prohibit is covered in detail in Writing Guidelines That Guide — Instead of Just Prohibiting.

Communication Tone

Define the community’s “tone.” For example: “We welcome specialized discussion, but we maintain an atmosphere where beginners can ask questions freely.” Or: “Humor is welcome, but avoid humor that targets specific individuals or demographic groups.”

This also becomes a reference for later moderation calls. “Does this comment fit the community’s tone?” is a question that resolves many grey areas.

How to Use Channels and Features

Briefly explain what to post where and what each feature is for. Making intentions legible — “keep promotions out of the main channel,” “questions go in #questions” — reduces both under-activity and overcrowding organically.

Minimum Template Examples

Below are minimum-viable templates for a small community using Slack or Discord. Modify them to fit your community’s purpose, scale, and platform before using.

Terms of Service (Minimum Version)

[Community Terms of Service]

1. Prohibited Actions
The following actions are prohibited in this community:
· Defamation or personal attacks against other members
· Unauthorized disclosure of personal information
· Unsolicited promotion or solicitation of products or services
· Discriminatory language, harassment
· Any other actions the operations team judges to be inappropriate

2. Copyright
Copyright on posted content belongs to the poster.
However, sharing and quotation within the community is permitted in advance.

3. Disclaimer
Information and advice exchanged in this community reflects the personal views
of individual members. The operations team does not guarantee accuracy or effectiveness.

4. Withdrawal and Removal
To withdraw, contact operations via #withdrawal or direct message.
If prohibited actions are confirmed, the operations team may remove the member at their discretion.

5. Changes to These Terms
If these terms are changed, members will be notified of the content and reasons.

Last updated: YYYY-MM-DD

Community Guidelines (Minimum Version)

[Community Guidelines]

■ About This Community
[Purpose, intended audience, what we care about]

■ What We Expect from Participants
· Questions are welcome. If you're unsure whether to post, go ahead and post.
· When there's disagreement, check the other person's intent before pushing back.
· Actively welcome and greet new members.

■ How to Use Channels
· #general: Casual conversation and everyday exchanges
· #questions: Questions only
· #announcements: Operator announcements only (please don't post here as a member)

■ Things to Avoid
· Promoting products or services (contact operations first if you'd like to share)
· Comments targeting specific individuals or demographic groups

■ If You Need Help
Contact operations (@{operator}) by DM or post in #help.

Keeping It Alive After You Create It

Writing terms of service and guidelines is not enough on its own — there’s a real risk of ending up with “a page that exists and no one uses.” Documents only work when they’re put into operation.

Include in Onboarding — Get Agreement

Terms of service should be embedded in the enrollment flow (application form, invitation email, etc.), creating the fact that a participant read and agreed to them. Guidelines should be linked in the welcome channel or welcome message so they’re the first thing new members see.

Have a Response Flow for Violations

Decide in advance: “We found a violation — what now?” That means: a channel to receive reports, escalation stages (first a warning, then removal on repeat offense), who makes the call, and how to keep records. Having this flow prevents operators from carrying the weight of every incident alone. The CoC operational design — including the three-loop framework — is covered in Making a Code of Conduct Actually Work.

Review Regularly

As communities grow, situations arise that no one anticipated. Schedule a review approximately every six months and bring “cases where no rule existed and we weren’t sure how to respond” into the next revision. When you make changes, notify members of what changed and why — that’s what keeps trust in the rules intact over time.

Summary

• Terms of service are hard rules (the basis for contracts and removal); guidelines are soft rules (a cultural declaration). Each has a distinct role.
• The five foundational items for terms of service: prohibited actions, disclaimer, copyright, personal information, withdrawal and removal conditions.
• Guidelines should center on “recommended behaviors,” “communication tone,” and “how to use channels.”
• Templates are a starting point — always adapt them to your community.
• Creating rules is not the finish line. Put them into operation through three mechanisms: onboarding, violation response, and regular review.

Rule design is the work of building your community’s “defense.” Well-established rules give every participant a basis for reassurance, and give operators an environment where they can make calls through systems rather than emotion. Starting minimal is fine — build it out through operation and experience. That’s what a rule system that actually works in the long run looks like.

Related Articles

Designing Community Guidelines That Guide, Not Forbid — Wording Patterns That Change Behavior

When community guidelines fail to be followed, the cause is usually not missing items but the wording itself. We cover five principles for steering toward desired behavior instead of forbidding, plus a copy-paste NG/OK comparison set.

rokuse.com/en/blog/community/guideline-writing-patterns

Making Your Code of Conduct Actually Work — Beyond Just Posting the Document

We explain how to move from a CoC that sits on a page to one that functions through three operational loops — onboarding, violation response, and periodic review.

rokuse.com/en/blog/community/code-of-conduct-operationalization

Expressing Community Operation in Code — Implementation Patterns for Policy, Moderation, and Invite Flows on Slack

We explain implementation patterns for declaratively managing operational policy, moderation, and invite flows in code on top of Slack. We show concrete file structures, automation designs, and a phased adoption path for moving from person-dependent operation to a reproducible system.

rokuse.com/en/blog/community/community-as-code-slack

Community Purpose Design — Moving Beyond "We'll Figure It Out as We Go"

This article identifies three symptoms that emerge when a community lacks a clear purpose, and presents a four-axis framework for structuring purpose design around Who, What, Why, and By When.

rokuse.com/en/blog/community/community-purpose-design