Skip to content

Contributing

Start with Adding an Algorithm — it is the lifecycle spine, and it says what order the phases go in, who owns the how for each, and which gate proves each one. Everything in contributing/ is a page it links to.

This list is a catalogue, not a reading order: it says what each page is, so you can find the one that owns your question.

The contributing guide

  • Adding an Algorithm — the lifecycle spine: the order of the phases, who owns each, and the four places evidence lives
  • Repository Map — a whole-repository view, and why an algorithm is implemented once, in C
  • Module Layout — where C headers, sources, and tests go
  • Adding a Module — step-by-step guide using jm
  • Error Convention — how errors are returned across the C ABI
  • DSSS Acquisition Use Cases — the two wide-Doppler operating regimes driving the acquisition design
  • Benchmarking — running and interpreting benchmark results
  • Measuring a Receiver — the path from a receiver to a number you can defend: the adapter, the four metrics together, how to read a refusal, and what to gate on
  • Object Validation — how an object is certified: header claims → C tests proven by sabotage → the generated evidence report and its two gates
  • Validation Log — which objects are certified, their limit and finding counts, and a link straight to each object's evidence
  • Doc Examples — every docs code snippet is discovered and tested, no opt-in list
  • Docstring Authoring — write the C header Doxygen so jm derives top-notch Python docstrings on both faces
  • Docs Conventions — what's generated vs. hand-owned under docs/, and the nav-index/Related-pages CI gates

Maintainer internals

Release-owner plumbing — a library user or drive-by contributor never needs these:

  • Open Issues — the whole backlog, tiered by the kind of harm each issue does rather than by age or label; generated from issue-tiers.toml by make issues
  • Continuous Integration — the pinned toolchain image and how to run CI's environment yourself (make ci-gates), the compiler cache, and the gates that watch CI itself
  • Release — versioning, tagging, and publishing
  • Build Internals — how the build/release pipeline turns source into a published wheel and C library tarball
  • Coverage — clang source-based coverage across the C/Python/Rust harnesses

Historical records

Kept for provenance in docs/dev/archive/ (out of the site nav; each carries a status banner):