Community and Support

Community & Support

Everything about interacting with the project and its maintainer, in one place. The authoritative versions live in the repo; this page is the map.

Where do I ask?

I want to…	Go here
Ask "how do I…?"	Q&A discussions
Report a bug	Bug report
Request a feature or integration	Feature request
Propose a design change	RFC
Show what you built	Show and tell
Report a vulnerability	Security advisory — privately, never a public issue
Ask about commercial licensing	mohsen.seyedkazemi@gmail.com

Full detail, including exactly what to paste into a bug report: SUPPORT.md.

What to expect

This is a single-maintainer, volunteer project. Best effort, no SLA. Issues are usually triaged within a week, and a quiet issue is a backlog rather than a rejection. Reports that come with a reproduction get looked at first, because they can be.

Bug reports against v1/–v3/ are closed as won't-fix by design — those generations are frozen so the published paper stays reproducible. Only v4/ is supported.

How issues are handled

Every issue starts as needs-triage, gets exactly one area/* label, and picks up priority/* once someone has read it. What each label means, what it promises, how to claim an issue, the two-week unassignment rule, and what each close reason means are all written down in TRIAGE.md.

You don't need commit access to triage. Reproducing someone else's bug and saying what happened is one of the highest-leverage things anyone can do here, and it's credited in release notes exactly like code.

Ways to contribute that aren't code

All of these count, and all are credited by name:

• Say you're using it → #51 or a one-row PR to ADOPTERS.md. The list is honestly empty right now; you'd be the first.
• Vote on the roadmap → 👍 the issues linked from #52. A one-line comment saying why you need something outweighs ten reactions, because it says what "done" has to mean.
• Answer a question in Q&A.
• Triage an issue labelled needs-triage.
• Test on a platform the maintainer doesn't have — an ARM Mac, an air-gapped cluster, OpenShift, k3s on a Pi.
• Add a playbook or a detector — one YAML file each.
• Improve the docs. If you got stuck, that is a documentation defect, not a you problem.

Writing code

Start at CONTRIBUTING.md, which includes a worked end-to-end first-PR walkthrough against a real open issue.

Three things that surprise people:

1. You don't need a cluster. Almost everything is mocked; uv sync then pytest works on a laptop with no Docker, no Kubernetes, and no LLM key.
2. mypy and ruff format are known debt and are not CI gates. You are not expected to fix pre-existing errors — just don't add new ones.
3. AI assistance is welcome, and asked to be disclosed. The bar is that you understand the change and can defend it in review — identical to hand-written code. The one hard rule: never let a generated change weaken the HITL approval gate, the RBAC checks, or the mutating chokepoint.

Commits need a DCO sign-off (git commit -s).

Governance

One maintainer today, with an explicit contributor ladder in GOVERNANCE.md. That ladder is a real invitation: the single most valuable contribution anyone can make to this project is becoming its second maintainer.

All interaction is governed by the Code of Conduct.