RUKAYAT-CODER · Oct 17, 2026 · Oct 17, 2026
diff --git a/Governance/community/MENTORSHIP_PROGRAM.md b/Governance/community/MENTORSHIP_PROGRAM.md
@@ -0,0 +1,91 @@
+# Mentorship Program
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/community/MENTORSHIP_PROGRAM.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 6 months |
+| Applies to | Mentors and mentees taking part in the project's mentorship program |
+| Related | [`processes/ONBOARDING.md`](../processes/ONBOARDING.md) · [`roles/CONTRIBUTOR.md`](../roles/CONTRIBUTOR.md) · [`policies/GOOD_FIRST_ISSUE.md`](GOOD_FIRST_ISSUE.md) |
+
+The mentorship program pairs an experienced contributor with a newcomer for a
+fixed period, so that a first contribution is a supported one rather than a
+guessing game. This document describes how pairs are made, what each side is
+expected to do, and how the pairing is reviewed and closed.
+
+## 1. How mentors and mentees are matched
+
+- **The program is opt-in for both sides.** A mentor volunteers and a mentee
+  asks to join; no one is assigned against their wishes.
+- **Matching is by interest and capacity, not seniority alone.** A mentee states
+  the area they want to work in (for example, the NestJS API layer, tests,
+  documentation, or database work); a mentor with that experience and available
+  time is paired with them.
+- **Start from a good first issue.** The pair normally begins from an issue
+  labelled as suitable for newcomers, following
+  [`policies/GOOD_FIRST_ISSUE.md`](GOOD_FIRST_ISSUE.md) and
+  [`policies/FIRST_TIME_CONTRIBUTOR.md`](FIRST_TIME_CONTRIBUTOR.md).
+- **Kept small.** A mentor takes on at most one or two mentees at a time so the
+  pairing stays real rather than nominal.
+- **Coordination.** A maintainer keeps the pair list, the area, and the start
+  date; the list lives with the project's contributor records.
+
+## 2. Expectations
+
+**The mentor:**
+
+- makes the first contact and agrees a working rhythm with the mentee;
+- explains the project's conventions and points at
+  [`processes/ONBOARDING.md`](../processes/ONBOARDING.md) and
+  [`CONTRIBUTING.md`](../../CONTRIBUTING.md);
+- reviews the mentee's work with the tone in
+  [`community/REVIEW_ETIQUETTE.md`](REVIEW_ETIQUETTE.md), and lets the mentee do
+  the work rather than taking it over;
+- is responsive, and says when they will be unavailable;
+- treats the mentee as a peer, not a task queue.
+
+**The mentee:**
+
+- drives their own work and asks questions rather than waiting silently;
+- reads the contribution guide and tries the tooling before asking;
+- takes on feedback and iterates;
+- keeps the mentor informed of blockers;
+- respects the mentor's time — batch questions, and use public channels where
+  the answer helps others.
+
+**Both** follow [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md) and use public
+channels for technical discussion, so the answers benefit the wider community.
+
+## 3. Duration and review
+
+- **Default duration is one contribution cycle**, typically **6–8 weeks**,
+  ending when the mentee's first change is merged or the period closes.
+- **A short check-in at the midpoint** confirms the pairing is working; either
+  side may ask to change mentor, area, or pace without it being a failure.
+- **A closing review** records what the mentee worked on, what they learned, and
+  whether they want to continue independently or take another pairing.
+- **Renewal is optional.** A successful pairing may be renewed for a further
+  cycle if both sides want it and the mentor has capacity.
+- **A graduated mentee is a new contributor**, and progression afterward follows
+  [`processes/PROMOTION_CRITERIA.md`](../processes/PROMOTION_CRITERIA.md).
+- **Mentor recognition.** Mentoring is credited under
+  [`RECOGNITION.md`](../RECOGNITION.md); mentors who sustain the program are
+  noted in the maintainer records.
+
+## 4. When it is not working
+
+- Either side may end a pairing at any time by telling the programme
+  coordinator; no reason is required.
+- If a pairing raises a conduct concern, it is handled under
+  [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md), not within the pair.
+- A mentor who repeatedly does not respond is offered support or replaced; the
+  mentee is never left without a contact.
+
+## 5. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |
diff --git a/Governance/community/OFFICE_HOURS.md b/Governance/community/OFFICE_HOURS.md
@@ -0,0 +1,80 @@
+# Office Hours
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/community/OFFICE_HOURS.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 6 months |
+| Applies to | Maintainers who host and contributors who attend office hours |
+| Related | [`processes/MEETING_CADENCE.md`](../processes/MEETING_CADENCE.md) · [`policies/COMMUNICATION_NORMS.md`](../policies/COMMUNICATION_NORMS.md) |
+
+Office hours are a recurring, open drop-in where contributors can ask a
+maintainer questions in real time. They complement, and do not replace, the
+asynchronous channels in
+[`policies/COMMUNICATION_NORMS.md`](../policies/COMMUNICATION_NORMS.md).
+
+## 1. Schedule and format
+
+- **Cadence.** Office hours run **once every two weeks**, alternating between two
+  time slots so that contributors in different regions can attend at least one
+  per month. The exact times are published on the repository's community page and
+  kept in step with
+  [`processes/MEETING_CADENCE.md`](../processes/MEETING_CADENCE.md).
+- **Duration.** 60 minutes, unless the host announces otherwise in advance.
+- **Channel.** A public voice/video room announced with the session; a text
+  channel is open in parallel for those who cannot join by voice.
+- **Format.** An open floor with a loose agenda:
+  1. a two-minute recap of open topics, drawn from submissions (§3);
+  2. the bulk of the time on live questions;
+  3. a close that records actions and links them to issues.
+- **Recorded by default?** No. Sessions are not recorded unless every participant
+  agrees; the written notes are the record either way.
+- **Cancellation.** If no host is available, the session is cancelled on the
+  community page at least 24 hours ahead.
+
+## 2. Who hosts
+
+- A **maintainer hosts** each session — see
+  [`roles/MAINTAINER.md`](../roles/MAINTAINER.md) — and rotates the duty so the
+  load is shared.
+- A qualified contributor may host with a maintainer's agreement; the maintainer
+  remains accountable for any decision made.
+- The host is responsible for: publishing the session, keeping time, taking
+  notes, and ensuring that any decision or action is captured in an issue.
+- If a topic needs a decision rather than a discussion, the host routes it to the
+  correct process (an issue, an RFC, or a vote) rather than deciding ad hoc. See
+  [`processes/PROPOSAL_LIFECYCLE.md`](../processes/PROPOSAL_LIFECYCLE.md).
+
+## 3. How topics are submitted
+
+- **In advance, via an issue or the pinned thread.** Anyone may add a topic
+  before the session; a topic should name the question, the relevant issue or PR,
+  and whether it needs a decision or just discussion.
+- **Live topics are welcome.** Time is reserved for questions that come up during
+  the session.
+- **Priority.** Topics with a linked issue and a clear question are taken first;
+  open-ended design debates without a link may be deferred to a dedicated
+  discussion, following
+  [`policies/COMMUNICATION_NORMS.md`](../policies/COMMUNICATION_NORMS.md) §3.2.
+- **No support-only sessions.** Office hours are for contributors and project
+  work; end-user support stays in the community support channel.
+
+## 4. After the session
+
+- The host posts short notes within **2 business days**: topics covered,
+  decisions, and action items with an owner and a due date.
+- Action items become issues so they are tracked like any other work; a decision
+  that changes a documented rule follows the normal change process.
+- Sensitive matters (security, conduct, personal data) are **not** discussed in
+  office hours; the host redirects them to the private channels in
+  [`SECURITY_POLICY.md`](../SECURITY_POLICY.md) and
+  [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md).
+
+## 5. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |
diff --git a/Governance/community/WELCOME_GUIDE.md b/Governance/community/WELCOME_GUIDE.md
@@ -0,0 +1,77 @@
+# Newcomer Welcome Guide
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/community/WELCOME_GUIDE.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 6 months |
+| Applies to | Anyone making their first contribution to `rinafcode/teachLink_backend` |
+| Related | [`processes/ONBOARDING.md`](../processes/ONBOARDING.md) · [`CONTRIBUTING.md`](../../CONTRIBUTING.md) · [`community/MENTORSHIP_PROGRAM.md`](MENTORSHIP_PROGRAM.md) |
+
+Welcome. This guide is the shortest path from "I just found this project" to "my
+first pull request is open". It assumes no prior knowledge of the codebase.
+
+## 1. Your first steps
+
+1. **Read the ground rules.** [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md) and
+   [`CONTRIBUTING.md`](../../CONTRIBUTING.md) — the latter is authoritative for
+   branching, commits, the PR checklist, and review expectations.
+2. **Get the project running.** Follow the setup instructions in the
+   [`README.md`](../../README.md). If a step is broken, that is a useful bug
+   report — open an issue.
+3. **Pick a first issue.** Look for the labels for newcomers, described in
+   [`policies/GOOD_FIRST_ISSUE.md`](GOOD_FIRST_ISSUE.md) and
+   [`policies/FIRST_TIME_CONTRIBUTOR.md`](FIRST_TIME_CONTRIBUTOR.md). Comment on
+   the issue to say you are taking it, so two people do not duplicate work.
+4. **Open a draft pull request early.** A draft PR that links the issue lets a
+   maintainer course-correct before you finish, which is faster for everyone.
+5. **Ask for a mentor if you want one.** See
+   [`community/MENTORSHIP_PROGRAM.md`](MENTORSHIP_PROGRAM.md).
+
+## 2. Key resources
+
+| Resource | What it is for |
+| --- | --- |
+| [`README.md`](../../README.md) | What the project is and how to run it. |
+| [`CONTRIBUTING.md`](../../CONTRIBUTING.md) | Branching, commits, PR checklist, review SLA, CI. |
+| [`docs/testing-standards.md`](../../docs/testing-standards.md) | Unit and E2E standards, mocking, coverage. |
+| [`Governance/README.md`](../README.md) | The index of governance documents. |
+| [`policies/COMMUNICATION_NORMS.md`](../policies/COMMUNICATION_NORMS.md) | Tone, official channels, response times. |
+| [`community/REVIEW_ETIQUETTE.md`](REVIEW_ETIQUETTE.md) | What to expect from review, and how to give it. |
+| [`processes/ONBOARDING.md`](../processes/ONBOARDING.md) | The onboarding path and its owners. |
+
+## 3. Where to get help
+
+- **General questions:** the [Telegram community](https://t.me/teachlinkOD) or
+  GitHub Discussions — see
+  [`policies/COMMUNICATION_NORMS.md`](../policies/COMMUNICATION_NORMS.md) §3.
+- **Task-specific questions:** comment on the issue you are working on, so the
+  answer is recorded for the next person.
+- **Stuck on setup or CI:** open an issue and quote the exact error; include the
+  command and the platform.
+- **Security or privacy concerns:** **never** post publicly — use the private
+  channel in [`SECURITY_POLICY.md`](../SECURITY_POLICY.md).
+- **A conduct problem:** contact a maintainer privately as described in
+  [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md).
+
+No question is too basic. If something in this guide or the setup was unclear,
+saying so improves the project for the next newcomer.
+
+## 4. What good looks like
+
+- One issue, one focused change, one pull request.
+- Commits that follow [`CONTRIBUTING.md`](../../CONTRIBUTING.md), signed off per
+  [`policies/DCO.md`](../policies/DCO.md).
+- A pull request that links its issue and explains what changed and how it was
+  verified.
+- Polite, specific review on both sides, per
+  [`community/REVIEW_ETIQUETTE.md`](REVIEW_ETIQUETTE.md).
+
+## 5. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |
diff --git a/Governance/policies/VULN_SLA.md b/Governance/policies/VULN_SLA.md
@@ -0,0 +1,83 @@
+# Vulnerability Remediation SLA
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/policies/VULN_SLA.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team, with the security response team |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 6 months |
+| Applies to | Vulnerabilities in the project's code, dependencies, and infrastructure |
+| Related | [`SECURITY_POLICY.md`](../SECURITY_POLICY.md) · [`SECURITY_SEVERITY_RUBRIC.md`](../SECURITY_SEVERITY_RUBRIC.md) · [`SECURITY_RESPONSE_TEAM.md`](../SECURITY_RESPONSE_TEAM.md) · [`processes/VULN_DISCLOSURE.md`](../processes/VULN_DISCLOSURE.md) |
+
+This policy sets the remediation targets for each severity, how those targets are
+measured, and the escalation that happens when a target is missed. Severity is
+assigned using [`SECURITY_SEVERITY_RUBRIC.md`](../SECURITY_SEVERITY_RUBRIC.md);
+this policy only defines the clock that starts once severity is known.
+
+## 1. Remediation targets per severity
+
+| Severity | Example | Time to mitigate / fix from triage |
+| --- | --- | --- |
+| **Critical** | Remote code execution, auth bypass, active data exposure | Mitigate within **24 hours**; permanent fix within **7 days** |
+| **High** | Privilege escalation, significant data leak, exploitable injection | Mitigate within **72 hours**; permanent fix within **30 days** |
+| **Medium** | Limited-impact issue, requires unusual conditions | Fix within **90 days** |
+| **Low** | Defence-in-depth, minor information leak | Fix within **180 days**, or accept with a documented rationale |
+
+- **"Mitigate"** means the exploitable path is closed or safely gated — a patch,
+  a config change, a feature flag, or a documented compensating control. A
+  mitigation is not a promise of a permanent fix.
+- **"Fix"** means the vulnerable code or dependency is corrected and shipped.
+- **Clock start.** The target clock starts when the report is triaged and rated,
+  not when it is first reported. Triage itself follows
+  [`SECURITY_POLICY.md`](../SECURITY_POLICY.md) and
+  [`processes/VULN_DISCLOSURE.md`](../processes/VULN_DISCLOSURE.md).
+- **Dependency vulnerabilities** follow the same clock, counted from the moment
+  the finding enters our tracking (for example, a Dependabot alert triaged by the
+  team).
+
+## 2. Measurement
+
+- **Every finding is tracked** with an owner, a severity, a triage date, and the
+  target date derived from §1. The security response team keeps the register.
+- **Time is measured in the project's primary timezone, in 24-hour days**, and
+  excludes time blocked waiting on a coordinated disclosure date agreed with a
+  reporter.
+- **Two metrics are reported** for each severity: the percentage mitigated or
+  fixed within target, and the age of any currently open finding past target.
+  These feed the security section of
+  [`policies/TRANSPARENCY_REPORTS.md`](TRANSPARENCY_REPORTS.md).
+- **Honest reporting.** A finding that misses its target is not removed from the
+  register; it is marked overdue with the reason.
+
+## 3. Escalation when a target is missed
+
+1. **At 50% of the window**, if a finding has no owner or no plan, the security
+   response team assigns one and posts the plan on the tracking issue.
+2. **At the target date**, an incomplete finding is marked overdue and escalated
+   to the lead maintainer with the reason and a revised date.
+3. **Every 7 days past target**, the overdue status is re-escalated until the
+   finding is fixed or formally accepted.
+4. **For Critical and High findings**, a missed target also triggers a
+   user-facing communication decision under
+   [`SECURITY_POLICY.md`](../SECURITY_POLICY.md): whether a mitigation advisory
+   or workaround should be published even before the fix ships.
+5. **Accepted risk.** A maintainer may formally accept a Low or Medium finding in
+   place of a fix; the acceptance names the rationale, the accepting maintainer,
+   and a review date. Critical and High findings may not be closed by acceptance
+   alone.
+
+## 4. Reporting channels
+
+- External reports follow [`SECURITY_POLICY.md`](../SECURITY_POLICY.md) and stay
+  private. This SLA governs the internal remediation clock; it does not change
+  how a vulnerability is reported or disclosed.
+- The response team's roles and coverage are defined in
+  [`SECURITY_RESPONSE_TEAM.md`](../SECURITY_RESPONSE_TEAM.md).
+
+## 5. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |