docs(governance): add vendor risk, record retention, access review and mentorship policies

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.

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.

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.

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.