Contributing to Ajar
> Org path convention: this file applies org-wide (lives in the .github repo). References like docs/03-PROTOCOL-SPEC.md, GLOSSARY.md,...
Org path convention: this file applies org-wide (lives in the
.githubrepo). References likedocs/03-PROTOCOL-SPEC.md,GLOSSARY.md,DECISIONS.md,schemas/,examples/resolve inside theajarspec repo;CONVERSION-PIPELINE.mdlives inajar-gateway;ROADMAP.mdandtasks/live inplanning; conformance vectors currently seed inajar/test-vectorsand graduate toconformanceas the executable harness lands.
Thank you for helping build the owner-sovereign agentic web.
Before you start
- New here? Follow
ONBOARDING.mdend to end. - Read
README.md, then the doc relevant to your area (docs/), thenGLOSSARY.md. - If you are an AI coding agent (or directing one),
AGENTS.mdis binding. - Check
DECISIONS.md— if your idea contradicts an accepted ADR, open a discussion to revisit the ADR first; don't code against it.
How work is organized
- All work maps to task IDs in
/tasks/phase-N-*.md(e.g.,T1.6). Issues are seeded in the owning repo and aggregated on the org Project board, Ajar Roadmap. One task = one PR. - New ideas: open an issue proposing a task (context, deliverable, Definition of Done, which docs it touches). Maintainers slot it into a phase.
- Spec changes: separate PRs labeled
spec-change, must update schemas, examples, conformance vectors, and (if needed) an ADR — together.
Ground rules
- Definition of Done is binding; demonstrate it in the PR.
- Tests ship with the change (unit / conformance / adversarial as applicable; see
TESTING.md). Never weaken a conformance or adversarial test to pass CI. - Docs move with code in the same PR (spec, GLOSSARY, DECISIONS as applicable).
- Fail closed; registry error codes at protocol boundaries; no telemetry in owner-deployed software (ADR-014).
- Licenses: docs CC-BY-4.0, code Apache-2.0 (ADR-011). Check license compatibility before porting any snippet. DCO sign-off required (
git commit -s).
Security issues
Do not open public issues for vulnerabilities. Follow SECURITY.md (private disclosure). Adversarial test contributions are very welcome via normal PRs after the underlying issue is fixed or when they encode already-documented threats.
Communication
- Issues: bugs, task proposals, spec ambiguities (cite the spec section).
- Discussions: design debates, ADR revisit proposals, ecosystem/interop topics.
- Be specific, cite documents by section, use GLOSSARY terms exactly.
Recognition & governance
External contributors who sustain quality work gain review rights per phase-5 governance workstream (T5.7). The goal is explicitly for this project to outgrow its founders.