Join the research

Contributing

RAHN is an open research project, and the highest-value contributions right now are measurement and critique, not features. CONTRIBUTING.md is the canonical process; this page is the map.

The fit questions first

CONTRIBUTING.md opens with fit questions, because RAHN is deliberately narrow: does the change strengthen verifiable, evolving network state? Features that strengthen that abstraction are in scope; everything else is deferred, and the boundary is a roadmap of post-v1.0 candidates that each require their own ADR. Nothing post-v1.0 is scheduled.

Two paths

1. Architectural change: design-proposal issue → accepted → ADR → spec/ARCHITECTURE update → implementation. Implementation is never first, and accepted ADRs are immutable — they are superseded, never edited.
2. Everything else: pick a curated issue from good first issues. Each carries acceptance criteria, related documents, and a scope that fits in a weekend.

Where help is most valuable now

• Measurement studies: E2 verification-latency benchmark, E3 merge-conflict study, the RQ4 constitution-expressiveness report — each has a methodology document and needs hands (see research).
• Independent review: an adversarial host-safety review of the Linux namespace backend; a deepening of the prior-art survey.
• Engineering: structured fuzzing of the canonical parser; a design RFC for the O(m·n) batch-apply debt; macOS in the CI determinism matrix.
• Documentation: an ADR index and reading guide; SDK doc examples.

Ground rules

• Determinism is non-negotiable: no wall-clock, RNG, or nondeterministic iteration in the core; behavior changes need tests.
• No AI in the core; simulation is the default; real execution stays opt-in and isolated.
• SPDX headers on new files (Apache-2.0 for source, CC-BY-4.0 for documents).
• Security issues go to the private channel in SECURITY.md, never to public issues.

Build, test, and lint commands are in CONTRIBUTING.md. Start here: github.com/MHAlikhani/rahn · Discussions · Issues.