From 7ffe484af26a36cd8650af47f15cb24e6fd9177d Mon Sep 17 00:00:00 2001 From: Essther77-git Date: Fri, 16 Oct 2026 09:51:02 +0100 Subject: [PATCH] docs(governance): add vendor risk, record retention, access review and mentorship policies --- Governance/community/MENTORSHIP_PROGRAM.md | 87 +++++++++++++++++++++ Governance/policies/ACCESS_REVIEW.md | 83 ++++++++++++++++++++ Governance/policies/RECORD_RETENTION.md | 89 ++++++++++++++++++++++ Governance/policies/VENDOR_RISK.md | 89 ++++++++++++++++++++++ 4 files changed, 348 insertions(+) create mode 100644 Governance/community/MENTORSHIP_PROGRAM.md create mode 100644 Governance/policies/ACCESS_REVIEW.md create mode 100644 Governance/policies/RECORD_RETENTION.md create mode 100644 Governance/policies/VENDOR_RISK.md diff --git a/Governance/community/MENTORSHIP_PROGRAM.md b/Governance/community/MENTORSHIP_PROGRAM.md new file mode 100644 index 00000000..c77085ef --- /dev/null +++ b/Governance/community/MENTORSHIP_PROGRAM.md @@ -0,0 +1,87 @@ +# Mentorship Program Policy + +## Purpose + +This policy sets up a voluntary mentorship program that helps newer contributors +grow into effective members of the TeachLink Web community. It states how +mentors and mentees are matched, what each can expect, and how long a mentorship +lasts, so participation is fair, safe, and useful to both sides. + +## Scope + +This policy applies to contributors who take part in the mentorship program as +mentors or mentees. It does not replace the [onboarding +process](../processes/ONBOARDING.md) every contributor receives, the [Review +Policy](../policies/REVIEW_POLICY.md) that applies to all changes, or the [Code +of Conduct](../CODE_OF_CONDUCT.md), which governs every mentorship interaction. + +## Matching Mentors and Mentees + +Matching is intended to be simple, voluntary, and fair: + +- **Mentors** are contributors with a record of merged contributions and good + standing under the [Code of Conduct](../CODE_OF_CONDUCT.md), who volunteer and + are confirmed by a maintainer. +- **Mentees** are contributors who ask to join and describe their goals, such as + learning an area of the codebase or growing toward a project role. +- Matches are made by a maintainer or program coordinator using the mentee's + goals, the mentor's expertise, time zone and availability, and spoken + languages. +- A mentor does not mentor someone they have a conflict of interest with (see + the [Conflict of Interest policy](../policies/CONFLICT_OF_INTEREST.md)) and + does not mentor more people than they can support, normally no more than two + at a time. +- Either party may decline a match or ask for a different one at any point + without giving a reason. + +## Expectations + +Participants agree to the following: + +- **Mentors** respond within an agreed time, share knowledge and context, give + constructive feedback, point to project resources, and help mentees find good + first work. Mentors do not do the mentee's work or guarantee roles or + approvals. +- **Mentees** state their goals, come prepared, act on feedback, ask questions, + and tell the mentor early if their availability changes. +- **Both** keep conversations respectful and professional, keep private matters + private, and raise any concern about behaviour through [Code of Conduct + reporting](../COC_REPORTING.md). +- Mentorship happens in public project channels where possible; one-to-one + conversations stay within the [Communication + Norms](../policies/COMMUNICATION_NORMS.md). +- Mentorship never affects review outcomes: a mentor's relationship with a + mentee does not exempt either from the normal independent review. + +## Duration and Review + +A mentorship has a defined shape: + +- A standard mentorship lasts 3 months and can be extended once by up to 3 + months by mutual agreement. +- At the midpoint and at the end, the pair and the coordinator check progress + against the mentee's goals and the experience of both sides. +- A mentorship ends early if either party asks, if availability is lost, or if a + conduct concern is upheld. +- At the end, the mentee is encouraged to share what they learned, and the pair + may be recognised under the [Recognition](../RECOGNITION.md). +- The program is reviewed annually using anonymous participant feedback; the + results inform changes to this policy. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- A maintainer acts as program coordinator, keeps the list of participants, and + handles matching and early-ending requests. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when mentees reach their stated goals, mentors feel +supported rather than overloaded, and the program remains voluntary, respectful, +and open to new participants. diff --git a/Governance/policies/ACCESS_REVIEW.md b/Governance/policies/ACCESS_REVIEW.md new file mode 100644 index 00000000..fbd72418 --- /dev/null +++ b/Governance/policies/ACCESS_REVIEW.md @@ -0,0 +1,83 @@ +# Access Review Policy + +## Purpose + +This policy requires periodic review of who has access to what in the TeachLink +Web project, so that permissions match current roles and stale or excessive +access is removed. Regular review is the main defence against access that +outlives the need for it. + +## Scope + +This policy applies to every resource where access is granted to people or +automation: the GitHub organization and repository permissions and teams, +protected-branch and environment settings, CI/CD secrets and deploy keys, +package registry and hosting accounts, analytics and monitoring tools, and +shared mailboxes. Roles themselves are described in the [Maintainer +role](../roles/MAINTAINER.md) and the [Moderator role](../roles/MODERATOR.md). + +## Review Cadence + +Access is reviewed on a fixed schedule and on specific events: + +- **Quarterly:** all administrative and write access, secrets, deploy keys, and + bot or automation accounts. +- **Every 6 months:** read access to private resources and tool accounts with + limited privileges. +- **On event:** a role change, a contributor leaving or becoming inactive, a + suspected compromise, or a vendor change triggers an immediate review of the + affected access. +- Each review is recorded with the date, reviewer, scope, and outcome in the + project's private maintainer records. + +## Scope per Resource + +Reviewers check each resource against least privilege: + +- **Repository and organization.** Every member's role matches their current + governance role; teams, outside collaborators, and installed apps and tokens + are still needed. +- **Protected branches and environments.** Who can push, merge, approve, and + deploy matches the [Review Policy](../policies/REVIEW_POLICY.md) and release + rules. +- **Secrets and keys.** Each secret has an owner and a purpose, was rotated + within its period, and is not shared across environments without need. +- **Third-party tools.** Each tool account lists its administrators, and former + contributors are removed. +- **Automation.** Tokens and apps have the narrowest scopes that work and an + owner who can answer for them. +- Reviewers do not review their own access; another maintainer signs off. + +## Revocation Process + +Access that is not justified is removed: + +- The reviewer lists the access to remove and the reason; the owner confirms or + contests within 5 business days. +- Removal is carried out promptly, and anything that was shared (secrets, keys, + tokens) is rotated rather than only deleted. +- Emergency revocation for a suspected compromise happens first and is explained + afterwards; it is then handled under the [Security + Policy](../SECURITY_POLICY.md). +- Role reductions follow the project's inactivity and emeritus practices, and + the person is thanked and told how to regain access. +- Each revocation is logged, and the next review checks that the access really + is gone. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- A maintainer is assigned to run each quarterly review and report the outcome + to the other maintainers. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when reviews happen on schedule, when no one holds access +their role does not need, and when departures and compromises lead to prompt +revocation and rotation. diff --git a/Governance/policies/RECORD_RETENTION.md b/Governance/policies/RECORD_RETENTION.md new file mode 100644 index 00000000..1d3d0e5f --- /dev/null +++ b/Governance/policies/RECORD_RETENTION.md @@ -0,0 +1,89 @@ +# Record Retention and Legal Hold Policy + +## Purpose + +This policy sets how long TeachLink Web keeps records, how a record is preserved +when a legal or investigative obligation requires it, and how records are +disposed of when their retention ends. It keeps the project from holding data +longer than needed while ensuring records that matter can be produced. + +## Scope + +This policy applies to records the project creates or controls: governance and +decision records, moderation and conduct case files, security advisories and +incident records, financial records, access and audit logs, and personal data +held for users and contributors. Public repository history (commits, issues, +pull requests) is a public record and is not deleted under this policy except as +the [Security Policy](../SECURITY_POLICY.md) or a lawful erasure request +requires. + +## Retention Schedule + +The default retention periods are: + +- **Governance and decision records** (RFCs, meeting minutes, votes): kept for + the life of the project. +- **Security advisories and incident records:** kept for 7 years. +- **Conduct and moderation case files:** kept for 3 years after the case closes, + or longer where a sanction remains in force. Access is limited to those + handling the case. +- **Financial and treasury records:** kept for 7 years, or longer if local law + requires. +- **Access and audit logs:** kept for 12 months online, then archived or + deleted. +- **Personal data of users:** kept only while the account or purpose is active, + then deleted or anonymised within 30 days of the end of that purpose, unless + another row of this schedule or the law requires longer. +- A shorter or longer period may be set for a category by a recorded maintainer + decision. Where laws conflict, the longer legal duty applies and is noted. + +## Legal Hold + +A legal hold suspends normal disposal for records that may be relevant to a +legal claim, investigation, regulatory request, or dispute: + +- Any maintainer who learns of a reasonably anticipated claim or a formal + request notifies the lead maintainers privately and promptly. +- The lead maintainers decide whether to issue a hold, define its scope (people, + systems, date range, record types), and record it with the date. +- Custodians are told in writing to stop deleting in-scope records, including + automated deletion jobs, which are suspended for the scope of the hold. +- Holds are reviewed every 6 months and released in writing only when the lead + maintainers confirm the matter is concluded. Records then return to the normal + schedule. +- Information about a hold is need-to-know and is not discussed in public + channels. + +## Disposal Rules + +When a retention period ends and no hold applies: + +- Records are deleted or irreversibly anonymised; "archived forever" is not a + disposal method. +- Deletion covers copies: backups are purged at their next rotation, and + processors are told to delete their copies. +- Disposal is carried out by the record owner, logged with the category, date, + and method (but not the content), and spot-checked by a second maintainer. +- Records of sensitive categories are disposed of by methods that prevent + recovery. +- Records are never disposed of early to avoid a request, a review, or a hold; + doing so is a conduct matter under the [Code of + Conduct](../CODE_OF_CONDUCT.md). + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The retention schedule is reviewed at least once a year, and the log of holds + and disposals is reviewed at the same time. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when records are kept for the stated periods and no longer, +when holds are issued and released in writing, and when disposal is logged and +verifiable. diff --git a/Governance/policies/VENDOR_RISK.md b/Governance/policies/VENDOR_RISK.md new file mode 100644 index 00000000..4fd9775b --- /dev/null +++ b/Governance/policies/VENDOR_RISK.md @@ -0,0 +1,89 @@ +# Vendor Risk Management Policy + +## Purpose + +This policy defines how TeachLink Web assesses and monitors the third-party +vendors and services it depends on. It gives maintainers a consistent way to +decide whether a vendor is acceptable, how closely to watch it, and when to stop +using it, so a dependency never becomes a hidden risk to users or contributors. + +## Scope + +This policy applies to any external service, platform, or supplier that +processes project or user data, runs project code, hosts project assets, or sits +in the build and release path: hosting and CDN providers, analytics and +error-tracking services, authentication and payment providers, CI services, and +package registries. Embedded browser scripts are additionally governed by the +[Third-Party Scripts governance](../domains/THIRD_PARTY_SCRIPTS.md) and +dependency licences by the [Third-Party Licenses +policy](../policies/THIRD_PARTY_LICENSES.md). + +## Vetting Criteria + +Before a vendor is adopted, a maintainer records an assessment in the pull +request or issue that introduces it, covering: + +- **Necessity.** What the vendor does that the project cannot reasonably do + itself, and the alternatives considered. +- **Data.** The categories of data the vendor will receive, where it is stored, + and whether personal data is involved. +- **Security.** Published security practices and certifications, breach history, + and how the vendor handles vulnerability reports. +- **Reliability.** Availability record, support terms, and how the project + degrades if the vendor is down. +- **Legal.** Licence and terms of service compatibility with the project, data + processing terms where personal data is involved, and the vendor's + jurisdiction. +- **Exit.** How data and configuration can be exported and the vendor replaced. +- A vendor that fails a necessity, data, or security check is not adopted + without an explicit, recorded exception approved by two maintainers. + +## Risk Tiers + +Each approved vendor is placed in a tier that sets how closely it is reviewed: + +- **Tier 1 - Critical.** Handles personal data, credentials, or payments, or + whose failure stops the product or release process. Requires the full + assessment, a recorded owner, and a documented contingency plan. +- **Tier 2 - Important.** Has meaningful access to project systems or + non-sensitive user data, or whose failure degrades the product. Requires the + standard assessment and a recorded owner. +- **Tier 3 - Low.** Has no access to user data or credentials and is easily + replaced (for example a development convenience tool). Requires a short note + recording what it is used for. +- A vendor takes the highest tier of any role it plays. A change in how a vendor + is used, such as sending it new data, triggers a re-tiering before the change + ships. + +## Review Cadence + +Reviews keep assessments current: + +- Tier 1 vendors are reviewed at least every 6 months, Tier 2 every 12 months, + and Tier 3 every 24 months or when they change. +- An unscheduled review is triggered by a vendor security incident, an + acquisition or change of terms, a loss of required certification, repeated + outages, or a new type of data being sent. +- Each review confirms the tier, the data shared, the owner, the contingency + plan, and whether the vendor is still needed; unused vendors are removed and + their access revoked. +- A vendor that no longer meets the criteria is placed on a time-boxed + remediation plan or replaced, and the decision is recorded. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- Each vendor has a named maintainer owner, and the vendor register is reviewed + as a whole at least once a year. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when every vendor has a recorded assessment, tier, and +owner, when reviews happen on schedule, and when a vendor incident leads to a +prompt, documented decision rather than a surprise.