Docs/add meeting minutes template

Governance/policies/QUORUM.md

@@ -0,0 +1,28 @@
+# Governance/policies/QUORUM.md
+# Voting Quorum Policy
+
+## 1. Overview
+This policy establishes the voting quorum requirements for governance decisions, RFC approvals, core maintainer elections, and repository policy changes within TeachLink. Establishing a clear quorum ensures that decisions have sufficient backing from the community and core maintainers before being enacted.
+
+---
+
+## 2. Quorum Thresholds
+Quorum requirements vary depending on the scope and impact of the decision:
+* **Standard Governance Proposals & Feature RFCs:** A minimum of **50% plus one** of active core maintainers must participate in the vote.
+* **Core Maintainer Additions / Removals:** At least **75%** of active core maintainers must participate.
+* **Constitutional or Policy Overhauls:** At least **66%** of active voting members must participate.
+
+---
+
+## 3. Measurement of Quorum
+* **Eligible Voters:** Defined as active contributors holding maintainer or voting status at the time the vote is officially opened.
+* **Participation Calculation:** Quorum is measured by the total number of cast votes (including affirmative (`Yes`), negative (`No`), and formal abstentions (`Abstain`)) relative to the total number of eligible voters.
+* **Approval Requirement:** In addition to meeting quorum, a proposal passes if it achieves a simple majority (or supermajority where specified) of non-abstaining votes.
+
+---
+
+## 4. Procedure When Quorum Is Not Met
+If a voting period closes and the required quorum threshold has not been reached:
+1. **Extension:** The voting window is automatically extended once by an additional 72 hours.
+2. **Notification:** Maintainers are notified via communication channels (e.g., issue/PR comments or governance meetings).
+3. **Deferral:** If quorum remains unmet after the extension period, the proposal is marked as **Defeated due to Lack of Quorum** and must be revised or re-proposed in a subsequent governance cycle.

Governance/processes/WORKING_GROUP_FORMATION.md

@@ -0,0 +1,29 @@
+# Governance/processes/WORKING_GROUP_FORMATION.md
+# Working Group Formation Process
+
+## 1. Overview
+Working Groups (WGs) are focused, temporary or ongoing sub-teams dedicated to specific domains within TeachLink (e.g., Curriculum Design, Core Infrastructure, Accessibility, Security). This document defines the formal lifecycle and process for proposing, chartering, and operating a Working Group.
+
+---
+
+## 2. Proposal Phase
+To propose a new Working Group, a contributor or maintainer must submit a formal Working Group Proposal via a pull request adding a charter document under the `Governance/working-groups/` directory. The proposal must include:
+* **Name & Mission:** A clear title and concise description of the group's scope and objectives.
+* **Lead / Chair:** Designated initial lead(s) responsible for organizing meetings and reporting progress.
+* **Initial Members:** A minimum of 3 committed participants from at least 2 distinct organizations or contributor groups.
+* **Communication Channels:** Proposed sync meeting frequency, issue tracking labels, or chat channels.
+
+---
+
+## 3. Approval Requirements
+* **Review Period:** The proposal PR must remain open for public comment and peer review by core maintainers for a minimum of **7 calendar days**.
+* **Approval Threshold:** Approval requires consensus among core maintainers or a successful majority vote adhering to the [Quorum Policy](../policies/QUORUM.md).
+* **Charter Ratification:** Upon approval, the working group is officially chartered, and its directory is merged into the main repository.
+
+---
+
+## 4. Initial Deliverables
+Within 60 days of official formation, a newly chartered Working Group must deliver:
+1. **Roadmap & Objectives:** An initial scope of work with milestone targets for the current release or quarter.
+2. **Meeting Cadence:** Established recurring public syncs with published meeting notes.
+3. **Point of Contact:** Active communication handles for community members seeking guidance or collaboration.

Governance/templates/MINUTES_TEMPLATE.md

@@ -0,0 +1,59 @@
+# Governance/templates/MINUTES_TEMPLATE.md
+# Meeting Minutes Template
+
+> **Instructions:** Use this template to record official meeting minutes for core maintainer syncs, working group meetings, and governance discussions. Publish the completed minutes within 48 hours of the meeting conclusion.
+
+---
+
+## Meeting Details
+* **Meeting Name / Working Group:** [Insert Group Name or Maintainer Sync]
+* **Date:** [YYYY-MM-DD]
+* **Time:** [HH:MM UTC]
+* **Facilitator:** [Name / Handle]
+* **Scribe:** [Name / Handle]
+* **Meeting Recording / Link:** [URL or "N/A"]
+
+---
+
+## Attendees
+* [Attendee Name / Handle] (Organization / Role)
+* [Attendee Name / Handle] (Organization / Role)
+* **Regrets:** [List absent members who provided notice]
+
+---
+
+## Agenda
+1. [Agenda Item 1: e.g., Milestone Review]
+2. [Agenda Item 2: e.g., RFC-004 Discussion]
+3. [Agenda Item 3: e.g., Open Floor / Q&A]
+
+---
+
+## Discussion Notes
+### 1. [Agenda Item 1]
+* Summary of key points discussed, arguments raised, and technical feedback shared.
+* Note any dissenting opinions or important design trade-offs considered.
+
+### 2. [Agenda Item 2]
+* Summary of key points discussed.
+
+---
+
+## Decisions Made
+> *Record all formal consensus items, policy agreements, or votes taken during the session.*
+* **Decision 1:** [Clear description of what was decided, e.g., "Approved RFC-004 with modifications regarding rate limiting."]
+  * *Voting Outcome / Consensus:* [e.g., Unanimous consensus among 5 present maintainers]
+
+---
+
+## Action Items
+> *List concrete tasks assigned during the meeting, including an owner and target deadline.*
+* [ ] **[Task Description]** — **Owner:** @handle — **Due:** YYYY-MM-DD
+* [ ] **[Task Description]** — **Owner:** @handle — **Due:** YYYY-MM-DD
+
+---
+
+## Publishing Instructions
+1. Save the completed markdown file under `Governance/minutes/YYYY/` (or within the specific Working Group's subdirectory).
+2. Name the file using the format: `YYYY-MM-DD-[topic-or-group-name].md`.
+3. Submit a pull request or push directly to the repository branch according to maintainer contribution guidelines.

Governance/templates/WORKING_GROUP_CHARTER.md

@@ -0,0 +1,38 @@
+# Governance/templates/WORKING_GROUP_CHARTER.md
+# Working Group Charter Template
+
+> **Instructions:** Copy this template when proposing a new Working Group under `Governance/working-groups/`. Fill out all sections completely before submitting for maintainer review.
+
+---
+
+## Working Group Name: [Insert Working Group Name]
+
+### 1. Mission & Scope
+* **Mission:** Provide a clear, one-sentence statement describing the purpose of this Working Group.
+* **Scope:** Detail what falls *within* the scope of this group and, equally importantly, what is *out of scope*.
+
+### 2. Leadership & Initial Members
+* **Group Lead(s) / Chair:** 
+  * Name / Handle: 
+  * Primary Contact: 
+* **Initial Members:**
+  * Member 1 (Name / Affiliation)
+  * Member 2 (Name / Affiliation)
+  * Member 3 (Name / Affiliation)
+
+### 3. Deliverables & Milestones
+* **Phase 1 (0–30 Days):** Setup communication channels, define initial backlog, and establish recurring meeting cadences.
+* **Phase 2 (30–90 Days):** Primary deliverables expected (e.g., draft specifications, code modules, documentation updates).
+* **Ongoing Deliverables:** Regular progress updates, maintenance of assigned domain areas, and community support.
+
+### 4. Meetings & Collaboration
+* **Meeting Frequency:** (e.g., Bi-weekly on Tuesdays at 14:00 UTC)
+* **Collaboration Channels:** (e.g., GitHub issues with label `wg-[name]`, dedicated chat channel)
+* **Meeting Notes Location:** Link to public meeting notes repository or folder.
+
+### 5. Sunset Clause & Dissolution
+* **Active Duration:** This charter is valid for **12 months** from the date of approval, after which it must be reviewed and re-chartered by core maintainers.
+* **Dissolution Conditions:** A Working Group may be dissolved if:
+  1. Its core objectives have been successfully completed and integrated into the main project.
+  2. Inactivity or lack of quorum persists for more than 90 consecutive days.
+  3. The core maintainers vote to sunset the group due to shifting project priorities.