diff --git a/Governance/community/MEDIA_POLICY.md b/Governance/community/MEDIA_POLICY.md new file mode 100644 index 00000000..2130b306 --- /dev/null +++ b/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. | diff --git a/Governance/community/REPRESENTATION.md b/Governance/community/REPRESENTATION.md new file mode 100644 index 00000000..86ac8aca --- /dev/null +++ b/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. | diff --git a/Governance/community/SPONSORSHIP.md b/Governance/community/SPONSORSHIP.md new file mode 100644 index 00000000..620b1eee --- /dev/null +++ b/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. | diff --git a/Governance/community/SURVEY_POLICY.md b/Governance/community/SURVEY_POLICY.md new file mode 100644 index 00000000..5e8355e5 --- /dev/null +++ b/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. |