Contributing

View as Markdown

Contributing

RocketRide is MIT-licensed and developed in the open at rocketride-org/rocketride-server. There are more ways in than writing C++ — pick the one that fits:

I want to…	Start here
Report a bug or request a feature	Issue templates
Improve these docs	Improve the docs
Add an example	Docs & examples
Build a new node	Build a node
Work on the engine, SDKs, or protocol	Contribute code
Help other users	GitHub Discussions, Discord

All participation falls under the Code of Conduct.

Report bugs & request features

Use the issue templates — the Get Help page lists what to include so a report lands in one round-trip. Security vulnerabilities are the exception: report them privately via GitHub Security Advisories or security@rocketride.ai, never as a public issue (security policy).

Every change starts with an issue

Every pull request must be linked to an issue (Fixes #123 — enforced by CI), and branch names embed the issue number. The difference is how long to wait:

• Docs and examples: open the issue and PR right away — no discussion needed.
• New nodes, engine core, and protocol changes: open the issue first and get a nod before building. It protects your time — a node or engine change that conflicts with platform direction is hard to accept after the fact.

Improve the docs

Docs live in the same repo as the code, under docs/ — what you're reading is built from docs/public/. Two things to know:

• Some content is generated (node parameter tables, SDK references, package README copies) — regenerated by the build, never edited by hand. Hand-written prose is fair game.
• Validate before you push: node scripts/build.js docs:build builds the site with a broken-link gate, and ./builder docs:check catches generated drift.

Prose fixes are the easiest first contribution there is.

Build a node

Nodes are self-contained Python packages under nodes/src/nodes/ — most of the node catalog was built with the same contract you'd use. Open an issue describing the node first (see above), then follow the contributor guides in the repo:

• Node authoring — the README and services.json contracts, and the catalog.
• Contract tests: ./builder nodes:test, plus python3 scripts/validate-node-readme.py <node-dir> for the README.

Contribute code

1. Fork, then branch off develop. Branch names follow <type>/RR-<issue>-<short-description> (e.g. fix/RR-123-sql-injection-prevention) — a ruleset enforces this.
2. Read AGENTS.md — the repo's contributor guide — and docs/development/ for setup, builder usage, and engine internals.
3. Build and test with the builder: ./builder build, ./builder test.
4. Use conventional commits (feat(scope):, fix(scope):, docs(scope):).

The repo's CONTRIBUTING.md is the canonical process reference.

Review

Pull requests target develop. CI runs the build, the test suites, and the docs gates; a maintainer reviews from there. Unsure whether something is worth building? Ask first in Discussions — a five-minute conversation beats a closed PR.