Contribution Lanes

Lane Examples
Documentation System notes, user guidance, diagrams, clarification of setup, and assumptions.
Mechanical and electrical Packaging, brackets, board layout, power notes, safety-oriented bring-up procedures.
Robotics software ROS 2 integration, perception pipelines, navigation logic, manipulation behavior.
Tooling and validation Tests, reproducibility helpers, repository automation, operator support workflows.

Before Large Changes

Open an issue first if the change is broad, architectural, or safety-sensitive. The project is still defining its first reproducible baseline, so discussion up front prevents drift in interfaces and operator assumptions.

What A Good Pull Request Explains

Documentation diffs

  • What was unclear or missing
  • What wording or links changed
  • Whether diagrams or screenshots also need follow-up

Hardware diffs

  • Design intent and affected subsystem
  • Changed dimensions, interfaces, or sourcing assumptions
  • Any operator-safety or assembly guidance that must change too

Software diffs

  • What behavior changed
  • How it was validated
  • What hardware or environment assumptions were made

Rules Worth Making Explicit

  • Prefer clear, direct writing over marketing language.
  • Favor incremental changes over broad speculative rewrites.
  • Add rationale when the decision is not obvious from the diff itself.
  • Do not silently change deployment assumptions, task definitions, safety-related defaults, or subsystem boundaries.

Support Routing

Need Recommended route
Project direction question Open a Question / Support issue.
Broken docs or reproducible repo behavior mismatch Open a Bug Report issue.
New subsystem direction or tooling proposal Open a Feature Request issue.
Security vulnerability Do not use a public issue. Follow the direct security reporting note on the Safety page.