Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/qualcomm-qrb-ros/qrb_ros_simulation/llms.txt

Use this file to discover all available pages before exploring further.

QRB ROS Simulation welcomes contributions of all kinds — bug fixes, new features, documentation improvements, tests, and more. This page covers the process for reporting issues, proposing features, and submitting pull requests. All contributions are governed by the project’s Code of Conduct and the BSD-3-Clause license.

GitHub Issues

Report bugs, request features, or start a discussion.

GitHub Repository

Browse source code, fork the repo, and submit pull requests.

​
Code of conduct

Please read and follow the project’s Code of Conduct before participating. It applies to all project spaces including issues, pull requests, and discussions.

​
Bug reports

If you find a bug, check whether it has already been reported in GitHub Issues first. If not, open a new issue using the Bug Report template and fill in as much detail as possible. The best bug reports include a pull request with a fix.

​
Feature requests

To request a new feature, open an issue using the Feature Request template. If you want to implement a feature yourself, reach out before investing significant time — not all features can be supported, and early coordination prevents duplicated work.
  • Major features: Open an issue first to outline your proposal and align with maintainers before writing code.
  • Small features: You can implement these directly and submit a pull request.

​
Submitting a pull request

1

Fork the repository

Go to the repository page and click Fork. This creates a copy under your GitHub account.
2

Clone your fork

git clone https://github.com/<your-username>/<repository-name>
Replace <your-username> and <repository-name> with your GitHub username and the forked repository name.
3

Create a branch

Create a new branch from main for your changes:
git checkout -b <my-branch-name> main
4

Make and commit your changes

Make your changes, then commit using the DCO sign-off. You can use -s or --signoff to attest to the Developer Certificate of Origin:
git add .
git commit -s -m "<type>: <subject>"
See Commit message format below for the expected structure.
5

Push your branch

git push -u origin <my-branch-name>
6

Open a pull request

Go to your forked repository on GitHub. You should see a prompt to compare and create a pull request for your recently pushed branch. Add a title and description, then click Create pull request.Target the main branch. A maintainer will review your PR and may request changes.

​
Contributing guidelines

Before submitting a pull request, verify that your changes meet these requirements:
  • Code is well-documented and follows the ROS 2 code style and language version guidelines.
  • All changes are covered by tests.
  • Commits are descriptive, with a clear summary of what changed and why.
  • The pull request targets main and includes a clear summary of changes.
A few practices that help your pull request get accepted faster:
  • Keep changes focused. Submit independent changes as separate pull requests rather than bundling them.
  • Write a good commit message.
  • For large features or architecture changes, coordinate with other developers first to reach consensus before writing code — this avoids surprises in review.

​
Commit message format

The project follows Conventional Commits. A commit message consists of a header, an optional body, and an optional footer: 
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

​
Type

TypeDescription
buildChanges to the build system or external dependencies
choreOther changes that don’t modify source or test files
ciChanges to CI configuration files and scripts
docsDocumentation-only changes
featA new feature
fixA bug fix
perfA code change that improves performance
refactorA code change that neither fixes a bug nor adds a feature
revertReverts a previous commit
styleChanges that do not affect code meaning (whitespace, formatting, etc.)
testAdding missing tests or correcting existing tests

​
Description

  • Use the imperative, present tense: “change” not “changed” or “changes”
  • Do not capitalize the first letter
  • Do not end with a period

​
Body and footer

The body should explain the motivation for the change and contrast it with the previous behavior. Use the same imperative, present tense as the description. The footer references GitHub issues and other PRs, and documents breaking changes or deprecations: 
BREAKING CHANGE: <brief summary>

<detailed description and migration instructions>

Fixes #<issue number>

DEPRECATED: <what is deprecated>

<description and recommended update path>

Closes #<pr number>

​
Revert commits

If a commit reverts a previous commit, begin the message with revert: followed by the header of the reverted commit. The body should include: This reverts commit <hash>.

​
License

QRB ROS Simulation is licensed under the BSD-3-Clause license. By contributing, you agree that your contributions will be licensed under the same terms.

Build docs developers (and LLMs) love

Get started for freeTalk to us