How to Contribute

Standards for subprojects

Subprojects must meet the following criteria (and the WG agrees to maintain them upon adoption).

  • Build passes against ROS 2 master

  • The ROS 2 standard linter set is enabled and adhered to

  • If packages are part of nightly builds on the ROS build farm, there are no reported warnings or test failures

  • Quality builds are green (address sanitizer, thread sanitizer, clang thread safety analysis)

  • Test suite passes

  • Code coverage is measured, and non-decreasing level is enforced in PRs

  • Issues and pull requests receive prompt responses

  • Releases go out regularly when bugfixes or new features are introduced

  • The backlog is maintained, avoiding longstanding stale issues

Adding new subprojects

To request introduction of a new subproject, add a list item to the “Subprojects” section and open a Pull Request to this repository, following the default Pull Request Template to populate the text of the PR.

PR will be merged on unanimous approval from Approvers.

Subproject changes

Modify the relevant list item in the “Subprojects” section and open a Pull Request to this repository, following the default Pull Request Template to populate the text of the PR.

PR will be merged on unanimous approval from Approvers.

Deprecating subprojects

Projects cease to be useful, or the WG can decide it is no longer in their interest to maintain. We do not commit to maintaining every subproject in perpetuity.

To suggest removal of a subproject, remove the relevant list item in the “Subprojects” section and open a Pull Request in this repository, following instructions in the Pull Request Template to populate the text of the PR.

PR will be merged on unanimous approval from Approvers.

If the repositories of the subproject are under the WG’s GitHub organization, they will be transferred out of the organization or deleted at this time.