Community

Contributing to Dits

Help make the local engine, durable format, compatibility evidence, and public product story trustworthy.

Start with the current boundary

Read the status and roadmap before choosing work. The hosted backend is historical; network and P2P are not current implementation surfaces.

High-value contributions

Crash-safety, corruption, and recovery regression tests.
Generated or redistributable real-media fixtures.
Deterministic format vectors and compatibility tests.
Bounded-memory ingest and high-object-count storage work.
Fair, reproducible workload comparisons.
CLI and documentation corrections tied to actual behavior.

Before a pull request

cargo +nightly fmt --all -- --check
cargo test --locked --workspace
npm --workspace apps/web run lint
npm --workspace apps/web run test:ci
npm --workspace apps/web run build
bash scripts/check-cli-docs.sh
bash scripts/check-product-truth.sh
git diff --check

Persistent-format, protocol, or broad product changes should begin with an issue and, when appropriate, an architecture decision. Explain compatibility impact, fixtures, failure behavior, documentation changes, and verification limitations in the pull request.

The complete guide is maintained in docs/development/contributing.md.