# 🕉️ OpenPecha Community Playbook

**URL:** <https://forum.webuddhist.com/t/openpecha-community-playbook/503>\
**Category:** 🤝 Governance\
**Created:** [December 25, 2025, 7:24am UTC](https://forum.webuddhist.com/t/openpecha-community-playbook/503 "2025-12-25T07:24:52Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![openpecha](https://yyz1.discourse-cdn.com/flex003/user_avatar/forum.webuddhist.com/openpecha/32/78_2.png) [@openpecha](https://forum.webuddhist.com/u/openpecha)\
**Post date:** [December 25, 2025, 7:24am UTC](https://forum.webuddhist.com/t/openpecha-community-playbook/503/1 "2025-12-25T07:24:53Z")

</div>

# **The OpenPecha Playbook**

This Playbook establishes the operational framework for OpenPecha’s engineering and product ecosystem. It defines a **Federated Hybrid Model** that maintains a strict separation between Organizational Governance (Board) and Product Operations (Working Groups). By bridging the **User Community (Demand)** with the **Contributor Community (Supply)** through representative democracy and disciplined **Agile Release Trains** , we ensure that every line of code serves a validated user need on a predictable bi-weekly cadence.

## **1. The Core Philosophy**

- **Separation of Concerns:** We maintain a strict firewall between **Organizational Governance** (Board) and **Product Operations** (Working Groups).
- **Distinct Communities:** We recognize two distinct groups: **Users** (who define the problems) and **Contributors** (who engineer solutions).
- **Strategic Alignment:** We use **OKRs (Objectives and Key Results)** to align daily work with long-term goals, breaking big **Epics** down into actionable Sprints.
- **Representative Governance:** We utilize **Working Groups (WGs)** to bridge the gap between User needs and Contributor capacity.

## **2. Roles & Responsibilities**

### **OpenPecha Board of Directors (The Governance Authority)**

The Board handles the “Administration of the Foundation” and does not intervene in product features unless they violate legal/brand constraints.

- **Composition:** Members elected by the entire OpenPecha community to fiduciary roles.
- **Responsibilities:**
  - **Corporate Strategy:** Defining the high-level mission, Annual Objectives, and budget.
  - **Strategic Partnerships:** Establishing formal alliances with institutions.
  - **Fundraising & Sustainability:** Securing grants and sponsorships.
  - **Brand & Legal Compliance:** Managing trademarks and liability.
  - **Organizational Arbitration:** Resolving disputes between WGs regarding resources or brand.

### **The Ecosystem Layers**

We explicitly distinguish between the people who _use_ the software and the people who _build_ it.

#### **A. The User Community (The Demand Side)**

- **Who they are:** The broad base of consumers, from daily users to enterprise deployers.
- **Primary Interaction:** submitting ideas via **Community Hubs** and voting on high-level roadmaps.
- **Goal:** To solve their business/personal problems effectively.

#### **B. The Contributor Community (The Supply Side)**

- **Who they are:** Developers, designers, and writers (both internal staff and external volunteers).
- **Primary Interaction:** submitting code/PRs via **Repositories**.
- **Goal:** To build high-quality, maintainable, and innovative software.

### **The Working Group (The Bridge)**

Each product is governed by a dedicated **Working Group (WG)** that negotiates the exchange between the Users (Demand) and Contributors (Supply).

- **Voters (5, 7, or 9 Seats) – representing the Users:**
  - **Role:** The operational board. They are the **Voice of the Customer**.
  - **Selection:** Appointed or elected to represent specific User Segments (e.g., Enterprise, Newcomers).
  - **Responsibilities:** Defining Quarterly Epics, prioritizing the Roadmap based on Userback data, and ratifying Release Candidates.

- **Contributors (The Builders) – representing the Contributor Community:**
  - **Role:** The technical workforce. They are the **Voice of the Code**.
  - **Responsibilities:** Estimating feasibility, writing code, and maintaining technical health.
  - _Constraint:_ They have “Write Access” but must build what the Voters prioritize.

- **Non-Voting Advisors (Appointed):**
  - **Role:** SMEs (Security, Legal, UX) who advise the Voters on feasibility.

### **Community Operations (CommOps) Team (Shared Service)**

- **Role:** The operational backbone supporting both communities.
- **Key Roles:**
  - **Community Growth Manager:** Focuses on the **User Community** (Events, Moderation, **Communications** , **Partnerships** ).
  - **Process and Automation Specialist:** Focuses on the **Contributor Community** (DevRel, Onboarding) and tracking **OKRs** (e.g., Active Users, Retention).
  - **Storyteller:** Focuses on **Narrative & Multimedia**. Produces short videos, podcasts, and spotlights to feature Contributor work and explain new Releases to the broader public.
  - **Release Train Engineer (RTE):** Focuses on **Process** and Schedule.

- **Responsibilities:**
  - **Facilitation:** Running syncs and elections.
  - **Communications:** Publishing Release Notes, Roadmaps, and Town Hall summaries.
  - **Partnerships:** Executing alliance programs, managing relationships with institutions, and coordinating joint events.
  - **Promotion:** Creating content that humanizes the code (Contributor Spotlights) and visualizes value (Feature Demos).
  - **Gatekeeping:** Ensuring Contributors work on Voter-approved items.
  - **Process Alignment:** Facilitating the “Cross-Product Release Sync” to manage cross-product dependencies.

## **3. The Workflow Lifecycle**

### **Phase 0: Strategic Planning (The Long View)**

Before individual items hit the roadmap, we set the destination using **OKRs** , **Epics** , and **Milestones**.

1. **Annual Strategy (The “Why”):**
  - **Owner:** Board of Directors.
  - **Output:** High-level Organizational **Objectives** (e.g., “Expand into the Enterprise Market”).

2. **Quarterly Planning (The “What” & “When”):**
  - **Owner:** WG Voters + Advisors.
  - **Output:**
    - **Key Results (KRs):** Specific metrics to hit (e.g., “Grow Active Users to 10k,” “Reduce Churn by 5%”).
    - **Milestones:** Critical temporal anchors for the Roadmap.
      - **Metric Milestones:** Hitting a specific KR target.
      - **Event Milestones:** Fixed dates for Community Events (e.g., “Annual Conference”, “Hackathon”) that act as deadlines for specific features.

    - **Epics:** Large thematic initiatives designed to achieve the KRs and hit the Milestones.
      - _Constraint:_ Must be fully deliverable within the **Quarter**.
      - _Structure:_ Broken down into multiple smaller **User Stories** which populate the Sprint Backlogs.

### **Phase 1: Discovery (The Intake)**

Tools: Community Hubs (Userback)  
Source: The User Community

1. **Submission:** Users submit ideas, bugs, and friction points.
2. **Refinement:** The **Voters** act as the intake filter, supported by CommOps facilitation.
  - Voters **deduplicate** similar requests to keep the backlog clean.
  - Voters convert raw feedback into structured **User Stories** (e.g., “As a user, I want X so that Y”) to ensure actionable clarity for prioritization.

3. **WG Prioritization (The 80/20 Analysis):**
  - The **Voters** review the clean feedback queue asynchronously.
  - They apply the **Pareto Principle (80/20 Rule)** to create a prioritized “Wishlist.”
  - **Strategic Filter:** Items that contribute to the current **Quarterly Epics/OKRs** are prioritized higher.

### **Phase 2: Commitment (The Handshake)**

Ceremony: Sprint Planning Meeting  
Attendees: Voters + Advisors (Demand/Impact) AND Contributors (Supply/Effort)

1. **The Pitch:** Voters present the top items from their Wishlist (aligned with Epics).
2. **The Cost:** Contributors provide “T-Shirt Sizing” (Small, Medium, Large) or Story Points to estimate effort.
3. **The Negotiation:**
  - If a high-impact item is too “expensive,” Advisors suggest scope cuts.
  - If Contributors flag critical technical debt, Voters agree to swap a feature for a fix.

4. **The Ratification:**
  - The final list of tasks is agreed upon.
  - **Result:** A committed Sprint Backlog that serves as the binding mandate for the next 2 weeks.

### **Phase 3: Development (The Build)**

Cadence: 2-Week Sprints  
Source: The Contributor Community

1. **Open Development:** Contributors build features in public repos.
2. **Daily Standups:** Contributors sync on progress (Voters may observe but not interrupt).
3. **Contributor Sync:** Weekly sync where Contributors discuss deep technical blockers with Advisors.

### **Phase 4: Delivery (The Release)**

Owner: Release Train Engineer (CommOps)  
Cadence: Bi-weekly (Aligned with Sprint End)

#### **Release Channels**

To balance rapid innovation with stability, we utilize a tiered release structure:

- **Nightly (The “Dev” Channel):**
  - _Content:_ Automatically built from the main branch every night.
  - _Audience:_ Contributors and “Bleeding Edge” Users.
  - _Purpose:_ Immediate feedback on yesterday’s code. “Use at your own risk.”

- **Release Candidate / RC (The “Beta” Channel):**
  - _Content:_ A frozen snapshot taken at the end of the Sprint.
  - _Audience:_ The **Voters** (for ratification) and intrepid users.
  - _Purpose:_ The subject of the **Acceptance Vote**.

- **Stable (The “Prod” Channel):**
  - _Content:_ The RC build _after_ it passes the Voter Acceptance Vote.
  - _Audience:_ General User Community and Enterprise deployments.
  - _Purpose:_ Production-ready workloads.

#### **The Process**

1. **RC Generation:** Contributors package the code into the Beta Channel.
2. **Acceptance Vote:** The **Voters** (User Reps) vote on the RC.
  - _Pass:_ The RC is promoted to **Stable**.
  - _Fail (The “Stop the Line” Protocol):_
    1. **Disable:** If the failing feature is behind a **Feature Flag** , it is toggled off immediately. The RC proceeds.
    2. **Revert:** If the feature cannot be flagged, the specific code commits are reverted. The RC is rebuilt and re-validated.
    3. **Discard:** The RC is only discarded if the instability is systemic and cannot be isolated.

3. **Deployment & Communication:**
  - **Deployment:** The **RTE** deploys the ratified build to the Stable Channel.
  - **Announcement:**  **CommOps** publishes the Release Notes to Community Hubs and notifies users.

#### **The Emergency Hotfix Protocol**

In the event of a Critical Security Vulnerability (CVE) or a System-Down Bug in Production, the bi-weekly schedule is suspended.

1. **Trigger:** A “Severity 1” issue is identified.
2. **Authorization:** The **Release Train Engineer (RTE)** and **Technical Advisors** have the authority to bypass the Voter Acceptance cycle.
3. **Execution:**
  - Contributors build the fix on a dedicated hotfix branch.
  - Technical Advisors perform an expedited code review.
  - RTE deploys immediately to the Stable Channel.

4. **Accountability:** A “Hotfix Incident Report” must be presented to the Voters at the next Town Hall to explain why the bypass was necessary.

#### **Versioning Convention**

To ensure clear communication of freshness and scope, all **Software and Dataset releases** utilize the `YY.Major.Sprint-Channel` format:

- **YY:** Two-digit Year (e.g., 26 for 2026).
- **Major:** Strategic version identifier (incremented only upon completion of significant Epics or breaking changes).
- **Sprint:** The sequential Sprint number within the current cycle.
- **Channel:** Suffix indicating the stability tier (defined in Release Channels).
  - **Stable:** No suffix (e.g., 26.3.14).
  - **Release Candidate:** -rc (e.g., 26.3.14-rc).
  - **Nightly:** -dev (e.g., 26.3.14-dev).

- _Example:_ 26.3.14 (Year 2026, Major Version 3, Sprint 14, Stable Release).

## **4. The Operating Rhythm**

To ensure alignment between high-level strategy and daily execution, we operate on two distinct timelines.

### **4.1 The Strategic Calendar (Long Wave)**

| Frequency | Time | Event | Scope | Facilitator | Attendees | Purpose |
| --- | --- | --- | --- | --- | --- | --- |
| **Annually** | 2 days | **North Star Retreat** | **Global (Org)** | Board Chair | Board, WG Leads | Set **North Star** Annual Objectives and vision. |
| **Quarterly** | 2:00 | **OKR & Epic Review** | **Product WG** | RTE/Leads | Core Team | Grade past OKRs, analyze Epic impact, and capture learnings. |
| **Quarterly** | 4:00 | **Drafting Workshop** | **Per Product WG** | | Core Team | Draft new OKRs, define new Epics, and map dependencies. |
| **Quarterly** | 1:00 | **OKR and Epic Setting** | **Per Product WG** | RTE | Voters, Advisors | Finalize OKRs, publish roadmap, and build community buy-in. |
| **Quarterly** | 1:00 | **Board Meeting** | **Global (Org)** | Board Chair | **Directors** | Governance, Budget, Fundraising. |
| **Monthly** | 1:30 | **Strategy & Roadmap Review** | **Per Product WG** | Leads | Leads | Review active Epics. Kill or pivot those not moving KR metrics. |

### **4.2 The Bi-Weekly Sprint Calendar (Execution Wave)**

**The “Release Train” runs on a strict 14-day cycle.**

| **Day** | Time | **Event** | **Owner** | Purpose |
| --- | --- | --- | --- | --- |
| **W2-Thu** | | **RC Deployment** | | Code Freeze. Packaging the Release Candidate for voting. |
| **W2-Fri** | | **Stable Deployment** | | Deploying the ratified RC and publishing Release Notes. |
| **Daily** | 12pm | **Nightly Build Deployment** | | CI/CD pushes code to the Dev Channel (Automatic). |

**Sprint Cadence**

| Day | Time | Event | Facilitator | Attendees | Purpose |
| --- | --- | --- | --- | --- | --- |
| **W0** | 4:00 | **Community Hubs Review** | CommOps | Voters | **Discovery:** Finalize the “Wishlist” to be ready for next Sprint Planning. |
| **W1-Mon** | 4:00 | **Sprint Planning** | RTE | 1+ Voter, All Contributors | **First 30m:** OKR Confidence Pulse. **Next 3.5h:** Story commitment. |
| **W1-Fri** | 0:30 | **Contributor Sync** | CommOps | Contributors | Technical unblocking & alignment. |
| **W2-Wed** | 1:00 | **Cross-Product Sync** | CommOps | Leads | Managing Epic dependencies that cross WG boundaries. |
| **W2-Thu** | 1:00 | **Mock Demo** | CommOps | Contributors | Pre-release technical checks. |
| **W2-Fri** | 1:00 | **Demo & Vote** | RTE | All | Proving that the Sprint’s output contributes to the Quarterly Objective. |
| **W2-Fri** | 1:00 | **Sprint Retro** | RTE | Contributors | Reviewing team health and “Outcome vs. Output” ratio. |
| | | | | | |
| **Daily** | 0:15 | **Daily Standup** | | Contributors | Tactical sync; flag blockers affecting specific Epics. |

## **5. Decision Making Matrix**

1. **Board Vote (Governance):** Highest authority for Legal/Financial/Brand.
2. **Joint Ratification (Planning):** The consensus agreement on _What_ enters the Sprint (Impact vs. Effort).
3. **Lazy Consensus (Supply):** Highest authority for _How_ we build it (Code/Architecture).
4. **RTE Mediation:** Mediation for cross-product conflicts.

## **6. Tools & Channels**

To ensure transparency and efficient collaboration, we utilize a standardized stack of tools across all Working Groups.

| Platform | Primary Audience | Scope | Usage |
| --- | --- | --- | --- |
| **Community Hubs (Userback)** | **Users** | Per Product | **Intake & Direction.** Collecting ideas/bugs and hosting the user-guided Roadmap. |
| **GitHub Projects** | **Contributors** | Per Product | **Execution.** Managing the Backlog, Epics, User Stories, and Sprint Boards. |
| **Discourse** | **All** | Global | **Documentation & Governance.** Hosts WG Charters, Rosters, Meeting Minutes, PRDs, Calendars, and the index of communication channels. |
| **Discord** | **Contributors** | Per Product | **Engineering Comms.** Real-time chat for daily standups, technical discussions, and troubleshooting. |
| **WhatsApp** | **Users** | Per Product | **User Comms.** Informal town square for end-users to network and support each other. |
| **Excalidraw** | **All** | Ad-Hoc | **Visual Collaboration.** Creating flowcharts, architecture diagrams, and low-fidelity mocks. |
| **Canva** | **Storyteller** | Global | **Visual Storytelling.** Creating promotional graphics, video thumbnails, and social media assets to feature contributors and releases. |

\_\_\_\_\_\_\_\_\_\_ TO INTEGRATE IN THE PLAYBOOK \_\_\_\_\_\_\_\_\_\_\_\_

# 🚀 Working Group (WG) Delivery Workflow

## 1. Governance Roles

- **Voters:** Strategic leads who manage the product roadmap. They translate user feedback (Userback) into actionable User Stories and Features.
- **Contributors:** Technical leads and developers. They assess effort, define implementation, and execute the work.

## 2. Work Hierarchy & Benchmarks

We use a 4-tier hierarchy in GitHub to maintain clarity. We optimize for deep work, allowing technical tasks to span up to two days.

| Level | Artifact | Owner | Ideal Duration | Content | Review & Test Strategy | GitHub Mapping |
| --- | --- | --- | --- | --- | --- | --- |
| **L0** | Product / Quarter | Voters | 3 Months | 4–6 Features | OKR & Metric Assessment | GitHub Project |
| **L1** | Feature/Epic (GH-board) | Voters | 2–6 Weeks | 5–10 Stories | Stakeholder Demo & UAT | Issue (Label: Feature/Epic) |
| **L2** | User Story (Hub-\>board) | Voters | 1–3 Days | 2–3 Tasks | QA & Voter Approval | Sub-issue (in Feature) |
| **L3** | Tech Task | Contributors | 1–2 Days | 3–6 Items | Peer Review & Unit Tests | Sub-issue (in Story) |
| **L4** | Checklist Item | Contributors | \< 2 Hours | N/A | Dev Self-check | Markdown Item |

## 3. The Lifecycle

### Phase A: Discovery (Continuous)

- **Feedback:** Voters monitor Userback cards and user roadmaps.
- **Synthesis:** Voters group feedback into Features (L1) and draft the underlying User Stories (L2) describing the “Who, What, and Why.”

### Phase B: Sprint Planning (Day 1 of Sprint)

- **Effort Assessment:** Voters present the Stories. Contributors assess the complexity and finalize the Technical Tasks (L3) together.
- **Task Sizing:** Because tasks are 1–2 days, we aim for 2–3 tasks per story to ensure the story remains deliverable within the sprint.

### Phase C: Execution & Quality (Daily)

- **Development:** Contributors work on Tasks (L3). A task is not “Done” until the Pull Request (PR) is merged.
- **Quality Gates:**
  - **L3 Review:** Every Task requires a Peer Code Review and passing CI/CD Unit Tests.
  - **L2 Review:** Once all Tasks are closed, the Voter verifies the Story in a staging environment.

- **Feature Completion:** Once the progress bar reaches 100%, the Feature is demoed and released.

## 4. GitHub Implementation Guide

**Sub-issue Nesting:**

- **Parent:** Feature Issue.
- **Child:** User Story Issue.
- **Grandchild:** Technical Task Issue (where the actual code lives).

**Tracking & Milestones:**

- **Progress Tracking:** Use the Sub-issue progress bar on the Feature and Story issues to monitor the completion of 1–2 day tasks.
- **Milestones:** All active User Stories and Tasks must be assigned to the current 2-week Sprint Milestone.

## 5. Definition of Done (DoD)

An item is only considered Done when:

- **Peer Review:** Code approved by at least one other Contributor.
- **Automated Testing:** Unit/Integration tests passed via GitHub Actions.
- **Documentation:** Technical docs or README updated.
- **Voter Sign-off:** A Voter has confirmed the Story meets user requirements.