diff --git a/Governance/community/AMBASSADOR_PROGRAM.md b/Governance/community/AMBASSADOR_PROGRAM.md new file mode 100644 index 00000000..df64bc69 --- /dev/null +++ b/Governance/community/AMBASSADOR_PROGRAM.md @@ -0,0 +1,90 @@ +# Ambassador Program Policy + +## Purpose + +This policy establishes an ambassador program for TeachLink Web: community +members who help others discover, understand, and contribute to the project in +their own regions, languages, and communities. It states what ambassadors do, +how they are chosen, and how their work is recognised, so the program grows +trust rather than confusion about who speaks for the project. + +## Scope + +This policy applies to people who hold or apply for the ambassador title. +Ambassadors are community advocates, not maintainers: the title carries no merge +rights, no authority over governance decisions, and no authority to speak +officially for the project beyond the limits below. Official statements remain +governed by the press and media and social media policies, and the use of +project names and logos by the [Brand Usage](../BRAND_USAGE.md). + +## Ambassador Responsibilities + +Ambassadors volunteer time to: + +- welcome newcomers and point them to the [first-time contributor + guidance](../policies/FIRST_TIME_CONTRIBUTOR.md) and the [onboarding + process](../processes/ONBOARDING.md); +- share what the project does accurately, including its limits, and correct + misunderstandings they encounter; +- help organise or support local meetups, workshops, and translation or + documentation efforts in their community; +- collect feedback from their community and bring it to maintainers through + public issues or discussions; +- model the standards of the [Code of Conduct](../CODE_OF_CONDUCT.md) and + [Communication Norms](../policies/COMMUNICATION_NORMS.md). +- Ambassadors do not promise features, release dates, or support, do not handle + security reports (those follow the [Security Policy](../SECURITY_POLICY.md)), + and do not accept money or gifts in the project's name. + +## Selection + +Ambassadors are selected openly and fairly: + +- **Eligibility.** A candidate has at least 3 months of constructive + participation, is in good standing under the [Code of + Conduct](../CODE_OF_CONDUCT.md), and has no unresolved conduct case. +- **Nomination.** A candidate may self-nominate or be nominated by a + contributor, with a short statement of the community they would serve and what + they would do. +- **Decision.** Two maintainers review the nomination, check for conflicts of + interest under the [Conflict of Interest + policy](../policies/CONFLICT_OF_INTEREST.md), and record the decision and + reasons. The candidate is told the outcome either way. +- **Term.** A term is 12 months and can be renewed after a short check-in. An + ambassador may step down at any time. +- An ambassador who becomes inactive for 6 months, or who breaches the [Code of + Conduct](../CODE_OF_CONDUCT.md) or this policy, is removed from the program + through the same two-maintainer process, with a chance to respond. + +## Recognition + +The project recognises ambassadors without creating unequal status: + +- Ambassadors are listed in the contributor recognition materials described in + [Recognition](../RECOGNITION.md), with their consent. +- They may use the title "TeachLink Web Community Ambassador" while in good + standing, following the [Brand Usage](../BRAND_USAGE.md). +- Maintainers thank ambassadors publicly for specific contributions, such as + events held or translations completed. +- Recognition is for effort and impact, not for follower counts or the number of + people recruited, and is never tied to payment or perks that could create a + conflict of interest. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- A maintainer acts as program coordinator, keeps the list of current + ambassadors and their terms, and runs the annual review. +- 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 newcomers meet knowledgeable, welcoming people in +their own communities, when ambassadors are clearly understood not to speak +officially for the project, and when selection and removal are transparent and +fair. diff --git a/Governance/community/OFFICE_HOURS.md b/Governance/community/OFFICE_HOURS.md new file mode 100644 index 00000000..5145c4dd --- /dev/null +++ b/Governance/community/OFFICE_HOURS.md @@ -0,0 +1,84 @@ +# Office Hours Policy + +## Purpose + +This policy sets up regular community office hours for TeachLink Web: open +sessions where contributors and users can talk to maintainers about +contributions, designs, and questions that are hard to settle in an issue +thread. It defines the format so sessions are predictable, welcoming, and +transparent. + +## Scope + +This policy applies to the community office hours sessions and the channels used +to organise them. It does not replace public decision-making: office hours are +for discussion and help, and decisions made in a session are recorded in the +usual place (see the [RFC process](../processes/RFC_PROCESS.md) and the +[Communication Norms](../policies/COMMUNICATION_NORMS.md)). + +## Schedule and Format + +Sessions are designed to be easy to attend: + +- Sessions are held on a regular cadence, at least monthly, with the date, time + (in UTC), and joining details announced in the project's official channels at + least 7 days ahead. Where possible the time alternates to suit different time + zones. +- Each session lasts up to 60 minutes: an introduction and agenda, topics in the + order submitted, and open questions at the end. +- Sessions follow the [Code of Conduct](../CODE_OF_CONDUCT.md) and are open to + anyone. Accessibility is considered: the joining method works without special + software where possible, and notes are available for those who cannot attend. +- Sessions are not recorded unless every attendee is told in advance and the + host agrees; written notes are the default record. +- A session may be cancelled with notice if no topics are submitted or no host + is available. + +## Hosts + +Hosting is shared: + +- Hosts are maintainers or trusted contributors who volunteer; at least one + maintainer is present, and the host role rotates so no one person carries it. +- The host keeps to time, ensures everyone who wants to speak can, moves + unresolved topics to an issue or discussion, and enforces the [Code of + Conduct](../CODE_OF_CONDUCT.md). +- A host who has a conflict of interest in a topic hands that item to another + host (see the [Conflict of Interest + policy](../policies/CONFLICT_OF_INTEREST.md)). +- Hosts publish short notes after each session: attendees who consent to being + named, topics covered, and any follow-up actions with owners. + +## Submitting Topics + +Anyone can propose a topic: + +- Topics are submitted at least 48 hours ahead through a comment on the + session's announcement issue or discussion, with a short description and a + link to any related issue or pull request. +- Good topics are questions about contributing, requests for design feedback, + help getting unstuck, and community ideas. Security vulnerabilities must not + be raised in a session; they follow the [Security + Policy](../SECURITY_POLICY.md). +- Items are taken in submission order, with newcomer questions given priority. + Same-day topics are taken if time remains. +- Anything that needs a decision is turned into a public issue or an [RFC + process](../processes/RFC_PROCESS.md) rather than decided in the room. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- A maintainer maintains the schedule, host rotation, and archive of session + notes. +- 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 sessions run on schedule, when newcomers get timely +answers, and when every outcome is recorded publicly so those who could not +attend are not left behind. diff --git a/Governance/community/REVIEW_ETIQUETTE.md b/Governance/community/REVIEW_ETIQUETTE.md new file mode 100644 index 00000000..38ba856b --- /dev/null +++ b/Governance/community/REVIEW_ETIQUETTE.md @@ -0,0 +1,86 @@ +# Code Review Etiquette Guide + +## Purpose + +This guide describes the tone and habits we expect in code review on TeachLink +Web. Review is how the project keeps quality high and how contributors learn +from each other; done well it is respectful, specific, and quick. It complements +the formal rules of the [Review Policy](../policies/REVIEW_POLICY.md). + +## Scope + +This guide applies to everyone who writes or reviews a pull request in this +repository: authors, reviewers, and maintainers, in comments, suggestions, and +review discussions. It covers behaviour; what must be checked, how many +approvals are needed, and reviewer independence are set out in the [Review +Policy](../policies/REVIEW_POLICY.md) and the approval requirements policy. + +## Tone and Expectations + +Review the code, not the person: + +- Assume good intent and that the author did their best with what they knew. +- Be specific and kind: say what the issue is, why it matters, and, when you + can, how to fix it. Prefer questions ("What happens if this is empty?") to + commands. +- Separate required changes from preferences. Label optional comments (for + example "nit:" or "optional:") so the author knows what blocks merge. +- Praise good work. A short "nice solution" costs nothing. +- Avoid sarcasm, absolutes, and personal remarks; follow the [Code of + Conduct](../CODE_OF_CONDUCT.md) and [Communication + Norms](../policies/COMMUNICATION_NORMS.md). +- Use inclusive wording and avoid assumptions about the author's background. + +## Author and Reviewer Norms + +**Authors**: + +- Keep pull requests small and focused, describe the change and how you tested + it, and link the issue. +- Review your own diff first, and answer comments or push fixes promptly; if you + disagree, say why. +- Do not take comments personally and do not mark conversations resolved on the + reviewer's behalf unless asked. +- **Reviewers**: +- Respond within the review window in the project's review SLA, or say that you + cannot and release the review. +- Review the whole change, not only the part you know; say what you did not + review. +- Approve when the change is good enough to merge, not when it is perfect; + follow up on non-blocking points in an issue. +- Do not approve changes you do not understand, and do not hold a change up over + style the linter already covers. + +## Handling Disagreement + +When author and reviewer disagree: + +- Explain your reasoning with evidence (a test, a doc, a measurement) and listen + to the other side. +- If a comment thread goes in circles after two rounds, move to a short call or + ask a third maintainer for an opinion. +- For technical decisions that affect others, use the [RFC + process](../processes/RFC_PROCESS.md); for stalled reviews use the [escalation + path](../processes/ESCALATION_PATH.md). +- A maintainer decides when consensus cannot be reached and records the reason + on the pull request. +- If a discussion becomes heated or disrespectful, pause it. Report concerns + through [Code of Conduct reporting](../COC_REPORTING.md). + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- Contributors are invited to suggest improvements based on their review + experience; the guide is revisited at least once a year. +- 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 reviews are timely and specific, when authors leave a +review feeling respected and more skilled, and when disagreements are settled +with evidence rather than friction. diff --git a/Governance/community/WELCOME_GUIDE.md b/Governance/community/WELCOME_GUIDE.md new file mode 100644 index 00000000..a6638008 --- /dev/null +++ b/Governance/community/WELCOME_GUIDE.md @@ -0,0 +1,92 @@ +# Newcomer Welcome Guide + +## Purpose + +Welcome to TeachLink Web. This guide gets a newcomer from "I'm interested" to a +first contribution: what to do first, which resources to read, and where to ask +for help. You do not need to be an expert, and you do not need permission to +start. + +## Scope + +This guide is for anyone new to the project, whether you plan to write code, +improve documentation, report bugs, help with design or translation, or answer +questions. It is a starting map; the linked documents are the authoritative +source for each topic. + +## First Steps + +A good first week looks like this: + +- **Read the basics.** Skim the repository [README](../../README.md) to see what + the project is and how to run it, then read the [Mission](../MISSION.md) and + [Values](../VALUES.md). +- **Read the rules of the road.** Read the [Code of + Conduct](../CODE_OF_CONDUCT.md) and the [Communication + Norms](../policies/COMMUNICATION_NORMS.md). They apply to everyone, every + time. +- **Set up locally.** Follow the setup steps in the README and + [CONTRIBUTING.md](../../CONTRIBUTING.md) so you can build and run the checks + before you change anything. +- **Find something small.** Browse issues labelled for newcomers, following the + [good first issue policy](../policies/GOOD_FIRST_ISSUE.md). Comment that you + would like to take one, and wait for a maintainer to confirm so work is not + duplicated. +- **Open your first pull request.** Keep it small and focused, link the issue, + explain what changed, and sign off your commits as described in the [DCO + policy](../policies/DCO.md). +- **Expect feedback.** Review comments are a normal part of the process and are + about the change, not about you. See the [Review + Policy](../policies/REVIEW_POLICY.md). + +## Key Resources + +Keep these close: + +- [CONTRIBUTING.md](../../CONTRIBUTING.md) - branching, checks, and the pull + request workflow. +- [Governance README](../README.md) - how decisions are made and where each + policy lives. +- [Scope](../SCOPE.md) - what the project does and does not take on, so you know + whether an idea fits. +- [Label taxonomy](../LABEL_TAXONOMY.md) - what the issue and pull request + labels mean. +- [Contributor role](../roles/CONTRIBUTOR.md) and the [onboarding + process](../processes/ONBOARDING.md) - what to expect as you take on more. +- [Security Policy](../SECURITY_POLICY.md) - how to report a vulnerability + privately; never post one in a public issue. + +## Where to Get Help + +You are never expected to struggle alone: + +- Ask a question on the issue you are working on, in the pull request, or in + GitHub Discussions when it is enabled, so the answer helps the next person + too. +- Join the community office hours when they are running (see the [onboarding + process](../processes/ONBOARDING.md) and the office hours policy in this + folder). +- If you are stuck on process, ask a maintainer to point you at the right + document; if a document is wrong or unclear, fixing it is a great first + contribution. +- If anyone behaves in a way that makes you uncomfortable, use [Code of Conduct + reporting](../COC_REPORTING.md). +- If you are stuck for several days with no reply, follow the [escalation + path](../processes/ESCALATION_PATH.md). + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- Anyone who finds the guide out of date is encouraged to fix it; a maintainer + checks the links and steps at least once per release cycle. +- 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 a newcomer can find the next step without asking, makes +a first contribution they are proud of, and feels welcome doing it.