From cbfc6c9e81e07667a6c76390389849b89d888b9f Mon Sep 17 00:00:00 2001 From: monique-7arch Date: Fri, 16 Oct 2026 09:54:34 +0100 Subject: [PATCH] docs(governance): add sponsorship, representation, survey and contributor agreement documents --- Governance/community/CONTRIBUTOR_AGREEMENT.md | 89 +++++++++++++++++++ Governance/community/REPRESENTATION.md | 83 +++++++++++++++++ Governance/community/SPONSORSHIP.md | 85 ++++++++++++++++++ Governance/community/SURVEY_POLICY.md | 88 ++++++++++++++++++ 4 files changed, 345 insertions(+) create mode 100644 Governance/community/CONTRIBUTOR_AGREEMENT.md create mode 100644 Governance/community/REPRESENTATION.md create mode 100644 Governance/community/SPONSORSHIP.md create mode 100644 Governance/community/SURVEY_POLICY.md diff --git a/Governance/community/CONTRIBUTOR_AGREEMENT.md b/Governance/community/CONTRIBUTOR_AGREEMENT.md new file mode 100644 index 00000000..b264a841 --- /dev/null +++ b/Governance/community/CONTRIBUTOR_AGREEMENT.md @@ -0,0 +1,89 @@ +# Contributor Agreement Overview + +## Purpose + +This document gives contributors a plain-language overview of what they agree to +when they contribute to TeachLink Web: the rights they grant, the promises they +make about their work, and how that agreement is shown and recorded. It +summarises the agreement; the governing text is the repository's licence and the +[DCO policy](../policies/DCO.md), which prevail if this overview differs. + +## Scope + +This overview applies to every contribution to the repository: code, +documentation, designs, translations, and other material submitted by pull +request, issue, or other means. It is not legal advice and does not create +obligations beyond the licence and sign-off terms. See the [Third-Party Licenses +policy](../policies/THIRD_PARTY_LICENSES.md) for how third-party material is +handled. + +## What Contributors Agree To + +By submitting a contribution, you confirm that: + +- you wrote it, or you have the right to submit it under the repository's + licence; +- you understand the contribution and a record of it (including your name and + email in the commit history) will be public and permanent; +- your contribution is licensed under the same licence as the project, and you + grant the project and its users the rights that licence provides, including + the right to modify and redistribute it; +- if your employer or another party has rights in your work, you have permission + to contribute it; +- you will not knowingly include code or content you cannot license, secrets, or + personal data of others. +- You keep ownership of your contribution unless you agree otherwise, and you + are credited as described in the [Recognition](../RECOGNITION.md). + +## Sign-off Mechanism + +Agreement is shown by signing off every commit: + +- Add a `Signed-off-by: Your Name ` line to each commit, for + example with `git commit -s`, using your real name or an established project + identity and an email address you control. +- The sign-off certifies the Developer Certificate of Origin; the exact wording, + how it is checked, and what happens when it is missing are set out in the [DCO + policy](../policies/DCO.md). +- A pull request with commits missing a sign-off is not merged until it is + fixed; maintainers will explain how to amend. +- Contributions made on behalf of an employer should be signed off by someone + with authority to agree, and the employer can contact the maintainers to + authorise their staff. +- Maintainers do not merge contributions they believe are not licensable. + +## Where Records Are Kept + +The agreement is evidenced in places that are public and durable: + +- The commit history, including each sign-off, is the primary record of each + contribution and its author. +- The pull request thread records the review, any questions about origin, and + the maintainers' decision. +- Written authorisations from employers, and any permission to contribute + material from another source, are kept by the maintainers as described in the + record retention and legal hold policy. +- A contributor can ask the maintainers to correct their recorded name or email, + or to withdraw a pending contribution. Merged contributions remain in the + history because of how version control works, though material can be removed + from future versions where there is a legal reason to do so. +- Changes to the agreement are made only through a governance pull request and + never apply retroactively to contributions already accepted. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- Maintainers review this overview whenever the licence or the DCO policy + changes. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This overview succeeds when a new contributor can read it in a few minutes and +understand what they are agreeing to, and when every contribution can be traced +to a signed-off commit. diff --git a/Governance/community/REPRESENTATION.md b/Governance/community/REPRESENTATION.md new file mode 100644 index 00000000..3f123f8a --- /dev/null +++ b/Governance/community/REPRESENTATION.md @@ -0,0 +1,83 @@ +# Representation and Speaking Policy + +## Purpose + +This policy says who may represent TeachLink Web at conferences, meetups, +panels, and other public forums, how that is approved, and what must be +disclosed. It protects the project's reputation, helps contributors take +speaking opportunities fairly, and makes clear when a speaker is talking for the +project. + +## Scope + +This policy applies to talks, workshops, panels, interviews, and booth or +sponsorship appearances where a person is introduced as a TeachLink Web +maintainer, contributor, or representative. It covers the speaker's role only; +communication with journalists is governed by the press and media policy +(`MEDIA_POLICY.md`) and event hosting by the events policy (`EVENTS_POLICY.md`). + +## Who May Represent the Project + +Representing the project is open but deliberate: + +- Any contributor in good standing may speak **about** TeachLink Web, accurately + and in their own name. +- Speaking **on behalf of** the project (presenting a position, answering as the + project's voice, or taking the project's slot at an event) is limited to + maintainers and to contributors a maintainer has approved for that occasion. +- Invitations are shared with the community where practical so opportunities are + spread fairly and newer contributors are given a chance to speak, especially + when a maintainer cannot attend. +- A contributor who is subject to an active conduct sanction under the [Code of + Conduct](../CODE_OF_CONDUCT.md) does not represent the project. + +## Approval Process + +Before accepting a role that speaks for the project: + +- Tell the maintainers in an issue or the project's designated channel at least + 14 days before the event, with the event, topic, date, audience, and any fee + or travel support offered. +- Two maintainers approve the topic and role, check for conflicts of interest + under the [Conflict of Interest policy](../policies/CONFLICT_OF_INTEREST.md), + and record the decision; no response in the review window means the speaker + may speak about the project but not for it. +- Slides and demos that present the project's roadmap, security matters, or + numbers about users are checked against what the project has already + published. +- After the event, the speaker may share a short summary and slides with the + community, which counts toward [Recognition](../RECOGNITION.md). + +## Disclosure Rules + +Speakers are open about their position and interests: + +- State at the start whether you speak for the project or for yourself, and say + if your employer, a sponsor, or an organiser pays for your travel or time. +- Disclose any financial interest in products or services you mention, in line + with the [Conflict of Interest policy](../policies/CONFLICT_OF_INTEREST.md). +- Do not present unreleased features, private conversations, security issues, or + personal data of contributors or users. +- Use the project name and logo only as the [Brand Usage](../BRAND_USAGE.md) + allows, and follow the [Code of Conduct](../CODE_OF_CONDUCT.md) in all + dealings with organisers and audiences. +- A speaker who finds that the event does not meet the project's standards for + safety or conduct may withdraw and tell the maintainers. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- A maintainer keeps the list of approved appearances and the disclosure + statements given. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when audiences know who is speaking for the project, when +speaking opportunities are shared fairly, and when no one misrepresents the +project's positions. diff --git a/Governance/community/SPONSORSHIP.md b/Governance/community/SPONSORSHIP.md new file mode 100644 index 00000000..364b15db --- /dev/null +++ b/Governance/community/SPONSORSHIP.md @@ -0,0 +1,85 @@ +# Donation and Sponsorship Policy + +## Purpose + +This policy sets out how TeachLink Web accepts donations and sponsorship, what +conflicts of interest must be avoided, and what the project commits to make +public. It lets supporters help the project while keeping its decisions +independent and its finances open. + +## Scope + +This policy applies to money, goods, services, and in-kind support offered to +the project or to events held in its name, whether from individuals, companies, +or other organisations. Management of project funds falls to the [Treasurer +role](../roles/TREASURER.md), and sponsorship of community events also follows +the community events policy in this folder (`EVENTS_POLICY.md`) where it exists. + +## Accepted Sponsorship Forms + +The project may accept: + +- **Cash donations** from individuals and organisations, one-off or recurring, + through the channels listed in the repository. +- **Sponsorship** of infrastructure, tooling, events, or contributor time, where + the support is described in a written, public agreement. +- **In-kind support**, such as hosting credits, licences, or services, when the + terms are recorded and do not restrict the project's choices. +- The project does not accept support that is conditional on: control of the + roadmap or technical decisions, exclusivity, access to user data, changes to + review or release outcomes, or silence about a sponsor's conduct. +- Sponsors from sectors or jurisdictions that conflict with the [Code of + Conduct](../CODE_OF_CONDUCT.md) or the project's legal obligations may be + declined. + +## Conflict-of-Interest Rules + +Funding must not become influence: + +- Sponsorship gives recognition only, not a vote, a maintainer seat, or priority + for issues or pull requests. +- A maintainer or contributor who is employed by, or has a financial + relationship with, a sponsor declares it and steps out of decisions that + directly concern that sponsor, as required by the [Conflict of Interest + policy](../policies/CONFLICT_OF_INTEREST.md). +- Sponsor-funded work is proposed, reviewed, and merged under the same rules as + any other change (see the [Review Policy](../policies/REVIEW_POLICY.md)). +- Gifts to individual contributors from sponsors are disclosed to the + maintainers and are not accepted if they could reasonably appear to affect a + decision. +- The project does not endorse a sponsor's products; sponsor acknowledgement + follows the [Brand Usage](../BRAND_USAGE.md). + +## Transparency Commitments + +The project publishes: + +- a public list of sponsors and the amounts or categories of support received, + unless a donor asks to be anonymous and the maintainers agree; +- a periodic summary of income and spending by category, prepared by the + [Treasurer role](../roles/TREASURER.md) and included in the [Transparency + Reports](../policies/TRANSPARENCY_REPORTS.md); +- the terms under which each significant sponsorship was accepted, with personal + data removed; +- any declined offer of significant size and the reason, when this can be said + without harming the donor. +- Records of funds are kept for the periods set out in the record retention and + legal hold policy and are available to maintainers for audit. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The treasurer reviews sponsorship records each quarter and reports any term + that conflicts with this policy. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when supporters can help with clear expectations, when no +sponsor gains influence over project decisions, and when anyone can see where +the project's support comes from and how it is used. diff --git a/Governance/community/SURVEY_POLICY.md b/Governance/community/SURVEY_POLICY.md new file mode 100644 index 00000000..4638e924 --- /dev/null +++ b/Governance/community/SURVEY_POLICY.md @@ -0,0 +1,88 @@ +# Community Survey Policy + +## Purpose + +This policy defines how TeachLink Web runs surveys of its community: how they +are designed and announced, how responses are kept private, and how results are +shared. Done carefully, surveys help the project listen to contributors and +users without burdening them or misusing their data. + +## Scope + +This policy applies to surveys, polls, and questionnaires run by or on behalf of +the project that collect responses from contributors, users, or the wider +community. Data collection inside the product is covered by the [Analytics Data +Collection](../domains/ANALYTICS_DATA.md) and the [Privacy Notice +governance](../domains/PRIVACY_NOTICE.md). + +## How Surveys Are Run + +Each survey follows a short process: + +- **Proposal.** A maintainer or contributor opens an issue stating the goal, the + questions, the audience, the duration, and how the results will be used. Two + maintainers approve it. +- **Design.** Questions are as few as needed, neutral, and inclusive (see the + community inclusive language guide), and each is optional unless essential. + Demographic questions are optional and justified. +- **Announcement.** The survey is announced in the project's official channels + with the purpose, how long it takes, who will see the responses, and the + closing date. No more than one general community survey runs at a time and + none runs more often than once every 6 months, so people are not + over-surveyed. +- **Consent.** Taking part is voluntary; the survey says so and links to the + data handling statement. Children are not surveyed without the safeguards in + the children's data policy. +- **Tools.** Only tools approved under the vendor risk management policy are + used. + +## Privacy of Responses + +Respondents are protected: + +- Surveys are anonymous by default. If identification is needed (for example to + follow up), the survey says why, and the identifying data is stored separately + and deleted when it is no longer required. +- Only the survey owner and the maintainers named in the proposal can see raw + responses; free-text answers are reviewed for personal data before anything is + quoted. +- Raw responses are kept for no longer than the stated period, and then deleted + according to the record retention and legal hold policy. +- Results are never used to identify, rank, or discipline individuals, and + responses are not shared with sponsors or third parties. +- Where a respondent can be identified, the project applies the privacy and + erasure principles in the [Privacy Notice + governance](../domains/PRIVACY_NOTICE.md). + +## Sharing Results + +The community sees what it contributed to: + +- A summary of results is published within 60 days of the survey closing, in the + same channels used to announce it. +- Results are reported in aggregate; groups smaller than 5 are merged or + withheld so nobody can be identified. +- The summary states the number of respondents, the response rate, the limits of + the sample, and the decisions or follow-up actions the results informed. +- Open-ended answers are summarised or lightly edited with consent; quotes never + reveal identity. +- Where it is safe to do so, anonymised data is published so others can check + the findings. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The survey owner is responsible for each step in the survey's life cycle, from + approval to deletion of raw data. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when surveys are rare, short, and purposeful, when +respondents trust that their answers are private, and when the community sees +what changed because of what it said.