From e13556b57b6bdf9f5cee54e6e61a0e3baf3da66b Mon Sep 17 00:00:00 2001 From: Maryam Ibrahim Hamza Date: Sat, 17 Oct 2026 02:53:23 +0100 Subject: [PATCH] Add vulnerability SLA, mentorship, welcome, and office hours community docs Closes #1850 Closes #1861 Closes #1863 Closes #1864 --- Governance/community/MENTORSHIP_PROGRAM.md | 91 ++++++++++++++++++++++ Governance/community/OFFICE_HOURS.md | 80 +++++++++++++++++++ Governance/community/WELCOME_GUIDE.md | 77 ++++++++++++++++++ Governance/policies/VULN_SLA.md | 83 ++++++++++++++++++++ 4 files changed, 331 insertions(+) create mode 100644 Governance/community/MENTORSHIP_PROGRAM.md create mode 100644 Governance/community/OFFICE_HOURS.md create mode 100644 Governance/community/WELCOME_GUIDE.md create mode 100644 Governance/policies/VULN_SLA.md diff --git a/Governance/community/MENTORSHIP_PROGRAM.md b/Governance/community/MENTORSHIP_PROGRAM.md new file mode 100644 index 00000000..2c838e1e --- /dev/null +++ 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 new file mode 100644 index 00000000..826a89d5 --- /dev/null +++ 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 new file mode 100644 index 00000000..a5bde43b --- /dev/null +++ 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 new file mode 100644 index 00000000..700cf19b --- /dev/null +++ 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. |