Add media, sponsorship, representation, and survey community policies

Governance/community/MEDIA_POLICY.md

@@ -0,0 +1,94 @@
+# Press and Media Policy
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/community/MEDIA_POLICY.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 6 months |
+| Applies to | Anyone contacted by, or responding to, the press, analysts, or a podcast on a project matter |
+| Related | [`community/SOCIAL_MEDIA.md`](SOCIAL_MEDIA.md) · [`community/REPRESENTATION.md`](REPRESENTATION.md) · [`policies/COMMUNICATION_NORMS.md`](../policies/COMMUNICATION_NORMS.md) |
+
+This policy states who may speak to the media on the project's behalf, the
+approval process for doing so, and the messaging guidance that applies. It
+governs project-facing media contact, not an individual commenting on their own
+work.
+
+## 1. Who speaks to media
+
+- **Official spokespeople are designated maintainers.** The maintainer team keeps
+  a short list of people authorised to speak to the press for the project. Only
+  those people may give an on-the-record interview or a statement attributed to
+  the project.
+- **Anyone may be approached.** If a journalist contacts you, you are welcome to
+  acknowledge the message, but you must not give a project statement unless you
+  are a designated spokesperson.
+- **On background, not on the record.** A non-designated contributor may talk
+  privately for context, clearly flagged as off the record and not attributable
+  to TeachLink, and must pass any request for an official comment to a
+  spokesperson.
+- **Personal views stay personal.** If you speak publicly about your own work,
+  say you are speaking for yourself unless you are a designated spokesperson —
+  see [`community/REPRESENTATION.md`](REPRESENTATION.md).
+
+## 2. Approval process
+
+1. **Forward the request.** Send the journalist's request, the outlet, and the
+   proposed questions to the maintainer team through a private channel.
+2. **Assign a spokesperson.** A maintainer with relevant knowledge takes the
+   request, or declines it.
+3. **Prepare the talking points.** Before the interview, the spokesperson drafts
+   the key messages and gets agreement from at least one other maintainer.
+   Security and legal topics are cleared through the channels in §4.
+4. **Coordinate timing.** Public-facing announcements are timed so the
+   repository, release notes, or an advisory is the source of record; media
+   coverage links to it, not the other way round.
+5. **Pre-notice for sensitive topics.** Anything touching security, legal
+   matters, funding, or a partner must be reviewed under
+   [`SECURITY_POLICY.md`](../SECURITY_POLICY.md) and, for legal matters, with
+   counsel before any statement is given.
+6. **Post-interview record.** The spokesperson files the final quotes or a link
+   to the published article with the maintainer team.
+
+## 3. Messaging guidance
+
+- **Be factual and specific.** Prefer what shipped, when, and what it does over
+  adjectives. If a number is used, cite the source.
+- **Stay on your area.** Answer what you know; defer questions outside your area
+  to a maintainer who knows it.
+- **Never speculate on the roadmap.** Future features are described as "under
+  discussion" unless a public issue or roadmap document states otherwise.
+- **Say "I don't know" freely.** A wrong answer costs more than a deferred one.
+- **Match the tone in [`policies/COMMUNICATION_NORMS.md`](../policies/COMMUNICATION_NORMS.md)**:
+  respectful, no snark, no criticism of other projects or individuals.
+- **Credit contributors.** Name the people who did the work when it is public.
+
+## 4. Security, privacy, and legal topics
+
+- **Do not discuss unpatched vulnerabilities.** Refer any security question to
+  the private process in [`SECURITY_POLICY.md`](../SECURITY_POLICY.md) and may
+  only comment after an advisory is published.
+- **Do not disclose personal data** about users, contributors, or partners.
+- **Legal questions** (licensing, trademarks, disputes) are answered only after
+  review by the maintainers and, where needed, counsel, per
+  [`policies/LICENSING.md`](../policies/LICENSING.md).
+- **Sanctions and financial topics** follow
+  [`compliance/SANCTIONS.md`](../compliance/SANCTIONS.md).
+
+## 5. If something goes wrong
+
+- If a spokesperson gives an inaccurate statement, correct it promptly through
+  the same outlet and note the correction with the maintainer team.
+- If an unauthorised person speaks for the project, a maintainer issues a short,
+  factual clarification and reminds the community of this policy without
+  personal attacks.
+- Repeated misrepresentation is a conduct matter under
+  [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md).
+
+## 6. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |

Governance/community/REPRESENTATION.md

@@ -0,0 +1,77 @@
+# Representation and Speaking Policy
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/community/REPRESENTATION.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 6 months |
+| Applies to | Anyone who speaks about the project at a conference, in a podcast, in a publication, or to a partner |
+| Related | [`community/MEDIA_POLICY.md`](MEDIA_POLICY.md) · [`community/SOCIAL_MEDIA.md`](SOCIAL_MEDIA.md) · [`roles/MAINTAINER.md`](../roles/MAINTAINER.md) |
+
+This policy states who may represent the project, how approval works, and the
+disclosure rules that apply. Its purpose is simple: a listener or reader should
+always know whether they are hearing from the project or from an individual.
+
+## 1. Who may represent the project
+
+- **The maintainer team represents the project.** A maintainer may speak for the
+  project on their area of responsibility by default.
+- **Project representation is a role, not a title.** A contributor may represent
+  the project at a specific event or in a specific forum if a maintainer
+  authorises it for that occasion (see §2). That authorisation is scoped and
+  time-limited.
+- **The lead maintainer is the final voice** on matters of project position that
+  are contested or that touch legal, security, or treasury questions. See
+  [`processes/RELEASE_SIGNOFF.md`](../processes/RELEASE_SIGNOFF.md) for the
+  analogous release authority.
+- **No one else speaks for the project.** A contributor without authorisation
+  may speak about their own work but not as TeachLink.
+
+## 2. Approval process
+
+1. **Ask first.** Before accepting an invitation to represent the project, send
+   the event or outlet, the audience, the topic, and any recording plan to the
+   maintainer team.
+2. **Scope the authorisation.** A maintainer confirms or declines and records the
+   scope: which topics, which date, and whether the talk is on the record.
+3. **Prepare the material.** Slides and talking points are shared with a
+   maintainer before the event. Anything on security, legal, or funding topics is
+   cleared under [`community/MEDIA_POLICY.md`](MEDIA_POLICY.md) §2.
+4. **Use the project marks correctly.** Branding follows
+   [`BRAND_USAGE.md`](../BRAND_USAGE.md).
+5. **Report back.** After the event, the speaker files a short note with a link,
+   so the community can find the talk.
+
+## 3. Disclosure rules
+
+- **State your capacity.** Begin by saying whether you are speaking for the
+  project or for yourself. When in doubt, say "I speak for myself".
+- **Disclose affiliation and funding.** If an employer, sponsor, or client is
+  relevant to your talk, say so. Travel or fees paid by a third party are
+  disclosed.
+- **Do not imply endorsement.** Do not present a vendor tool, a partner, or a
+  sponsor as "officially recommended" unless the project has decided it publicly.
+- **Be accurate about status.** Describe unreleased work as under discussion, not
+  as shipped, and cite the public issue or roadmap when you do.
+- **Attribute the work.** Credit contributors by name where they are public.
+- **Do not disclose private detail.** No secrets, no user data, no unpublished
+  vulnerability detail, no private governance discussion.
+
+## 4. Partners and third parties
+
+- A partner may describe their integration with the project factually, but may
+  not claim to represent the project or speak to its roadmap.
+- A statement that appears to commit the project to a partner must be cleared by
+  the maintainers in advance.
+- Misrepresentation by a third party is addressed with a short public
+  clarification and, if repeated, under
+  [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md).
+
+## 5. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |

Governance/community/SPONSORSHIP.md

@@ -0,0 +1,87 @@
+# Donation and Sponsorship Policy
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/community/SPONSORSHIP.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team, with the treasurer |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 6 months |
+| Applies to | Any donation or sponsorship offered to, accepted by, or announced by the project |
+| Related | [`roles/TREASURER.md`](../roles/TREASURER.md) · [`policies/TRANSPARENCY_REPORTS.md`](../policies/TRANSPARENCY_REPORTS.md) · [`compliance/SANCTIONS.md`](../compliance/SANCTIONS.md) |
+
+This policy defines the forms of sponsorship the project accepts, the
+conflict-of-interest rules that apply, and the transparency commitments the
+project keeps. It exists so that funding never buys influence over the project's
+technical direction or its Code of Conduct.
+
+## 1. Accepted sponsorship forms
+
+The project may accept:
+
+- **Unrestricted financial donations** to the community treasury, with no
+  conditions on how the funds are used.
+- **Directed grants** for a named, agreed purpose (for example, documentation or
+  accessibility work), where the purpose is public and does not create control
+  over roadmap or staffing.
+- **In-kind contributions** — infrastructure, CI minutes, tooling, or event
+  space — that are disclosed and that the project can decline or stop using at
+  any time.
+- **Event and program sponsorship** that follows
+  [`community/EVENTS_POLICY.md`](EVENTS_POLICY.md).
+
+The project does **not** accept:
+
+- funding conditioned on a change to the Code of Conduct, moderation, or review
+  outcomes;
+- sponsorship from a party under applicable sanctions (see
+  [`compliance/SANCTIONS.md`](../compliance/SANCTIONS.md));
+- anonymous funding above the threshold in §3 that cannot be screened;
+- any arrangement that would make the project an instrument of a sponsor's
+  marketing or legal dispute.
+
+## 2. Conflict-of-interest rules
+
+- **Disclose before discussion.** Anyone taking part in a decision about a
+  sponsor must disclose any financial or personal interest in that sponsor.
+- **No self-approval.** A person with a conflict may provide information but must
+  not cast the deciding vote or approve the arrangement alone; a second,
+  unconflicted maintainer approves.
+- **No sponsor in the driver's seat.** Sponsors do not sit on the technical
+  decision path, do not get a veto over releases, and do not review moderation.
+- **No preferential treatment.** A sponsor's bug report, PR, or feature request
+  is triaged like any other; money does not change priority.
+- **Cooling-off.** A maintainer who takes a paid role with a sponsor discloses it
+  and recuses from sponsorship decisions involving that sponsor.
+
+## 3. Transparency commitments
+
+- **A public register.** Accepted sponsors, the form and amount (or "in-kind"),
+  and any stated purpose are listed in the project's public sponsorship register
+  or transparency report, using the cadence in
+  [`policies/TRANSPARENCY_REPORTS.md`](../policies/TRANSPARENCY_REPORTS.md).
+- **No undisclosed funding.** Funding above a small, published threshold is
+  always disclosed; only genuinely trivial donations may be aggregated rather
+  than itemised, and the aggregation rule is published.
+- **Treasury reporting.** The treasurer records income and spending and reports
+  it per [`roles/TREASURER.md`](../roles/TREASURER.md).
+- **Screening.** Before accepting, the responsible maintainer or treasurer
+  screens the party as required by
+  [`compliance/SANCTIONS.md`](../compliance/SANCTIONS.md) and records the check.
+- **Withdrawal.** The project may decline or return a sponsorship at any time,
+  including if the sponsor's conduct conflicts with
+  [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md).
+
+## 4. Process
+
+1. Open an issue describing the offer, the form, the amount, and any conditions.
+2. The treasurer and a maintainer without a conflict review it against §1–§3.
+3. Record the decision and the screening outcome; update the public register.
+4. Announce accepted sponsorship factually and link the register entry.
+
+## 5. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |

Governance/community/SURVEY_POLICY.md

@@ -0,0 +1,73 @@
+# Community Survey Policy
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/community/SURVEY_POLICY.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 6 months |
+| Applies to | Any survey, poll, or feedback form run by or for the project |
+| Related | [`policies/DATA_DELETION.md`](../policies/DATA_DELETION.md) · [`policies/CONSENT_MANAGEMENT.md`](../policies/CONSENT_MANAGEMENT.md) · [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md) |
+
+This policy describes how surveys are run, how the privacy of responses is
+protected, and how results are shared. It applies to contributor surveys,
+community polls, and user-feedback forms run in the project's name.
+
+## 1. How surveys are run
+
+1. **State a purpose and an owner.** Every survey names the decision it informs,
+   the maintainer who owns it, and the closing date. A survey with no decision
+   attached is a sign the survey should not run.
+2. **Open an issue first.** The proposal describes the purpose, the audience, the
+   questions, the tool, and how results feed back. This lets the community
+   object to a leading or unnecessary question before anyone is asked.
+3. **Design it fairly.** Ask neutral, answerable questions; avoid leading
+   wording; offer "prefer not to say" and "other" where an answer may not fit;
+   keep it as short as the purpose allows.
+4. **Say how long it takes** and how the results will be used. No dark patterns
+   and no requirement to answer every question.
+5. **Run it in the open.** Identify the survey as a project survey, and use a
+   tool the project controls or a processor recorded under
+   [`compliance/DPA_TEMPLATE.md`](../compliance/DPA_TEMPLATE.md).
+
+## 2. Privacy of responses
+
+- **Collect the minimum.** Ask only for what the purpose needs; do not collect
+  identifiers (name, email, employer) unless required, and say why.
+- **Anonymous by default.** Prefer anonymous responses. If a response must be
+  attributable, tell respondents before they start and give the reason.
+- **Honest about anonymity.** Do not describe a survey as anonymous if free-text
+  answers, timestamps, or account linkage could identify a respondent.
+- **Secure handling.** Responses are stored in a project-controlled, access-
+  limited location, classified per
+  [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md), and are
+  not shared with a sponsor or third party without consent.
+- **Consent and deletion.** Participation is opt-in and the consent and
+  withdrawal rules in [`policies/CONSENT_MANAGEMENT.md`](../policies/CONSENT_MANAGEMENT.md)
+  and [`policies/DATA_DELETION.md`](../policies/DATA_DELETION.md) apply.
+- **Sensitive topics.** A survey that would surface personal or sensitive
+  information is reviewed before launch, and never published as raw data.
+
+## 3. How results are shared
+
+- **Share a summary, not raw data.** Publish aggregate results and the key
+  findings within a reasonable time of closing, linked from the survey issue.
+- **Do not expose individuals.** Suppress or aggregate any cell small enough to
+  identify a respondent; present free-text comments in a way that cannot be
+  traced back without the author's agreement.
+- **Explain the decision.** Say what the project will do with the findings, or
+  explicitly that no change is planned. A survey whose results are never
+  discussed discourages future participation.
+- **Keep the data only as long as needed.** Raw responses are retained per the
+  project's retention rules and then deleted; the published summary persists as
+  the record.
+- **Credit the work.** Acknowledge those who designed or analysed the survey, per
+  [`RECOGNITION.md`](../RECOGNITION.md).
+
+## 4. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |