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.
- Annual Strategy (The “Why”):
- Owner: Board of Directors.
- Output: High-level Organizational Objectives (e.g., “Expand into the Enterprise Market”).
- 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
- Submission: Users submit ideas, bugs, and friction points.
- 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.
- 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)
- The Pitch: Voters present the top items from their Wishlist (aligned with Epics).
- The Cost: Contributors provide “T-Shirt Sizing” (Small, Medium, Large) or Story Points to estimate effort.
- 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.
- 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
- Open Development: Contributors build features in public repos.
- Daily Standups: Contributors sync on progress (Voters may observe but not interrupt).
- 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
- RC Generation: Contributors package the code into the Beta Channel.
- Acceptance Vote: The Voters (User Reps) vote on the RC.
- Pass: The RC is promoted to Stable.
- Fail (The “Stop the Line” Protocol):
- Disable: If the failing feature is behind a Feature Flag, it is toggled off immediately. The RC proceeds.
- Revert: If the feature cannot be flagged, the specific code commits are reverted. The RC is rebuilt and re-validated.
- Discard: The RC is only discarded if the instability is systemic and cannot be isolated.
- 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.
- Trigger: A “Severity 1” issue is identified.
- Authorization: The Release Train Engineer (RTE) and Technical Advisors have the authority to bypass the Voter Acceptance cycle.
- Execution:
- Contributors build the fix on a dedicated hotfix branch.
- Technical Advisors perform an expedited code review.
- RTE deploys immediately to the Stable Channel.
- 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
- Board Vote (Governance): Highest authority for Legal/Financial/Brand.
- Joint Ratification (Planning): The consensus agreement on What enters the Sprint (Impact vs. Effort).
- Lazy Consensus (Supply): Highest authority for How we build it (Code/Architecture).
- 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. |
| 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 | Voters | 2–6 Weeks | 5–10 Stories | Stakeholder Demo & UAT | Issue (Label: Feature) |
| L2 | User Story | 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.