diff --git a/Governance/community/EVENTS_POLICY.md b/Governance/community/EVENTS_POLICY.md new file mode 100644 index 00000000..c02ecd4d --- /dev/null +++ b/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. diff --git a/Governance/community/INCLUSIVE_LANGUAGE.md b/Governance/community/INCLUSIVE_LANGUAGE.md new file mode 100644 index 00000000..8999960c --- /dev/null +++ b/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. diff --git a/Governance/community/MEDIA_POLICY.md b/Governance/community/MEDIA_POLICY.md new file mode 100644 index 00000000..0a9769b4 --- /dev/null +++ b/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. diff --git a/Governance/community/SOCIAL_MEDIA.md b/Governance/community/SOCIAL_MEDIA.md new file mode 100644 index 00000000..b8f3841d --- /dev/null +++ b/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.