10. Contributing

Help is welcome, and the project is deliberately structured so that contributions are easy to review and hard to make unsafe.

Good first contributions #

• A new chaos scenario in chaos/scenarios/ plus its eval entry. Small, self-contained, and directly useful.
• A policy in deploy/policies/ with test cases in deploy/policies/tests/, following the kyverno/policies conventions.
• Docs: clarify a page, add a client example, improve the deployment guide.
• Run the eval harness against a model and contribute the results.

Ground rules #

• The small tool surface is a feature. A new MCP tool needs a written rationale: why it is safe to expose and which guardrail layers cover it. "It would be convenient" is not enough.
• Every write-path change needs tests for the guardrail and approval behavior it touches.
• Policies follow the kyverno/policies conventions: descriptive names, policies.kyverno.io/* annotations, one concern per policy, test cases included.

Local workflow #

make install       # editable install with dev + tracing extras
make test          # unit tests, no cluster
make lint          # ruff
make policy-test   # offline Kyverno CLI tests
make bootstrap     # full local fleet, for end-to-end work

Commit and PR conventions #

• Conventional-style subjects: feat:, fix:, docs:, test:, chore:.
• Sign off every commit (git commit -s, DCO). No other trailers.
• One logical change per commit; keep diffs reviewable.
• The PR template includes a checklist; new tools must include the safety rationale.

Full detail: CONTRIBUTING.md and the Code of Conduct.

Security and sponsorship #

• Security issues go through private advisories, never public issues. See SECURITY.md.
• For commercial support, a hardened deployment review, sponsored features, or talks and workshops, connect on LinkedIn (SUPPORT.md).

Next: FAQ.

Source: wiki/Contributing.md — this page is generated from it, so edit the markdown, not the site.