Consolidated issues for all OCL repositories.
We use Projects to organize the community's roadmap into tickets, and all tickets are stored in this repo (see the Issues tab).
If you would like to report an issue, please first verify that it does not exist yet by searching from the Issues tab. If you are sure it is a new issue, click here to report it. An OCL community member will get back to you as soon as possible and may ask for more details, if needed.
NOTE: The OCL community previously used ZenHub Browser Extension in combination with GitHub tickets, but that is now deprecated.
- Actionable Only: A ticket should only exist if there is an immediate intent to work on it.
- The "Dreaming" Boundary: If a task doesn't have a clear path to execution in the near term, it is documentation, not an issue.
- Content is King: Tickets that are just titles with no descriptions or comments provide no value and should be closed.
- Preserving Knowledge: Institutional knowledge is valuable, but it shouldn't "gunk up" the active backlog.
- Markdown-Based Repos: Future ideas and complex "institutional memory" belong in a dedicated documentation repository (using Markdown) rather than open GitHub issues.
- Public-facing documentation can live in this repo until ready for action: OCL Knowledge Base repository
- Private documentation can reside in a dedicated repo until ready for action.
- Precursor to Projects: Documentation serves as the "parking lot" or precursor where ideas are fleshed out before becoming actionable tickets.
- Primary Structure: GitHub Projects should be the primary organizational tool, rather than relying solely on labels or a massive, flat backlog.
- Discrete Buckets: Work is organized into specific, funded efforts (like the CL project) or evolving functional areas (like TBV3).
To ensure the board is scannable and actionable at a glance, while keeping our best ideas safe in a searchable "library" elsewhere.