Contributing

Contributions are welcome. The GitHub repo is github.com/NotAutopilot/openpilot.

Branches

Branch	Purpose
nap-release	Production. What installer.comma.ai/NotAutopilot/nap-release serves to daily drivers.
nap-alpha	Tester builds. Mirrors nap-dev when stable enough to run on real cars.
nap-dev	Active development. Send pull requests here.

PRs target nap-dev. Changes flow from nap-dev → nap-alpha → nap-release as they stabilize.

There is also a naponsp-dev branch for sunnypilot-specific work. Code that is sunnypilot-specific (MADS, CP_SP, etc.) belongs there only — do not land it in nap-dev.

Opening a PR

For anything non-trivial, open an issue first and describe what you want to change and why. This avoids duplicated effort and catches design disagreements before you have written a lot of code.

PRs that touch safety-critical code — anything in opendbc_repo/opendbc/safety/ — must include test coverage. The test file is at opendbc_repo/opendbc/safety/tests/test_tesla_preap.py. Run it with:

source .venv/bin/activate
python -m pytest opendbc_repo/opendbc/safety/tests/test_tesla_preap.py -v

If your change modifies safety behavior and no test exists for it yet, write one. Safety changes without tests will not be merged.

Pre-push checklist

Before pushing to any nap-* branch:

1. Local scons build passes
2. Pre-AP safety tests are green
3. If you touched anything in safety/, run the Docker CI build too
4. If you bumped the opendbc_repo submodule pointer, confirm the submodule commit is pushed upstream first

Building locally

The full contributor docs live in docs-nap/ in the repo. That covers the local macOS build, the Docker CI build, submodule setup, and the release notes format. Read those docs before sending your first PR.

Contributing to this wiki

The wiki source is at github.com/NotAutopilot/nap-wiki . Pages are markdown files in content/ following the frontmatter format at the top of each file.

A few things to keep in mind for wiki contributions:

• Write for an owner audience — someone who has already opened the frunk and understands what CAN is, but may not read Python
• Sentence case headings, no filler intros, no marketing language
• Cross-link to related pages using absolute paths from the content root (e.g., /hardware/pedal-interceptor), no .md extension
• If a page describes hardware or software that has changed since the Tinkla era, note the current behavior and point to the relevant history page rather than leaving stale information in place

If you spot something wrong in an existing page, a pull request with a correction is faster than filing an issue about it.