diff --git a/Governance/community/CONTRIBUTOR_AGREEMENT.md b/Governance/community/CONTRIBUTOR_AGREEMENT.md new file mode 100644 index 00000000..d31b7640 --- /dev/null +++ b/Governance/community/CONTRIBUTOR_AGREEMENT.md @@ -0,0 +1,79 @@ +# Contributor Agreement + +| Field | Value | +| --- | --- | +| Document | `Governance/community/CONTRIBUTOR_AGREEMENT.md` | +| Status | Active | +| Version | 1.0.0 | +| Owner | Maintainer Team | +| Last reviewed | 2026-10-17 | +| Review cadence | Every 12 months | +| Applies to | Everyone who contributes code, documentation, or other material to `rinafcode/teachLink_backend` | +| Related | [`policies/DCO.md`](../policies/DCO.md) · [`policies/CONTRIBUTOR_SIGNOFF.md`](../policies/CONTRIBUTOR_SIGNOFF.md) · [`policies/LICENSING.md`](../policies/LICENSING.md) | + +This document is the human-readable overview of what a contributor agrees to +when they contribute to the project. It is not a contract and it adds no +obligation beyond the licence and the sign-off described below; the authoritative +texts are [`policies/DCO.md`](../policies/DCO.md), +[`policies/CONTRIBUTOR_SIGNOFF.md`](../policies/CONTRIBUTOR_SIGNOFF.md), and the +project's [`LICENSE`](../../LICENSE). + +## 1. What contributors agree to + +By contributing, you agree that: + +1. **You have the right to contribute the work.** The contribution is your own + original work, or you have permission to submit it, and it does not knowingly + infringe anyone's copyright, patent, or trademark. +2. **Your contribution is licensed under the project's licence.** The licence for + this repository is described in [`policies/LICENSING.md`](../policies/LICENSING.md) + and the root [`LICENSE`](../../LICENSE). Inbound contributions are licensed + under the same terms as outbound, so the project can distribute them. +3. **You follow the Code of Conduct.** Participation is governed by + [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md) and enforced under + [`COC_ENFORCEMENT.md`](../COC_ENFORCEMENT.md). +4. **You follow the contribution process.** Branching, commits, the PR checklist, + and review expectations are defined in [`CONTRIBUTING.md`](../../CONTRIBUTING.md). +5. **You will not contribute secrets or third-party material you cannot license.** + Do not submit credentials, `.env` values, customer data, or code copied from a + source you do not have the right to relicense. + +## 2. Sign-off mechanism + +The project uses the **Developer Certificate of Origin (DCO)**, not a CLA. You +sign off by adding a `Signed-off-by:` trailer to each commit: + +``` +Signed-off-by: Full Name +``` + +`git commit -s` adds it for you. The trailer certifies the statements in §1 and +is described fully in [`policies/DCO.md`](../policies/DCO.md). Commits without a +valid sign-off may be asked to amend before merge. + +## 3. Where records are kept + +- **The commits themselves are the record.** The `Signed-off-by` trailer in the + repository history is the primary, durable record of each contribution and its + sign-off. +- **Pull requests** keep the review trail: who proposed the change, who reviewed + it, and the discussion that led to the merge. +- **No separate private registry** of contributors is maintained for the DCO; + the git history is sufficient and auditable. Maintainer-role records, if any, + live with the governance documents in this folder. +- Personal data in a sign-off is limited to the name and email you choose to + publish in the commit, in line with the project's data-minimisation principle. + +## 4. If you change your mind + +You may stop contributing at any time. Because the DCO grants an irrevocable +licence for contributions already made, merged contributions remain part of the +project under the project's licence. If you have a concern about a specific +contribution, raise it with the maintainers rather than rewriting published +history. + +## 5. Change log + +| Date | Version | Change | +| --- | --- | --- | +| 2026-10-17 | 1.0.0 | Initial release. | diff --git a/Governance/compliance/ACCESSIBILITY_STATEMENT.md b/Governance/compliance/ACCESSIBILITY_STATEMENT.md new file mode 100644 index 00000000..c2a5f74b --- /dev/null +++ b/Governance/compliance/ACCESSIBILITY_STATEMENT.md @@ -0,0 +1,73 @@ +# Accessibility Statement Governance + +| Field | Value | +| --- | --- | +| Document | `Governance/compliance/ACCESSIBILITY_STATEMENT.md` | +| Status | Active | +| Version | 1.0.0 | +| Owner | Maintainer Team | +| Last reviewed | 2026-10-17 | +| Review cadence | Every 12 months, and after any major UI change | +| Applies to | The public accessibility statement for the platform's user-facing surfaces | +| Related | [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md) · [`community/INCLUSIVE_LANGUAGE.md`](../community/INCLUSIVE_LANGUAGE.md) | + +This document defines the **stated conformance level**, the **feedback channel**, +and the **review cadence** for the project's accessibility statement. It governs +the statement's process; the published statement itself may live outside this +repository, but it must follow the rules below so that what we claim matches what +we do. + +## 1. Stated conformance level + +- Our target is **WCAG 2.2 Level AA** for user-facing web surfaces of the + platform. This is the level the published statement must claim. +- **Claims must be evidence-based.** The statement may only claim a conformance + level that a documented evaluation supports. Where we are not yet conformant, + the statement must say so plainly, list the known gaps, and give the + remediation plan rather than overstating conformance. +- **Partial conformance is stated as partial.** If some surfaces meet AA and + others do not, name the exceptions. A blanket "fully conformant" claim is not + permitted while known gaps exist. +- **Third-party content** that the project does not control is called out + separately, with the effort made to influence it. + +## 2. What the statement must include + +At minimum: the conformance target and current status; the date of the most recent +evaluation and who performed it; known limitations and the plan to fix them; the +feedback channel in §3; and the review cadence in §4. It should be reachable from +the product's footer or help pages, not buried in a repository. + +## 3. Feedback channel + +- Users can report an accessibility barrier through a **named, monitored + channel** — a dedicated email address and the issue tracker — published in the + statement itself. +- A report is **acknowledged within 3 business days** and triaged under + [`processes/TRIAGE.md`](../processes/TRIAGE.md). Reports that describe a + blocker for assistive-technology users are prioritised. +- Where a barrier has no quick fix, the report is tracked as an issue labelled + for accessibility, with a target and an owner, and the reporter is told where + to follow it. +- The feedback channel is not used for security reports; those follow + [`SECURITY_POLICY.md`](../SECURITY_POLICY.md). +- The channel is open to everyone and the response is given respectfully, as + required by [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md). + +## 4. Review cadence + +- The statement is **reviewed at least every 12 months**, and after any major + change to a user-facing surface, so it does not drift from reality. +- Each review checks the conformance claim against a fresh evaluation, confirms + the feedback channel still works, and updates the "last reviewed" date. +- The review is recorded in this document's change log with the reviewer and the + outcome. If a gap is found, an issue is opened rather than only editing the + statement. +- If a review is not performed within the cadence, the statement is amended to + say the last evaluation is older than one year. + +## 5. Change log + +| Date | Version | Change | +| --- | --- | --- | +| 2026-10-17 | 1.0.0 | Initial release. | diff --git a/Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md b/Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md new file mode 100644 index 00000000..caefa001 --- /dev/null +++ b/Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md @@ -0,0 +1,88 @@ +# Privacy Policy Governance + +| Field | Value | +| --- | --- | +| Document | `Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md` | +| Status | Active | +| Version | 1.0.0 | +| Owner | Maintainer Team, in consultation with the project's data-protection contact | +| Last reviewed | 2026-10-17 | +| Review cadence | Every 6 months, and on any material change to data processing | +| Applies to | The public privacy policy that describes how the platform handles personal data | +| Related | [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md) · [`domains/DATA_RETENTION.md`](../domains/DATA_RETENTION.md) · [`compliance/DPA_TEMPLATE.md`](DPA_TEMPLATE.md) | + +This document defines **who owns** the project's privacy policy, **how** it is +updated and reviewed, and **how** it is versioned. It governs the process, not +the legal content; the published policy itself may live outside this repository, +but every change to it follows the process below. + +## 1. Who owns the privacy policy + +- The **maintainer team** owns the privacy policy and is accountable for keeping + it accurate and published. See [`roles/MAINTAINER.md`](../roles/MAINTAINER.md). +- A **data-protection contact** (a named maintainer or an external advisor acting + for the project) is responsible for the substantive review: whether the policy + matches what the system actually does. +- The **treasurer** reviews any part of the policy that touches payment or + financial data, with the treasurer's duties in [`roles/TREASURER.md`](../roles/TREASURER.md). +- Where processing is performed by a processor, the relationship is recorded + using [`compliance/DPA_TEMPLATE.md`](DPA_TEMPLATE.md). + +## 2. What the policy must cover + +The policy, at minimum, must state: + +- what personal data is collected and for what purpose; +- the legal basis relied on for each processing activity; +- how long data is retained and how it is deleted (see + [`domains/DATA_RETENTION.md`](../domains/DATA_RETENTION.md) and + [`policies/DATA_DELETION.md`](../policies/DATA_DELETION.md)); +- who data is shared with, including sub-processors and any cross-border transfer + (see [`policies/DATA_RESIDENCY.md`](../policies/DATA_RESIDENCY.md)); +- the data-subject rights available and how to exercise them, including consent + withdrawal (see [`policies/CONSENT_MANAGEMENT.md`](../policies/CONSENT_MANAGEMENT.md)); +- how children's data is handled (see [`compliance/CHILDRENS_DATA.md`](CHILDRENS_DATA.md)); +- the contact channel for privacy questions and complaints. + +The classification vocabulary used to describe the data is defined in +[`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md). + +## 3. Update and review process + +1. **Trigger.** A change is opened when the system's data handling changes, when + a new processor or transfer is introduced, when a legal requirement changes, + or on the scheduled review date, whichever is first. +2. **Proposal.** An issue is opened describing the change and the processing + activity it reflects. The change is made as a pull request that stays within + `Governance/` for the process record. +3. **Substantive review.** The data-protection contact confirms the policy still + matches the system. A change that alters a legal basis, a retention period, + or a transfer also requires maintainer approval. +4. **Cross-check.** The reviewer confirms the policy is consistent with + [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md) and + [`domains/DATA_RETENTION.md`](../domains/DATA_RETENTION.md) and that the + promises made are implementable. +5. **Approval.** At least one maintainer who is not the author approves, then the + change is merged and, when it affects users, published as §4 requires. +6. **Scheduled review.** Even with no trigger, the policy is reviewed at least + **every 6 months** and the review date recorded here. + +## 4. Versioning and notification + +- Every published policy carries a **version** (semantic `MAJOR.MINOR.PATCH`) and + an **effective date**. Material changes increment `MAJOR`; clarifications + increment `MINOR`; typo fixes increment `PATCH`. +- The current version and its history are kept **in this document's change log** + and in the published policy itself, so a user can see what changed and when. +- A material change is notified to users through the product's normal notice + channel (in-product notice or email to registered contacts) **before** it takes + effect, with a reasonable advance window, unless a legal requirement dictates + otherwise. +- Prior versions are kept for an audit trail; do not delete a superseded version + from the history. + +## 5. Change log + +| Date | Version | Change | +| --- | --- | --- | +| 2026-10-17 | 1.0.0 | Initial release. | diff --git a/Governance/compliance/TERMS_OF_SERVICE_GOVERNANCE.md b/Governance/compliance/TERMS_OF_SERVICE_GOVERNANCE.md new file mode 100644 index 00000000..c739d6b4 --- /dev/null +++ b/Governance/compliance/TERMS_OF_SERVICE_GOVERNANCE.md @@ -0,0 +1,89 @@ +# Terms of Service Governance + +| Field | Value | +| --- | --- | +| Document | `Governance/compliance/TERMS_OF_SERVICE_GOVERNANCE.md` | +| Status | Active | +| Version | 1.0.0 | +| Owner | Maintainer Team, with legal review where required | +| Last reviewed | 2026-10-17 | +| Review cadence | Every 12 months, and on any material change to the service | +| Applies to | The public terms of service that govern use of the platform | +| Related | [`compliance/PRIVACY_POLICY_GOVERNANCE.md`](PRIVACY_POLICY_GOVERNANCE.md) · [`policies/DEPRECATION.md`](../policies/DEPRECATION.md) | + +This document defines **who owns** the terms of service, the **update and +approval process**, and the **user-notification rule** for changes. It governs +the process; the published terms themselves may live outside this repository, but +every change follows the process below. + +## 1. Who owns the terms + +- The **maintainer team** owns the terms and is accountable for keeping them + current and published. +- **Legal review** is required for any change that alters liability, dispute + resolution, acceptable use, or termination. Where the project has no in-house + counsel, the maintainers obtain external review before publishing. +- **Product owners** of a feature that changes what users may do must flag the + change so the terms can be updated before the feature ships. +- The **privacy policy** is owned separately under + [`compliance/PRIVACY_POLICY_GOVERNANCE.md`](PRIVACY_POLICY_GOVERNANCE.md); the + two documents must not contradict each other. + +## 2. What the terms must cover + +At minimum: acceptable use, account responsibilities, intellectual-property and +licence terms, fees and payment terms where applicable, availability and support +expectations, suspension and termination, disclaimers and limitation of +liability, governing law, and how disputes are resolved. Feature-specific rules +(for example rate limits or API fair use) must be reachable from the terms rather +than existing only in code. + +## 3. Update and approval process + +1. **Trigger.** A change is opened when a feature changes user obligations, when + a legal or regulatory requirement changes, or on the scheduled review date. +2. **Proposal.** An issue describes the change and the user-facing behaviour it + reflects. The change to the process record is made as a pull request inside + `Governance/`. +3. **Review.** + - A maintainer who is not the author confirms the terms match the service. + - Legal review is required for the categories listed in §1. + - The privacy-policy owner is consulted if the change touches data use. +4. **Approval.** A material change requires approval by at least **two + maintainers**, one of whom must not be the author. Legal sign-off, where + required, is recorded on the issue. +5. **Effective date.** Approval sets an **effective date** that allows the notice + period in §4 to run before the new terms bind users. +6. **Scheduled review.** Even without a trigger, the terms are reviewed at least + **every 12 months**. + +## 4. User-notification rule + +- **Material changes are notified before they take effect.** A reasonable advance + notice is given through the product's standard channel (in-product notice or + email to registered contacts) before the effective date, unless a legal or + security requirement dictates a shorter or immediate change. +- **The notice must say what changed and when it takes effect**, and link the new + version. It is not enough to change the document silently. +- **Non-material changes** (typo fixes, formatting, clarifying wording that does + not change meaning) may be published without a notice but still increment the + version. +- **Where continued use constitutes acceptance**, the notice must say so and give + users a way to stop using the service. Changes that increase a user's + obligations without a lawful basis to impose them cannot rely on continued use + alone. + +## 5. Versioning + +- Every published version carries a version and an effective date. Material + changes increment the major version; clarifications the minor; typo fixes the + patch. +- The version history and the notice sent for each material change are recorded + in this document's change log and in the published terms. +- Superseded versions are retained for the audit trail. + +## 6. Change log + +| Date | Version | Change | +| --- | --- | --- | +| 2026-10-17 | 1.0.0 | Initial release. |