docs(governance): add inclusive language, events, social media and media policies

Governance/community/EVENTS_POLICY.md

@@ -0,0 +1,92 @@
+# Community Events Policy
+
+## Purpose
+
+This policy defines how community events related to TeachLink Web are proposed,
+run, and supported. It lets contributors organise meetups, workshops,
+hackathons, and online sessions that reflect the project's values, while
+protecting attendees and keeping the project's name from being used carelessly.
+
+## Scope
+
+This policy applies to events that use the TeachLink Web name, are announced in
+the project's official channels, or are presented as supported by the project,
+whether in person or online. Independent events that do not claim project
+backing are outside this policy, but their organisers are welcome to ask for
+guidance. Use of the project name and logo follows the [Brand
+Usage](../BRAND_USAGE.md).
+
+## Proposing an Event
+
+An organiser who wants project support opens an issue at least 30 days before
+the event with:
+
+- the purpose, format, expected audience, date, time zone, and location or
+  platform;
+- the organisers, their roles, and how attendees can contact them;
+- the budget and any sponsors or funding sought, and how accessibility needs
+  will be met;
+- how the event will use the project's name, and who will represent the project,
+  if anyone.
+- Two maintainers review the proposal against this policy and the
+  [Scope](../SCOPE.md), record approval or the reasons for declining, and agree
+  what support the project will give (announcements, speaker time, recognition).
+  Approval does not make the event an official project activity unless the
+  approval says so.
+
+## Code of Conduct Applicability
+
+The [Code of Conduct](../CODE_OF_CONDUCT.md) applies at every event that uses
+the project's name:
+
+- Organisers publish the Code of Conduct and a named contact for reports before
+  registration opens, and brief staff and volunteers on how to respond.
+- A report made at an event can be sent to the organisers on site and to the
+  project through [Code of Conduct reporting](../COC_REPORTING.md); the
+  project's enforcement procedures apply to participants who are also
+  contributors.
+- Organisers choose venues and platforms that are accessible, provide captions
+  or equivalent for online sessions where possible, and state any registration
+  or recording rules in advance.
+- Organisers do not ask attendees for more personal data than they need, and
+  handle it as described in the [Privacy Notice
+  governance](../domains/PRIVACY_NOTICE.md).
+- An event that does not follow the Code of Conduct may lose its approval and
+  the right to use the project name.
+
+## Sponsorship Rules
+
+Funding must not compromise independence or trust:
+
+- Sponsors are disclosed publicly on the event page, and sponsorship does not
+  buy influence over project decisions, speaking slots on technical content, or
+  review outcomes.
+- Organisers follow the [Conflict of Interest
+  policy](../policies/CONFLICT_OF_INTEREST.md) and tell maintainers of any
+  relationship that could look like a conflict.
+- Money raised in the project's name is handled transparently; where the
+  project's funds are involved, the [Treasurer role](../roles/TREASURER.md) role
+  applies.
+- Sponsors may not use the event to collect attendee data for marketing without
+  informed, separate consent (see the [Cookie and Consent
+  governance](../domains/COOKIE_CONSENT.md) for the consent principles).
+- After the event, organisers post a short summary: attendance, sponsors,
+  expenses, and lessons learned.
+
+## Ownership and Review
+
+- Maintainers own this document and are accountable for applying it
+  consistently.
+- A maintainer keeps the events list and records approvals, withdrawals, and
+  post-event summaries.
+- 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 events that carry the project's name are safe,
+accessible, and transparently funded, and when contributors know how to propose
+one.

Governance/community/INCLUSIVE_LANGUAGE.md

@@ -0,0 +1,90 @@
+# Inclusive Language Guide
+
+## Purpose
+
+This guide helps contributors write and speak in a way that welcomes everyone to
+TeachLink Web. It lists preferred terms, terms to avoid, and how the guide is
+applied, so inclusive wording is a shared habit rather than a matter of personal
+taste. It supports, and does not replace, the [Code of
+Conduct](../CODE_OF_CONDUCT.md).
+
+## Scope
+
+This guide applies to everything contributors write for the project: code
+(identifiers, comments, commit messages), documentation, issue and pull request
+text, UI copy, release notes, and discussion in project channels. Localised
+content follows the [I18N Governance](../domains/I18N_GOVERNANCE.md) for
+language-specific choices.
+
+## Preferred Terms
+
+Choose precise, neutral words:
+
+- **allowlist / denylist** for lists of permitted or blocked items.
+- **primary / replica** (or **leader / follower**) for roles in a system.
+- **main** for the default branch, as this repository does.
+- **placeholder value**, **sample data**, or **stub** instead of terms that
+  stereotype.
+- **people**, **everyone**, **folks**, or **team** instead of gendered group
+  terms such as "guys".
+- **they** for a single person whose pronouns are not known; use the pronouns a
+  person tells you.
+- **stop** or **end** instead of violent metaphors such as "kill" where a calmer
+  verb is just as clear, and **confidence check** instead of "sanity check".
+- Plain, literal wording rather than idioms that may not translate. Many
+  contributors and learners read English as an additional language.
+
+## Terms to Avoid
+
+Avoid language that excludes, stereotypes, or harms:
+
+- master/slave, whitelist/blacklist, and similar terms that carry racial
+  connotations.
+- Ableist terms used as insults or metaphors (for example "crazy", "lame",
+  "blind to", "crippled").
+- Gendered defaults ("he", "manpower", "man-hours") when the person or group is
+  unspecified.
+- Terms that assume background or ability, such as "obviously", "simply",
+  "just", and "everyone knows", which make learners feel behind.
+- Slurs, jokes at the expense of a group, and sexual or violent humour in any
+  project space.
+- External names we cannot change (a vendor API field, a standard's keyword) are
+  not renamed in third-party code; wrap them where practical and say why the
+  original is used.
+
+## How It Is Enforced
+
+The aim is education first:
+
+- Reviewers raise a wording concern as a normal review comment, with a suggested
+  alternative and, where helpful, a link to this guide. The author is expected
+  to address it as they would any review note.
+- Existing terms are updated gradually: a pull request that touches a line is a
+  good moment to improve its wording, and dedicated renaming pull requests are
+  welcome when they stay small and avoid breaking public APIs (follow the
+  [Deprecation policy](../policies/DEPRECATION.md)).
+- A repeated disregard of the guide, or deliberate use of exclusionary language,
+  is a conduct matter handled through [Code of Conduct
+  reporting](../COC_REPORTING.md) and the [Moderation
+  policy](../policies/MODERATION.md).
+- Disagreements about a term are resolved by asking whether it could exclude or
+  hurt someone and whether a clear alternative exists; a maintainer decides and
+  records the outcome if the discussion cannot settle it.
+
+## Ownership and Review
+
+- Maintainers own this document and are accountable for applying it
+  consistently.
+- Anyone may propose additions to the preferred and avoided terms by pull
+  request with a short rationale.
+- 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 guide succeeds when contributors reach for inclusive wording by habit, when
+reviewers can point to a shared reference instead of personal opinion, and when
+no one is made to feel unwelcome by the project's words.

Governance/community/MEDIA_POLICY.md

@@ -0,0 +1,85 @@
+# Press and Media Policy
+
+## Purpose
+
+This policy says who may speak to journalists, researchers, and other media on
+behalf of TeachLink Web, how statements are approved, and what messages are
+consistent with the project. It protects contributors from being misquoted or
+pressured and makes the project's public statements accurate and coordinated.
+
+## Scope
+
+This policy applies to interviews, press releases, quotes, podcasts, conference
+press, and other communications with media or analysts that concern the project.
+It is read together with the social media policy
+([SOCIAL_MEDIA.md](SOCIAL_MEDIA.md)) and the use of project names and logos
+described in the [Brand Usage](../BRAND_USAGE.md).
+
+## Who Speaks to Media
+
+Spokespeople are limited so statements are consistent:
+
+- The lead maintainers, or maintainers they designate for a topic, may speak for
+  the project.
+- Any other contributor who is approached by media says they speak for
+  themselves, not for the project, unless a maintainer has agreed otherwise in
+  writing.
+- Anyone approached directly forwards the request to the maintainers through the
+  project's designated contact within 2 business days, without committing to an
+  interview or deadline.
+- Spokespeople never share private information about contributors, users,
+  security matters, or conduct cases (see the [Security
+  Policy](../SECURITY_POLICY.md) and [Code of Conduct
+  reporting](../COC_REPORTING.md)).
+
+## Approval Process
+
+Statements are approved before they are released:
+
+- A maintainer acknowledges each request, notes the outlet, topic, deadline, and
+  what is being asked, and records it.
+- For written statements and press releases, two maintainers review the text for
+  accuracy, privacy, and consistency with published project decisions, and
+  approve it in the request thread.
+- For live or recorded interviews, the spokesperson is briefed on the topics,
+  the facts that may be shared, and the matters that must not be discussed, and
+  may ask to review quotes before publication.
+- Urgent statements about security incidents follow the [Security
+  Policy](../SECURITY_POLICY.md) and may be approved by one maintainer with the
+  second maintainer informed immediately afterwards.
+- Approved statements are published on the project's official channels so the
+  public record is complete.
+
+## Messaging Guidance
+
+Messages are factual and in line with the project's purpose:
+
+- Describe the project using the [Mission](../MISSION.md) and
+  [Vision](../VISION.md); do not claim endorsements, adoption numbers, or
+  roadmap dates that are not published.
+- Distinguish clearly between what is released, what is planned, and what is an
+  opinion of the speaker.
+- Be neutral about other projects and vendors, and disclose any affiliation or
+  sponsorship (see the [Conflict of Interest
+  policy](../policies/CONFLICT_OF_INTEREST.md)).
+- Do not speculate about incidents under investigation; say what is known, what
+  is being done, and when the next update is expected.
+- Acknowledge contributors accurately and with their consent, and correct errors
+  in coverage by contacting the outlet politely and recording the correction.
+
+## Ownership and Review
+
+- Maintainers own this document and are accountable for applying it
+  consistently.
+- Maintainers keep the request log and the list of designated spokespeople.
+- 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 the project's public statements are accurate and
+consistent, when contributors are not pulled into speaking for the project
+against their will, and when every statement can be traced to an approval.

Governance/community/SOCIAL_MEDIA.md

@@ -0,0 +1,88 @@
+# Social Media Policy
+
+## Purpose
+
+This policy sets rules for the project's official social media presence and for
+how contributors talk about TeachLink Web on social media. It keeps the
+project's public voice consistent, respectful, and honest, and makes clear when
+someone speaks for the project and when they speak for themselves.
+
+## Scope
+
+This policy applies to the project's official accounts and to contributors who
+identify themselves as connected with the project when posting. Statements to
+journalists and formal public statements are covered by the press and media
+policy in this folder ([MEDIA_POLICY.md](MEDIA_POLICY.md)). Personal accounts
+are otherwise the individual's own; this policy asks only for the courtesy of
+clarity.
+
+## Who May Post Officially
+
+Official accounts speak for the project, so access is limited:
+
+- Only maintainers, and contributors the maintainers have designated in writing
+  as social media stewards, may post from official accounts.
+- Stewards post about releases, events, community news, and recognised
+  contributions. They do not announce policy changes, roadmap commitments, or
+  security matters that have not been published through the proper process.
+- Access to accounts follows least privilege, uses strong authentication, and is
+  reviewed on the cadence in the access review policy; credentials are never
+  shared in chat or issues.
+- A steward who leaves the role hands over the account and has their access
+  removed the same day.
+
+## Tone and Disclosure
+
+Posts are written to reflect the [Code of Conduct](../CODE_OF_CONDUCT.md) and
+the project's [values](../VALUES.md):
+
+- Be accurate, courteous, and inclusive (see the [Communication
+  Norms](../policies/COMMUNICATION_NORMS.md)); correct mistakes openly and
+  promptly rather than deleting them.
+- Do not argue with critics, disparage other projects or people, or post about
+  private conduct cases or security details.
+- Credit contributors and sources, and obtain consent before sharing a person's
+  words, image, or personal information.
+- Disclose relationships: a contributor who posts about the project while paid
+  by or affiliated with a vendor says so. Paid promotion and sponsored content
+  are labelled as such.
+- Contributors posting from personal accounts should make clear they speak for
+  themselves and not for the project, unless they are acting under the [Brand
+  Usage](../BRAND_USAGE.md) and the press and media policy.
+
+## Escalation
+
+When something goes wrong:
+
+- A post that is wrong, harmful, or exposes private information is taken down or
+  corrected immediately by a steward, and a maintainer is told.
+- Harassment, threats, or abuse aimed at the project or its contributors are not
+  answered in kind; they are recorded, reported to the platform where
+  appropriate, and handled through [Code of Conduct
+  reporting](../COC_REPORTING.md) when a contributor is involved.
+- Mentions of a possible vulnerability are moved to the private reporting
+  channel in the [Security Policy](../SECURITY_POLICY.md) and not discussed
+  publicly.
+- Media enquiries received on social media are passed to the people named in the
+  press and media policy.
+- Serious or unclear cases follow the [escalation
+  path](../processes/ESCALATION_PATH.md). Lessons from an incident are recorded
+  and this policy updated if it fell short.
+
+## Ownership and Review
+
+- Maintainers own this document and are accountable for applying it
+  consistently.
+- Maintainers keep the list of social media stewards and the inventory of
+  official accounts.
+- 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 the project's public voice is consistent and
+trustworthy, when it is clear who speaks for the project, and when mistakes are
+corrected quickly and in the open.