Title here
Summary here
How We Work
This page describes how the OCM team organizes its day-to-day development work. Most meetings listed here are open to the public - anyone is welcome to join, listen, or participate. The Retrospective is invite-only to maintain a safe space for feedback.
How We Structure Work
All work items are GitHub issues tracked on the OCM Backlog Board. Work is organized in a hierarchy:
| Type | Prefix / Label | Scope | Purpose | Template |
|---|---|---|---|---|
| Initiative | Initiative: | Multiple quarters | Communicates vision and progress to stakeholders by aggregating epics | - |
| Epic | EPIC: (epic type) | ~1 quarter | Organizes tasks into a manageable chunk that tracks progress towards an initiative | epic |
| Task | task type | 1 sprint | Documents a small unit of work within an epic so progress is traceable and hand-off is possible | task |
| Spike | spike type | Time-boxed | Explores a question or proof-of-concept within an epic; result is open-ended | spike |
Project Board and Issue Tracking
All work is tracked on the OCM Backlog Board in the ocm-project repository. The board has several views:
| View | Purpose |
|---|---|
| Current Sprint | Active sprint work |
| Next Sprint | Upcoming sprint queue |
| Backlog | All open issues, prioritized |
| Roadmap | Timeline view of planned work |
| Epics | High-level feature tracks |
How Issues Enter the Sprint
Anyone can propose work for an upcoming sprint. The process is:
- Create an issue in the relevant repository (or in ocm-project for cross-cutting work). Write a clear description following the appropriate issue template.
- Self-refine the issue - ensure it has enough context for others to understand scope and intent.
- Add it to the project board with status “Needs Refinement”, assign an initial priority, and place it in the next sprint.
- Refinement discussion - during the weekly refinement meeting the team discusses the issue. If everyone understands it, it is story-pointed and its priority is evaluated.
- Ready for sprint - once refined, the issue moves to the “Next-Up” column and is available for sprint planning.
Meetings
| Meeting | Cadence | Purpose |
|---|---|---|
| Daily Standup | Every workday | Casual sync - not mandatory, not necessarily work-related |
| Planning | Biweekly (Monday) | Review the Next Sprint view, agree on sprint goals |
| Retrospective | Biweekly (Monday) | Reflect on what went well and what to improve (invited members only to maintain a safe space for feedback) |
| Refinement | Weekly (Thursday) | Discuss items in “Needs Refinement” on the Next Sprint view, clarify scope, and story-point |
| Warroom | Every workday | Synchronous coordination on tasks or open topics |
| Community Call | First Wednesday of the month | Project updates, demos, and open Q&A with the broader community |
| TSC Meeting | First Monday of the month | Governance decisions, SIG approvals ( meeting notes) |
Decision-Making
Day-to-day technical decisions are made by the contributors doing the work, in pull requests and issues. For decisions that affect multiple areas or establish a precedent, the team uses Architecture Decision Records (ADRs).
Larger decisions that affect project direction are escalated to the TSC. The process is:
- Discuss in a GitHub issue, SIG meeting, or on Slack/ Zulip
- If consensus is not reached, bring it to the TSC agenda
- The TSC decides by majority vote (quorum: 50% of voting members)
For full governance details, see the Governance page and the Project Charter.
Communication Channels
For communication channels and how to reach the team, see the Community Engagement page.