docs(governance): add sponsorship, representation, survey and contributor agreement documents

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 <you@example.com>` 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.

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.

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.

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.