From bc4b90b20981354a67751c2a851c66ada7bd366a Mon Sep 17 00:00:00 2001 From: Sakariyah Abdulhazeem Date: Tue, 29 Sep 2026 00:52:51 +0100 Subject: [PATCH] docs(governance): add moderation policy --- Governance/policies/MODERATION.md | 134 ++++++++++++++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 Governance/policies/MODERATION.md diff --git a/Governance/policies/MODERATION.md b/Governance/policies/MODERATION.md new file mode 100644 index 00000000..a7b94f17 --- /dev/null +++ b/Governance/policies/MODERATION.md @@ -0,0 +1,134 @@ +# Moderation Policy + +- **Status:** Active +- **Version:** 1.0.0 +- **Owner:** Maintainers (see [Roles & membership](../README.md#structure)) +- **Last reviewed:** 2026-09-29 +- **Review cadence:** Every 6 months, or after a material change to the Code of Conduct or contribution process + +This policy explains how TeachLink Backend keeps project spaces useful, +welcoming, and safe. It applies to issues, pull requests, discussions, +reviews, and other project-managed communication. It complements the Code of +Conduct and does not replace the project's security-reporting process. + +## 1. Moderation Principles + +Moderators and maintainers apply these principles consistently: + +1. **Safety first.** Threats, harassment, doxxing, credential exposure, + malicious code, and other clearly harmful content are handled promptly. +2. **Focus on behavior and impact.** Decisions address observable conduct and + its effect on people or the project, not a contributor's identity, + popularity, or disagreement with a maintainer. +3. **Proportionality.** Prefer the least restrictive action that protects the + community and restores a productive discussion. Repeated or severe conduct + may require stronger action. +4. **Consistency.** Similar conduct should receive similar treatment. Any + exception must be explained in the moderation record. +5. **Due process.** When safe and practical, tell the affected person what + rule or behavior prompted an action and how to request reconsideration. +6. **Privacy.** Do not publish private reports, personal information, or + security-sensitive evidence. Share only the minimum necessary details. + +Moderation is not a tool for suppressing good-faith technical disagreement, +negative project feedback, or a report that is inconvenient to the project. + +## 2. Actions Available to Moderators + +Depending on the behavior and urgency, an authorised moderator may: + +- ask for a discussion to return to the issue's scope; +- request that secrets, personal data, or sensitive exploit details be removed; +- hide or remove content that violates the Code of Conduct, exposes secrets, + or creates a credible safety risk; +- close, lock, or move an issue or discussion when it is duplicative, + resolved, off-topic, or no longer constructive; +- issue a private or public warning, with the least public detail needed; +- temporarily restrict participation when a cooling-off period is needed; or +- recommend a longer suspension or account-level action to the repository + owner when the platform or organisation must apply it. + +Only repository owners or people with the required platform permissions may +perform account, team, repository-setting, or access changes. A moderator +must not request a password, personal access token, private key, or other +credential as part of moderation. + +### Urgent safety and security reports + +For an active threat, exposed credential, doxxing, or security vulnerability: + +1. Preserve the minimum evidence needed to explain the action. +2. Remove or restrict the dangerous content where authorised. +3. Notify the repository owner and use the private security channel described + by the repository's security policy. +4. Rotate or revoke exposed credentials through the owner, without copying the + secret into an issue or pull request. +5. Record the action without reproducing sensitive values. + +Moderators should not investigate a live vulnerability in a public thread. + +## 3. Transparency and Records + +Moderation should be understandable and auditable without exposing private +information: + +- A warning or restriction should identify the relevant rule or behavior, + unless doing so would create a safety or privacy risk. +- The moderator records the date, affected project area, action, reason, + duration if temporary, and the responsible reviewer in the private + moderation log or appropriate issue record. +- Public notices describe the outcome at a high level; they must not include + private reports, personal information, credentials, or security details. +- Periodic maintainer reviews should look for inconsistent enforcement, + repeated concerns, and whether restrictions can be lifted. +- Records are retained only for as long as needed for accountability and + follow the project's privacy and retention policies. + +When a content removal changes the technical record, leave a short neutral +placeholder where possible, such as "Content removed under the moderation +policy; see the issue history for the maintainer decision." Do not quote the +removed sensitive content. + +## 4. Notice and Reconsideration + +Except for urgent safety actions, the affected contributor should receive a +notice explaining the action and how to respond. A reconsideration request +should include the relevant issue or pull request, the action being +challenged, and any new context. It should be reviewed by a maintainer who +was not the sole decision-maker for the original action when practical. + +An action may be upheld, narrowed, lifted, or replaced. A temporary +restriction should have a review point; silence does not make a permanent +restriction automatic. + +## 5. Roles and Limits + +- **Moderators** apply this policy within the permissions granted to them and + escalate access, security, and account decisions. +- **Maintainers** own final repository decisions, review escalations, and make + sure moderation does not bypass contribution or decision-making policies. +- **Contributors** should report concerns in good faith, follow the Code of + Conduct, and avoid publicising private moderation or security material. + +If a moderator has a personal conflict with a report, they must disclose it +and hand the decision to another moderator or maintainer. Retaliation against +a reporter, reviewer, or person requesting reconsideration is prohibited. + +## 6. Relationship to Other Policies + +- The **Code of Conduct** defines unacceptable conduct and the expected + community standard. +- The **security policy** governs private vulnerability reports and disclosure. +- **Governance policies** govern project decisions, roles, access, and records. +- The **privacy and retention policies** govern personal data and record + lifetimes. + +When documents appear to conflict, moderators preserve safety first, document +the conflict, and ask a maintainer to resolve it through the project's normal +governance process. + +## 7. Change Log + +| Version | Date | Change | +| --- | --- | --- | +| 1.0.0 | 2026-09-29 | Initial moderation principles, actions, transparency, and reconsideration policy. |