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
Joining meetings
All public meetings are listed on the OCM community calendar on LFX. Open the page for join links, or subscribe to the feed in your own calendar app and every change shows up automatically.
| 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.