A rule should define behavior and consequence
A useful rule says what is prohibited, gives an example, states the usual consequence, and explains how to appeal. Avoid vague rules such as “do not be annoying” when staff cannot apply them consistently.
Starter rule framework
| Area | Example rule | Typical first response |
|---|
| Chat | No threats, targeted harassment, hate speech, or repeated spam. | Warning or temporary mute depending on severity |
| Gameplay | No unauthorized clients, duplication exploits, or bypassing protections. | Evidence review, rollback, temporary ban |
| Building | Do not grief, steal, or claim another player’s work. | Restore damage and apply proportionate sanction |
| Privacy | Do not share private information or impersonate staff. | Immediate removal and escalation |
| Staff | Staff actions must be logged and conflicts disclosed. | Review by another administrator |
Enforcement ladder
- Preserve evidence and identify the exact rule.
- Check prior actions and context.
- Use the least severe action that protects the community.
- Record duration, reason, staff member, and evidence.
- Provide an appeal route.
- Review repeated patterns and improve the rule if necessary.
Permissions and least privilege
Do not solve moderation by giving every staff member full operator access. On compatible software, use roles that separate chat moderation, player management, world editing, plugin administration, and server power controls.