docs(governance): add ambassador, welcome, office hours and review etiquette guides

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.

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.

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.

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.