ota is maintainer-led and does not currently accept external code contributions.
That is a governance choice, not a signal that outside feedback is unwanted. The most useful external input right now is issue-quality feedback that helps harden the public contract and the trust-sensitive command surfaces.
- bug reports with a concrete reproduction
- feature requests tied to a real repo or operator workflow
- docs feedback where wording, examples, or guidance are unclear
- fixture ideas or example repos that expose important edge cases
For suspected vulnerabilities, do not open a public issue. Use SECURITY.md.
Use the GitHub issue templates when possible so the report is actionable.
- external code pull requests
- speculative refactors without a concrete operator problem
- product-positioning changes that are not grounded in the shipped contract and docs
Ota treats the contract, diagnosis model, JSON output, and readiness semantics as trust-critical product surfaces. The project is currently kept under strict maintainer stewardship so those surfaces can evolve coherently while the public contract hardens.
External code pull requests remain closed during this stabilization period. Any future opening will begin with bounded contribution lanes backed by explicit contribution terms, provenance, ownership, and review controls; roadmap and trust-sensitive product decisions will remain maintainer-led.
- open a bug with a failing repo shape
- file docs corrections or examples that are misleading
- propose a feature with exact operator value and trade-offs
- point out contract drift, output ambiguity, or trust leaks