Contributing

This is the on-ramp for code contributors. If you're authoring art assets (bikes, tracks, props) you probably want the Modding section instead.

The canonical contributor guide is the repo's CONTRIBUTING.md — it covers setup, branch naming, commit style, and PR review.

This site adds the orientation a newcomer probably wants on day one:

• Architecture — the load-bearing rules of the codebase. Read this before touching layer boundaries.
• Testing — what gets unit-tested vs. e2e-tested, what runs in CI, and how to write a new test.
• Code review — what reviewers care about, what conventions PRs are expected to follow.

If you only have time for one page, read Architecture. The sim-layer rule is the constraint most likely to surprise a newcomer.

Filing issues

Use the templates:

• Bug report
• Feature / idea

For security issues, see SECURITY.md — don't open public issues for those.

Good first PRs

• Items in docs/blender-wishlist.md — open roadmap for Blender automation.
• Unchecked rows in the convention table in docs/v1-work-breakdown.md — the active v1 execution plan.
• Issues labelled good first issue or help wanted on GitHub.

Open a draft PR or a discussion early if you're not sure — easier to course-correct before you've written a thousand lines.