Contributing
A practical workflow for focused, reproducible, and safely validated contributions.
ESPFlight Docs · v1 • Validated v1 documentation path
# Contribution workflow
- Start from the relevant repository and current baseline. Fork/branch the component you intend to change and record the exact tag or commit you started from.
- Reproduce or define the problem. Explain current behavior, expected behavior, hardware assumptions, and why the change belongs in the platform.
- Keep the patch focused. Avoid unrelated formatting, refactors, or hardware changes in the same review unless they are required.
- Build and validate. Use the documented toolchain. Flight-affecting changes require propeller-off validation; add controlled flight evidence when the behavior cannot be validated safely on the bench.
- Document compatibility effects. Call out protocol, pin, hardware, licensing, configuration, or safety changes explicitly.
- Open a pull request. Include reproduction steps, validation results, logs/screenshots when useful, and the exact environment used.
SAFETY
A successful compile is not flight validation. Changes that can affect motor output, flight state, sensors, failsafe behavior, or networking need evidence appropriate to their risk.
# Review checklist
Problem and intended behavior are clear.
Exact firmware tag/commit, board revision, toolchain, and libraries are stated.
Unrelated changes are excluded.
Hardware assumptions and test conditions are explicit.
Bench and, when needed, controlled-flight results are included.
Protocol and compatibility changes are identified.