From 9ce47e5a2ef8465cdec33b182ac09a876ece798f Mon Sep 17 00:00:00 2001 From: Bilkee Date: Sat, 17 Oct 2026 20:05:21 +0100 Subject: [PATCH] docs: add office hours, review etiquette, audit, and whistleblower documents Add two community documents and two compliance documents under Governance/, covering how the project convenes, reviews, assures, and responds to bad news: - community/OFFICE_HOURS.md: fortnightly schedule, format, hosting and co-host roles, topic submission, mandatory published notes, and the accessibility conditions that make the session genuinely open. - community/REVIEW_ETIQUETTE.md: tone and substance for reviewers, what authors can expect, a six-step sequence for handling disagreement, and review of governance documents where checkable claims are verified. - compliance/AUDIT_ASSURANCE.md: audit scope and cadence, evidence retention, finding severity and remediation deadlines, continuous verification, and a statement that no external audit has been commissioned. - compliance/WHISTLEBLOWER.md: reporting channels, the non-retaliation guarantee including protection for good-faith reports that prove unfounded, an eight-step handling process with interim measures, and confidentiality limits stated plainly. Existing processes stay authoritative for their own categories; the whistleblower policy is the safeguard for cases where those processes cannot safely be used. Closes #1505 Closes #1506 Closes #1523 Closes #1524 --- Governance/community/OFFICE_HOURS.md | 142 ++++++++++++++++ Governance/community/REVIEW_ETIQUETTE.md | 171 +++++++++++++++++++ Governance/compliance/AUDIT_ASSURANCE.md | 207 +++++++++++++++++++++++ Governance/compliance/WHISTLEBLOWER.md | 182 ++++++++++++++++++++ 4 files changed, 702 insertions(+) create mode 100644 Governance/community/OFFICE_HOURS.md create mode 100644 Governance/community/REVIEW_ETIQUETTE.md create mode 100644 Governance/compliance/AUDIT_ASSURANCE.md create mode 100644 Governance/compliance/WHISTLEBLOWER.md diff --git a/Governance/community/OFFICE_HOURS.md b/Governance/community/OFFICE_HOURS.md new file mode 100644 index 0000000..fbf1046 --- /dev/null +++ b/Governance/community/OFFICE_HOURS.md @@ -0,0 +1,142 @@ +# Office Hours Policy + +## Purpose + +This policy defines the project's open support sessions: the schedule, the format, who +hosts, and how topics are submitted. Some questions are easier to answer in conversation +than in an issue thread, and a recurring, announced session gives newcomers a low-pressure +place to ask them. Without a stated format, office hours become an unstructured call +where whoever talks most sets the agenda. + +## Scope + +This policy covers open office hours for contributors and community members. It does not +cover: + +- private support requests, which follow the [Support Policy](../policies/SUPPORT.md); +- security reports, which always use the private channel in the + [Security Policy](../SECURITY_POLICY.md) and are never discussed in an open session; +- conduct concerns, which follow the + [Code of Conduct Reporting](../COC_REPORTING.md) process; and +- mentor and mentee pairs, whose time is arranged separately under the + [Mentorship Program](MENTORSHIP_PROGRAM.md). + +## Schedule and Format + +| Element | Arrangement | +| --- | --- | +| Frequency | **Fortnightly**, at minimum | +| Day and time | Fixed and published, chosen to avoid the project's busiest overlap window rather than a maintainer's convenience | +| Time zone | Published explicitly, with the session length set so it is workable across at least two regions | +| Length | **60 minutes**, with the last 10 reserved for open questions | +| Public or private | Public by default, announced in advance, with any recording made public afterwards if the participants agree | +| Notes | Notes published in the repository after every session, so attendance is not required to benefit | +| Language | English, with a written summary that is usable by non-native speakers. Where interpretation is needed, it is arranged in advance rather than improvised | + +The fortnightly cadence is a floor, not a ceiling. A session is skipped rather than +cancelled late, and a skip is announced in advance with the reason. + +## Who Hosts + +| Role | Responsibility | +| --- | --- | +| Host | Runs the session, keeps it to time, ensures questions are answered or assigned. Normally a maintainer, reviewer, or the [Community Manager](../roles/COMMUNITY_MANAGER.md) | +| Co-host | Handles the notes, the chat, and the queue of questions. Rotating among volunteers so the load is not always the same people | +| Any attendee | May raise a topic. Hosting is not required to participate | + +Rules that apply to hosting: + +- **Hosting is voluntary and rotates.** Someone who cannot host says so; the session is + rescheduled or given without a host as an informal discussion. +- **The host is not on duty.** Office hours are not a support channel with an on-call + commitment, and a question the host cannot answer is assigned rather than guessed at. +- **The host moderates for time, not for content.** A substantive disagreement belongs in + an issue or the [Conflict Resolution Process](../processes/CONFLICT_RESOLUTION.md), + not in a call. +- **The host follows the Code of Conduct** in the same way as any session, per the + [Code of Conduct Enforcement](../COC_ENFORCEMENT.md). + +## How Topics Are Submitted + +| Step | What happens | +| --- | --- | +| 1. Submit | A topic is posted as an issue labelled `office-hours`, or as a comment on the session announcement, before the session | +| 2. Triage | The host reviews submissions, groups related ones, and publishes an agenda | +| 3. Prioritise | Where there is more time than topics, order by: blockers for a new contributor, questions with broad answers, then specific deep dives | +| 4. Open floor | The last 10 minutes are for anything not on the agenda | +| 5. Carry over | A topic that cannot be covered becomes an issue, so it is not lost | + +Rules for topics: + +- **Anyone may submit**, including someone who has never contributed. No topic is + declined because it seems too basic; a question asked by one person is asked by the + next. +- **State what you need.** A topic that names the problem and what an answer looks like + is answerable. "I am stuck" is not, and the host will ask. +- **No personal data in a topic.** Security issues, conduct concerns, and anything + containing personal data go to the private channels above, and the submitter is told + where. +- **A topic is not a support ticket.** Anything needing sustained work is turned into an + issue so it is tracked. + +## Output + +Each session produces three things: + +1. **Notes**, published in the repository: what was discussed, what was decided, and what + was left open. The notes are written so that someone who was not present can act on + them. +2. **Follow-up issues** for anything that needs tracking, with the session referenced. +3. **Pointers**, where the answer is already written — a documentation link is a better + answer than a verbal one, and a question answered by improving the documentation + produces a lasting fix. + +A session that produces notes nobody can use has not met the standard this policy sets. + +## Accessibility + +The session is designed to be attendable, because a format that excludes people is not +open: + +- The agenda is published in advance, so someone can prepare or decide the topic is not + for them. +- Notes are published afterwards, so attendance is never a requirement for receiving the + information. +- Audio-only attendance is fully supported; no question requires being on video. +- Written questions are treated identically to spoken ones. +- Where a session cannot accommodate someone's needs — a sign-language interpreter, a + translated summary — that is arranged in advance on request, without the requester + having to justify it. + +## Relationship to Other Support + +Office hours complement rather than replace the issue tracker. Anything that needs a +tracked answer becomes an issue, so that it has a +[response expectation](../policies/SUPPORT.md) and a visible lifecycle. A question +answered in office hours and never written down is a question the next person asks +again, which is why the notes are mandatory. + +## Enforcement Status + +- Office hours are a human arrangement. There is no automation for reminders, agendas, or + notes. +- Attendance and topic counts are gathered from the session issues themselves; no + participant tracking beyond the session announcement is required. +- The Community Manager reviews the format every 12 months, and after any session where + someone was unable to take part because of how it was run. + +## Related Documentation + +- [Support Policy](../policies/SUPPORT.md): the channels and response expectations + outside office hours +- [Meeting Cadence](../processes/MEETING_CADENCE.md): how the project's other meetings + are scheduled +- [Community Manager Role](../roles/COMMUNITY_MANAGER.md) and + [Working Group Lead Role](../roles/WORKING_GROUP_LEAD.md) +- [Code of Conduct Enforcement](../COC_ENFORCEMENT.md) and + [Security Policy](../SECURITY_POLICY.md) +- [Mentorship Program](MENTORSHIP_PROGRAM.md) and + [Newcomer Welcome Guide](WELCOME_GUIDE.md) +- [Conflict Resolution Process](../processes/CONFLICT_RESOLUTION.md) +- [Agenda Template](../templates/AGENDA_TEMPLATE.md) and + [Minutes Template](../templates/MINUTES_TEMPLATE.md) diff --git a/Governance/community/REVIEW_ETIQUETTE.md b/Governance/community/REVIEW_ETIQUETTE.md new file mode 100644 index 0000000..b3f369d --- /dev/null +++ b/Governance/community/REVIEW_ETIQUETTE.md @@ -0,0 +1,171 @@ +# Code Review Etiquette Guide + +## Purpose + +This guide sets the expectations for code review as a human interaction: the tone, what +authors can expect from reviewers and reviewers from authors, and how disagreement is +handled so that it produces better code rather than worse relationships. The project's +[Code Review Policy](../policies/REVIEW_POLICY.md) governs *what* is reviewed and who may approve; +this guide is about how the conversation is conducted. + +## Scope + +This guide applies to review of pull requests, issues, and proposed changes anywhere in +the project — including governance documents, which are reviewed with the same care as +code. It covers the conduct expected of both sides. + +It does not set the technical bar, the approval counts, or the turnaround commitments. +Those are in the [Code Review Policy](../policies/REVIEW_POLICY.md), the +[PR Approval Requirements](../policies/APPROVAL_REQUIREMENTS.md), and the +[Code Review Service Level Agreement](../policies/REVIEW_SLA.md). + +## Why This Matters + +Code review is where most people first experience how the project treats them. A +contributor whose first review was patient and specific comes back. One that was a +string of terse corrections, or a public pile-on, does not. That is the whole reason +this document exists: review quality is a retention mechanism as much as a quality +mechanism. + +## For Reviewers + +### Tone + +- **Write to the author, not about them.** "This allocates twice" rather than "you + allocated twice" is not a pedantic rule; it makes a comment about the code and not a + verdict on the person. +- **Assume competence and good faith.** The author may know something you do not, and may + have a constraint you were not told about. +- **Say what you mean.** "This is unclear" is not feedback. Say which line and what is + unclear about it. +- **Praise specifically when something is good.** Not as a cushion before criticism, but + because a specific "this abstraction is exactly right, and here is why it will hold up" + teaches as much as a correction. +- **No sarcasm, no jabs, no "nitpicking your lack of tests" as an opening.** Jokes that + single someone out are not review. +- **Do not relitigate the project's decisions in a review thread.** If a design decision + is wrong, that is a discussion in an issue or an RFC, not a series of one-line comments + on someone's pull request. + +### Substance + +- **Distinguish what blocks from what does not.** Label blocking comments clearly, and + separate required changes from preferences and questions. A reviewer who marks + everything required teaches authors to ignore the labels. +- **Explain the why, not just the what.** "Use a constant here" is an instruction. "Use a + constant here, because this value appears in three places and has already drifted + between two of them" is review. +- **Be specific about correctness.** If you believe something is wrong, give the input + that breaks it. "This will fail if X" is answerable; "this looks fragile" is not. +- **Offer the alternative you would accept.** A blocking comment without a path forward + transfers the design work to the author. +- **Read the whole change before commenting on a part.** Reviewing the third hunk first + produces comments that the first hunk already contradicts. +- **Approve what is good.** Withholding approval to reserve leverage is a misuse of the + mechanism. If the change is ready, approve it. + +### Scope + +- **Review the change in front of you.** Unrelated problems are noted separately, as a + new issue rather than as scope added to this pull request. +- **Check that the change does what it says**, including the tests and the documentation. + A missing test or an unupdated policy is a legitimate review comment. +- **Review for security, correctness, and maintainability first.** Style nits come last + and never block on their own; where the project has automated formatting and linting, + a comment that a tool would have caught is a comment about the tool configuration, not + the author. + +## For Authors + +- **Assume the reviewer is trying to help.** Where that is not what happened, the + [Conflict Resolution Process](../processes/CONFLICT_RESOLUTION.md) exists, and using it + is legitimate. +- **Explain context in the pull request.** Reviewers are frequently missing the constraint + you worked under. A sentence about why saves three review cycles. +- **Respond to every comment**, even if only to say you disagree and why. An unanswered + comment stalls the review and, more importantly, leaves the other person unsure. +- **Disagree in the thread, with a reason.** Most disagreements resolve once the + underlying fact is on the table. +- **Take feedback on the code, not on the tone.** A blunt comment often contains a real + point. Answer the point, and raise the tone separately if it needs raising. +- **Do not push new commits to a pull request already under review** without saying so. + It forces reviewers to start again. +- **Say when you are done and what remains.** If you are still working, or you believe the + change is not ready, say so — an unfinished draft is fine, an unfinished one presented + as finished is not. + +## Handling Disagreement + +Most review disagreement is a missing fact rather than a conflict of values. The +sequence below is tried in order. + +1. **Ask, once, for the underlying fact.** "What breaks if this is nil here?" is often + answered with "nothing — good catch". +2. **State your position with a reason.** A position with a reason can be discussed; one + without becomes a matter of taste. +3. **Bring in a third maintainer.** Where two people have both reasoned carefully and + still disagree, a third reviewer decides, per the + [Decision Rights Matrix](../matrices/DECISION_RIGHTS_MATRIX.md). +4. **Move it to the right venue.** A disagreement about a design belongs in an issue or an + RFC under the [RFC Process](../processes/RFC_PROCESS.md), not in a pull request + thread that blocks a merge. +5. **Escalate if it is not resolving.** Through the + [Escalation Path](../processes/ESCALATION_PATH.md) or the + [Conflict Resolution Process](../processes/CONFLICT_RESOLUTION.md). +6. **Code of conduct, separately.** Persistent hostility, personal criticism, or + discrimination during review is a conduct matter, not a review disagreement, and goes + to the [Code of Conduct Reporting](../COC_REPORTING.md) process. It is raised on its + own terms and never used as leverage in a technical argument. + +Rules that hold throughout: + +- **No blocking over style.** A reviewer who will not approve over formatting when a tool + handles formatting is overruling the project's automation. +- **The author can walk away.** Someone who feels review has become abusive can stop + participating. That is a legitimate outcome, and the conduct is addressable regardless + of whether the pull request ever merged. +- **Good faith is assumed, and so is a bad day.** Reviewers are volunteers with their own + work. A terse comment is addressed, not escalated on its own. + +## Governance and Documentation Reviews + +Documentation and governance changes are reviewed on the same terms as code, with two +adjustments: + +- **Factual claims are verified.** A policy document that asserts something untrue about + the repository is a defect. Checkable statements are checked, and where a statement + cannot be verified from the repository, the document says so. +- **Scope matters.** Governance changes stay inside `Governance/`, as the + [Governance README](../README.md) requires, so that a documentation change cannot + silently alter behaviour. +- **A policy that describes a control that does not exist is worse than no policy.** A + reviewer should challenge a claim of enforcement that is not implemented, and the + document should state plainly what is enforced today and what is not. + +## Enforcement + +Review etiquette is enforced by the +[Code of Conduct Enforcement](../COC_ENFORCEMENT.md), not by a separate mechanism. +Persistent or severe violations are handled under that policy and the +[Privilege Revocation Policy](../policies/REVOCATION.md), which is how review powers are removed when +someone uses them badly. + +Review quality is also checked in the monthly governance review: the number of changes +requested, the number of pull requests that went quiet, and recurring comments that +suggest a missing convention or a missing automated check. + +## Related Documentation + +- [Code Review Policy](../policies/REVIEW_POLICY.md): what is reviewed, by whom, and how +- [PR Approval Requirements](../policies/APPROVAL_REQUIREMENTS.md): approval counts and required + checks +- [Code Review Service Level Agreement](../policies/REVIEW_SLA.md): turnaround commitments +- [Conflict Resolution Process](../processes/CONFLICT_RESOLUTION.md) and + [Escalation Path](../processes/ESCALATION_PATH.md) +- [Objection Handling Process](../processes/OBJECTION_HANDLING.md) and + [RFC Process](../processes/RFC_PROCESS.md) +- [Code of Conduct Enforcement](../COC_ENFORCEMENT.md) and + [Code of Conduct Reporting](../COC_REPORTING.md) +- [Decision Rights Matrix](../matrices/DECISION_RIGHTS_MATRIX.md) +- [Stale Pull Request Policy](../policies/STALE_PRS.md) and + [Inclusive Language Guide](INCLUSIVE_LANGUAGE.md) diff --git a/Governance/compliance/AUDIT_ASSURANCE.md b/Governance/compliance/AUDIT_ASSURANCE.md new file mode 100644 index 0000000..1963005 --- /dev/null +++ b/Governance/compliance/AUDIT_ASSURANCE.md @@ -0,0 +1,207 @@ +# Audit and Assurance Policy + +## Purpose + +This policy defines how the project's controls are audited, how often, what evidence is +retained, and how findings are remediated. Governance documents that nobody checks are +aspirations. This policy makes assurance an activity with a schedule, evidence, and an +obligation to act on what it finds. + +## Scope + +This policy covers assurance activity over the project's governance and operational +controls, including: + +- governance documents: whether each policy still reflects how the project works, and + whether the registers are being maintained; +- access and identity: the [Access Register](../registers/ACCESS_REGISTER.md) and the + [Access Review Policy](../policies/ACCESS_REVIEW.md); +- security controls: the [Security Policy](../SECURITY_POLICY.md), the + [Secret Rotation Policy](../policies/SECRET_ROTATION.md), and the + [Key Management Policy](../policies/KEY_MANAGEMENT.md); +- data protection controls: the [Record Retention and Legal Hold Policy](../policies/RECORD_RETENTION.md), + the [Right-to-Erasure Policy](../policies/DATA_DELETION.md), and the + [Consent Management Policy](../policies/CONSENT_MANAGEMENT.md); +- supply chain: the [Dependency Register](../registers/DEPENDENCY_REGISTER.md), + licence compliance, and the + [Vulnerability Remediation SLA Policy](../policies/VULN_SLA.md); +- release controls: the + [EAS Build Governance](../domains/EAS_BUILD_GOVERNANCE.md) and the + [App Signing Key Policy](../domains/APP_SIGNING_KEYS.md); and +- process controls: triage, review, escalation, and the community policies. + +It does not govern an external audit commissioned on the organisation, nor a regulatory +inspection. Where an external audit is arranged, this policy's evidence set is what makes +that audit faster. + +## Audit Scope and Cadence + +| Assurance activity | Scope | Cadence | Owner | +| --- | --- | --- | --- | +| Governance review | Are policies current, registers maintained, decisions recorded | **Quarterly** | Maintainers | +| Access review | Privileged access, workflow secrets, service accounts | **Quarterly** | [Security Officer](../roles/SECURITY_OFFICER.md) | +| Security posture review | Incident history, vulnerability targets, secret and key hygiene | **Quarterly** | [Security Officer](../roles/SECURITY_OFFICER.md) | +| Data protection review | Processing register, retention, consent, subprocessor changes | **Every 12 months**, or quarterly where child data is involved | [Security Officer](../roles/SECURITY_OFFICER.md) | +| Supply chain review | Dependency register, advisories, licence allowlist | **Every 12 months** | Maintainer responsible for dependencies | +| Release control review | Signing custody, promotion path, store submissions | **Every 12 months** and before a major release | [Release Manager](../roles/RELEASE_MANAGER.md) | +| Continuous verification | What the CI workflows and `audit.yml` actually check | **Every 12 months** | Maintainer responsible for CI | +| Independent review | A second pair of eyes on a named area | **Every 24 months**, and on request | [Community Manager](../roles/COMMUNITY_MANAGER.md) arranges | + +Rules that apply to the schedule: + +- **A skipped review is recorded as skipped**, with the reason. A gap that is documented + can be planned for; a gap that is invisible cannot. +- **A finding in one area expands the review of that area.** A failure found in a + quarterly review is a reason to look at the neighbouring control, not only to fix the + finding. +- **Child data raises the cadence.** Where a control protects data about children, the + quarterly cadence applies, per the + [Children's Data Policy](../compliance/CHILDRENS_DATA.md). + +## Evidence Retention + +Evidence is what makes a control verifiable later. An assurance activity that leaves no +evidence has not happened, however thoroughly it was performed. + +| Evidence | Retention | Where it lives | +| --- | --- | --- | +| Review records and their outcomes | 3 years | The relevant register or the governance review record | +| Access review findings | 3 years | [Access Register](../registers/ACCESS_REGISTER.md) | +| Secret and key rotation records | 3 years | The rotation calendar and the relevant issue | +| Security incident records | 6 years | [Incident Log](../registers/INCIDENT_LOG.md) | +| Vulnerability remediation measurements | 3 years | The tracking issue, per the [Vulnerability Remediation SLA Policy](../policies/VULN_SLA.md) | +| Consent records and deletion confirmations | Duration of consent plus 3 years | The controlled consent store | +| External audit reports, where obtained | As the auditor requires | Private storage, summary published | +| CI run results and required-check outcomes | 90 days, per the provider's retention | CI provider | + +Rules that apply to evidence: + +- **Evidence records what was checked and what was found**, not only that a check passed. + A list of "reviewed, no findings" is itself the evidence that the review happened. +- **Evidence never contains secrets or personal data.** A rotation record states that a + key was rotated, not what the key was. +- **Evidence is retained even when the control failed.** A finding record is retained and + linked to its remediation, which is how repeat findings are detected. +- **Evidence follows the retention schedule** in the + [Record Retention and Legal Hold Policy](../policies/RECORD_RETENTION.md), and is + subject to a legal hold when one is in place. + +## Finding Remediation + +A finding is only useful if it leads to a change. Every finding follows the same path. + +| Severity | Definition | Remediation deadline | +| --- | --- | --- | +| **Critical** | A control that does not exist and should, exposing personal data or enabling unauthorised access | **7 calendar days** | +| **High** | A control that exists but is not operating, or a material gap in a documented control | **30 calendar days** | +| **Medium** | A control operating partially, or a documentation and practice mismatch | **90 calendar days** | +| **Low** | An improvement opportunity, or a register and practice divergence with low consequence | Next scheduled review | + +The remediation process: + +1. **Record the finding** with the control, the evidence, the severity and why, and the + owner accountable for fixing it. +2. **Plan the fix** with a date. A finding with no date is a finding with no deadline. +3. **Remediate**, or record why it cannot be remediated as found. +4. **Verify the fix.** The same person who verified the control found the gap confirms + the closure, where practicable. Self-certification of a High or Critical closure + requires a second reviewer. +5. **Close with the evidence recorded**, linked to the original finding, so that a later + reviewer can see what was wrong and what changed. +6. **Escalate on a missed deadline**, through the + [Escalation Path](../processes/ESCALATION_PATH.md), rather than letting the date pass + and the finding quietly ageing. + +A finding that recurs after being closed is treated as a **systemic** finding: the +individual fix is secondary to why the same gap reappeared. Systemic findings go to the +maintainers as a governance item. + +### Exceptions + +A finding accepted rather than fixed is recorded in the +[Exception and Waiver Register](../registers/EXCEPTION_REGISTER.md) with the reason, the +compensating control, an approver holding the authority to grant it, and an expiry no more +than 12 months ahead. A finding about a missing control is not improved by noting it, and +renewal is never automatic: a second approval is a signal to fix it. + +## Continuous Verification + +Some controls are verified automatically, and it is worth being clear about which, since a +policy that implies automation that does not exist is misleading. + +| Control | Verified by | Frequency | +| --- | --- | --- | +| High and critical dependency vulnerabilities | `audit.yml` | On push and weekly | +| Disallowed dependency licences | `license-audit.js` and `audit.yml` | On push | +| Architecture boundaries | `dependency-cruiser` in `architecture.yml` | On pull request | +| Lint, format, typecheck, tests, OpenAPI validation | The `ci` job | On pull request | +| Bundle size and API performance budgets | `checkBundleSize.js`, `checkApiPerf.js` | On pull request | +| Build and release provenance | The release workflow and tagged releases | Per release | +| Branch protection rules | Maintainer confirmation in the repository settings | Every 12 months | + +The controls verified only by human review — registers, rotation cadence, access +reviews, consent records, vendor assessments, exception expiry — are stated as such in +each policy's enforcement-status section. The Continuous Verification activity exists +precisely to confirm that this table still matches reality, because an inventory of +automation drifts as workflows change. + +## Reporting + +Each assurance activity produces a short record: + +- the date, the reviewers, and the scope reviewed; +- the controls examined and the evidence used; +- findings raised with their severity and owner; +- the outcome for each, including "no change needed"; and +- anything that could not be verified, and why. + +The record is published where it contains nothing sensitive. A summary of each quarterly +governance review is published to contributors so that the project is accountable for +what it claims; the full record, where it names individuals or includes security +detail, is kept private and its existence stated. + +## Enforcement Status + +- Everything in the Continuous Verification table is real and runs in this repository + today. The human-review activities are not automated, and are tracked through the + register and review records rather than a tool. +- Branch protection settings live outside the repository and are confirmed by a + maintainer rather than read by CI. +- No external audit has been commissioned, and none is claimed. This document describes + what the project does for itself, and says so plainly rather than implying assurance it + does not have. + +## Exceptions + +Any deviation from the cadence or from the evidence requirement is recorded in the +[Exception and Waiver Register](../registers/EXCEPTION_REGISTER.md) with an approver +holding the authority to grant it and an expiry no more than 12 months ahead. A review +that cannot be performed because of a staffing gap is an exception to record, not a +review to skip quietly. + +## Ownership and Review + +The [Security Officer](../roles/SECURITY_OFFICER.md) owns this policy, with the +[Release Manager](../roles/RELEASE_MANAGER.md) responsible for release-control assurance +and the [Community Manager](../roles/COMMUNITY_MANAGER.md) for publishing the summaries. +It is reviewed at least once every 12 months, and after any Critical or High finding. +Changes are proposed in a pull request that touches only the `Governance/` folder. + +## Related Documentation + +- [Children's Data Policy](../compliance/CHILDRENS_DATA.md): the raised cadence for + child data +- [Access Register](../registers/ACCESS_REGISTER.md) and + [Access Review Policy](../policies/ACCESS_REVIEW.md) +- [Incident Log](../registers/INCIDENT_LOG.md) and + [Risk Register](../registers/RISK_REGISTER.md) +- [Exception and Waiver Register](../registers/EXCEPTION_REGISTER.md) and + [Security Exceptions Register](../registers/SECURITY_EXCEPTIONS_REGISTER.md) +- [Security Policy](../SECURITY_POLICY.md) and + [Secret Rotation Policy](../policies/SECRET_ROTATION.md) +- [Record Retention and Legal Hold Policy](../policies/RECORD_RETENTION.md): evidence + retention +- [Escalation Path](../processes/ESCALATION_PATH.md): missed remediation deadlines +- [CI/CD Governance Policy](../policies/CICD_GOVERNANCE.md): the pipelines whose checks + are listed here +- [Security Officer role](../roles/SECURITY_OFFICER.md) diff --git a/Governance/compliance/WHISTLEBLOWER.md b/Governance/compliance/WHISTLEBLOWER.md new file mode 100644 index 0000000..bae665d --- /dev/null +++ b/Governance/compliance/WHISTLEBLOWER.md @@ -0,0 +1,182 @@ +# Whistleblower Policy + +## Purpose + +This policy defines how someone who observes wrongdoing in TeachLink Mobile can report +it, what protection they have if they do, and what the project does with the report. It +exists so that a person with a genuine concern has a safe route to raise it, and so that +the project has a defined process rather than improvising when one is used. + +## Scope + +This policy covers reports of suspected wrongdoing connected with the project: conduct +breaches, misuse of access or credentials, financial or procurement irregularity, +fraud, harassment, discrimination, safety concerns, and attempts to conceal any of these. + +It does not replace the processes that already exist for specific categories, and a +report is routed to the right one: + +| Report about | Primary process | +| --- | --- | +| A vulnerability in the software | [Security Policy](../SECURITY_POLICY.md), private channel | +| Code of Conduct or conduct at the project | [Code of Conduct Reporting](../COC_REPORTING.md) | +| A data protection breach or a failed erasure request | [Security Policy](../SECURITY_POLICY.md), handled as an incident | +| A governance or decision dispute | [Conflict Resolution Process](../processes/CONFLICT_RESOLUTION.md) | +| Retaliation against a reporter | This policy, treated as the most serious category | + +This policy is the **safeguard** for those processes: it covers the situations where a +person cannot safely use them, cannot reach the right person, or is afraid of the +consequences of doing so. + +## Reporting Channels + +A reporter chooses the channel. More than one is offered because the right channel +depends on who the reporter trusts, and a single named channel is not usable by everyone. + +| Channel | Best for | Notes | +| --- | --- | --- | +| Email to the [Security Officer](../roles/SECURITY_OFFICER.md) | Security, access, data, and anything the reporter can describe in writing | The primary intake. A report sent here is treated as confidential and is not actioned in the open | +| The [Code of Conduct Reporting](../COC_REPORTING.md) process | Conduct concerns, including harassment | Has its own trained handlers and its own confidentiality rules | +| A private message to any maintainer | Where the reporter trusts one specific person | The recipient forwards it to a handler. A maintainer who receives such a report must not sit on it | +| A named external contact, where the project has one | Where the concern is about the project's leadership, or where no internal channel feels safe | External channels are recorded in the project documentation when they exist | +| Anonymous report | Where the reporter will not identify themselves and will not be persuaded to | Accepted. It limits what can be investigated, and that limit is stated plainly rather than used to dismiss the report | + +Rules that apply to every channel: + +- **A report is never dismissed because it came in the wrong channel.** It is forwarded to + a handler and the reporter is told where it went. +- **A report is never dismissed because the reporter wants anonymity.** Where anonymity + makes an investigation impossible, the reporter is told what specifically could not be + done and why. +- **Reports are not made in public channels.** A report posted in an issue, a pull + request, or a discussion is moved to a private channel immediately, and the public + post is removed where the reporter asks. A reporter who posts publicly is treated as + having made a public disclosure and is told what follows from that, without being + blamed for it. +- **A reporter may report the same thing twice.** A second report is not treated as + harassment of the project; it usually means the first was not handled. + +## Non-Retaliation Guarantee + +This is the core of the policy. + +- **No retaliation of any kind** against a person who makes a report in good faith, for + raising a concern, for participating in an investigation, or for refusing to participate + in something they believe is wrong. +- **Retaliation is a violation of this policy and of the Code of Conduct**, handled under + the [Code of Conduct Enforcement](../COC_ENFORCEMENT.md) and the + [Privilege Revocation Policy](../policies/REVOCATION.md), and it is treated as the most + serious category of report. +- **Retaliation includes** removing someone's role, reducing their access, reassigning + their work, rejecting their contributions for improper reasons, excluding them from + communication, publishing a response that identifies them, and any pressure applied + through a third party. +- **The guarantee covers good-faith reports that turn out to be unfounded.** A person who + reports something sincerely and it is not substantiated has not misconducted + themselves, and the report is closed without any consequence to them. This matters: a + policy that protects only reporters who were right protects silence. +- **The guarantee extends to witnesses and to people who ask questions.** Asking why a + decision was made is not retaliation. +- **The project will not require a reporter to prove harm to themselves first.** Retaliation + is assessed on intent and effect, and a pattern of small acts is assessed as a pattern. +- **Where the project cannot prevent retaliation by someone outside its control** — for + example an employer or a school — the project will record the concern, act on what it + can, and say plainly what it cannot do rather than implying protection it does not + offer. + +The [Security Officer](../roles/SECURITY_OFFICER.md) is accountable for this guarantee +and reports on it in the periodic governance review. + +## Handling a Report + +| Step | What happens | Timing | +| --- | --- | --- | +| 1. Acknowledge | The handler confirms receipt. The reporter is told who now holds the report | Within **2 business days** | +| 2. Triage | Severity assessed and the route decided: conduct, security incident, governance, or financial. Conflicts of interest in the subject matter are identified here | Within **5 business days** | +| 3. Scope | The handler defines what will and will not be investigated, and tells the reporter that scope | Within **10 business days** | +| 4. Investigate | Facts gathered by someone with no conflict of interest. The reporter is told what evidence is being sought | Ongoing | +| 5. Decide | A finding, or a no-finding, with the reasons. Referred to the [Decision Rights Matrix](../matrices/DECISION_RIGHTS_MATRIX.md) where the subject is a maintainer's conduct | Within **30 business days** of scope | +| 6. Act | Action taken under the relevant policy. Where the report concerns the handling team itself, a handler is replaced | With the decision | +| 7. Inform | The reporter is told the outcome. Where confidentiality was promised, the limits of what can be shared are explained | With the decision | +| 8. Record | The report, the decision, and the action are recorded in the [Incident Log](../registers/INCIDENT_LOG.md) without identifying the reporter | Within **10 business days** of the decision | + +Rules that apply to the handling: + +- **Handlers are conflict-checked.** Anyone named in the report, or with a relationship to + the subject, does not handle it. Where the concern is about a senior maintainer, the + handler is someone outside that maintainer's reporting line, or external. +- **Interim measures are available.** Access, roles, or a person's ability to act on the + project can be suspended while a report is investigated, without that being a finding. + This is a precaution, and it is reviewed rather than left in place indefinitely. +- **Investigations are proportionate.** The handling aims to establish what happened, not + to build a case, and it does not extend to unrelated conduct. +- **A report is not shared beyond the handlers.** Confidentiality is maintained for as + long as possible, and the limits are stated to the reporter rather than assumed. +- **A report is closed, not abandoned.** Where it cannot be progressed, the reason is + recorded and the reporter is told. +- **Records survive the outcome.** An unsubstantiated report is retained, without + identifying the reporter, because a pattern of reports is itself information. + +## Protection of the Reporter + +- **Identity is protected** unless the reporter chooses otherwise, or unless disclosure is + legally required, in which case the reporter is told before it happens wherever that is + possible. +- **The reporter is not named** in any record, report, or governance summary. +- **The reporter can request updates** at agreed intervals, and is told if the expected + timing changes. +- **A reporter facing a risk to their safety or their employment or school position is + told what the project can do**, which may be limited. Stating a limit honestly is more + use than implying more protection than exists. +- **A reporter who wants support** is directed to the + [Code of Conduct Reporting](../COC_REPORTING.md) process, which has trained handlers + and support contacts. + +## Good-Faith Reports + +A report is in good faith when the reporter genuinely believes something is wrong, +regardless of whether it proves to be true or whether they were right about the facts. + +Reports that are knowingly false, and reports made to harass or to extract something, are +handled differently: the [Code of Conduct Enforcement](../COC_ENFORCEMENT.md) applies. A +person whose genuine concern turns out to be mistaken is not in this category, and the +distinction is drawn deliberately so that the cost of being wrong does not fall on the +person who spoke up. + +## Confidentiality and Disclosure + +| Situation | Position | +| --- | --- | +| Nothing found | The reporter is told. No finding is published | +| Something found | The action is taken. The reporter is told the outcome; details are shared only as far as confidentiality allows | +| Legal obligation to disclose | Disclosure is made, and the reporter is told beforehand where possible | +| A report that would identify a reporter being published publicly | The publication is prevented or the reporter's identity is redacted, unless disclosure is required | +| Ongoing risk to others, such as an unremediated vulnerability | Disclosure to those at risk is not blocked by a promise of confidentiality to the reporter. The reporter is told it is happening | + +The project does not agree to keep a report secret from everyone regardless of +consequences. It agrees not to identify the reporter unnecessarily. + +## Enforcement Status + +- This is a human process with no automated component. The existence of the channels, and + the training of handlers, are what make it real. +- No external ethics hotline is operated, and none is claimed. Where the project has no + external channel, the escalation path reaches the [Community Manager](../roles/COMMUNITY_MANAGER.md) + and, for concerns about the leadership, the maintainers as a group. +- Handling records are kept in the [Incident Log](../registers/INCIDENT_LOG.md), which is + reviewed under the [Audit and Assurance Policy](AUDIT_ASSURANCE.md). + +## Related Documentation + +- [Code of Conduct Enforcement](../COC_ENFORCEMENT.md) and + [Code of Conduct Reporting](../COC_REPORTING.md) +- [Security Policy](../SECURITY_POLICY.md): the private channel for security reports +- [Incident Log](../registers/INCIDENT_LOG.md) and + [Conflict-of-Interest Register](../registers/CONFLICT_OF_INTEREST_REGISTER.md) +- [Privilege Revocation Policy](../policies/REVOCATION.md): action taken against a + person, including for retaliation +- [Conflict Resolution Process](../processes/CONFLICT_RESOLUTION.md) and + [Escalation Path](../processes/ESCALATION_PATH.md) +- [Audit and Assurance Policy](AUDIT_ASSURANCE.md): how findings are tracked and closed +- [Security Officer role](../roles/SECURITY_OFFICER.md) and + [Community Manager role](../roles/COMMUNITY_MANAGER.md)