Léo
0276e15f6e
The handbook says substantial features need Product Owner approval before implementation, but not how a proposal gets there, what counts as substantial, or what happens when no answer comes. Add the full workflow: triage within 7 days, a decision brief, four product labels, a lazy-consensus timeout that only applies to big-but-reversible work, and definitions for every judgement call (small, big, reversible, new direction, fits ROADMAP, objection, recorded decision). The Feature Request form gets three optional fields for the brief, and the PR template, CONTRIBUTING and triage point at the workflow.
Odysseus maintainer handbook
Odysseus maintainers are trusted to act, not to wait for permission. The default is individual responsibility; additional review is required when the risk warrants it.
This handbook records the project's maintainer governance and gives reviewers a reusable process. It complements CONTRIBUTING.md and SECURITY.md; it does not replace the PR template, repository protections, or product decisions.
At a glance
| Area | Working rule |
|---|---|
| Product direction | Pewds is the Product Owner |
| New feature | Feature Request issue; big, new-direction or hard-to-undo features need a recorded Product Owner decision (workflow) |
| Ordinary, reversible maintainer PR | Self-merge allowed after appropriate validation and applicable repository checks |
| External contribution | Maintainer review required |
| High-risk change | At least one independent, qualified maintainer review |
| Access | Need-to-have, least privilege, separately granted per system |
| Release | A designated Release Maintainer owns preparation and publish |
| Inactivity | Access review after 2 months without activity, notice, or response |
| Documentation | Repository Markdown is canonical |
These are governance rules, not guarantees that a GitHub permission or branch-protection setting permits a particular action. Respect the stronger applicable automated gate.
Start here
- Roles and access: responsibility, permissions, and continuity.
- Product and feature proposals: product approval versus technical ownership, and the feature proposal workflow.
- Changes and review: review thresholds, self-merge, contributor corrections.
- Practical review playbook: risk, provenance, CI, CodeQL, independent audit, and handoff evidence.
- Triage: turning incoming reports into actionable work.
- Testing and releases: evidence, platform validation, promotion to main.
- Documentation: canonical sources, updates, and traceability.
Accountability
Maintainers own the changes they take on, including validation, regression prevention, follow-up, and rollback when needed. Roles describe responsibilities, not a hierarchy of technical approval.
Important product-direction decisions go through the Product Owner. Maintainers retain responsibility for feasibility, implementation, maintainability, and security.
AI coding or review agents can help collect evidence, test hypotheses, and prepare changes, but they are not the qualified human reviewer required for high-risk changes. A maintainer must inspect and accept the evidence.