Skip to content

How to Contribute

OpenSkyhawk is built in the open and there's plenty to do. Whether you write firmware, lay out PCBs, model panels, or just want to improve the docs, this section explains how the project works and the conventions to follow.

Three disciplines

A cockpit panel is three things at once, and the project is organised the same way:

  • Firmware — the control logic on STM32/RP2040. Start with the Firmware Reference.
  • PCB hardware — KiCad schematics and boards. Start with Hardware Reference and the KiCad Workflow.
  • CAD / mechanical — the printed/machined panel enclosures, bezels, and knobs. See CAD Workflow (tooling still being decided).

Most panels need all three. The Adding a Controller page walks through how they fit together.

Ways to help

  • Build a planned panel. The left and right consoles are open ground — pick a panel group and own it. The Armament Group is the worked example to follow.
  • Implement a control type. Most input/output types are specified but not yet written — see Control Types for what's open.
  • Improve the docs. Every stub page is an invitation. See Docs Workflow.

Before you start

The canonical setup and PR essentials live in CONTRIBUTING.md at the repo root — toolchain install, claiming a NODE_ID, the PR process, and the Code of Conduct. The short version:

  • Branch from main with a feat/ fix/ chore/ docs/ ci/ build/ prefix; one focused change per PR.
  • Title the PR as a Conventional Commit, type(scope): summary — a required check enforces it.
  • Firmware: pio run must compile. PCB: ERC clean (DRC clean for layout PRs).
  • CI must pass — never merge with failing checks.
  • Claim your NODE_ID in Firmware/NODE_IDS.md before starting firmware work.

How releases work

  • Your PR title matters. Write it as type(scope): summary — e.g. feat(firmware): add a dimmer output or fix(pcb): swap the TVS diode. A required check fails the PR if it isn't; the title becomes the line in the changelog.
  • Firmware releases itself. Each merge to main keeps a draft "release firmware X.Y.Z" pull request up to date with the next version and its changelog. When a maintainer marks it ready and merges it, the release is tagged and published — nothing for you to do.
  • Hardware releases the same way. Commits under PCB/ keep a draft "release hardware X.Y.Z" pull request up to date. A board joins a release once it has been built and verified — it's then listed in PCB/manifest.yaml — and each board folder's README.md says whether it is Released, In progress, or Deprecated.

Want the details? See Releases and design decision D10.

In this section