Skip to content

Update REP links in Contributing Section (backport #6012) #6015

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 14, 2025
+11 −11
Merged

Update REP links in Contributing Section (backport #6012) #6015

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion source/The-ROS2-Project/Contributing/Code-Style-Language-Versions.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -378,7 +378,7 @@ CMake
Version
^^^^^^^

Read `REP 2000 <https://www.ros.org/reps/rep-2000.html>`_ to determine the minimum CMake version you should support.
Read `REP 2000 <https://reps.openrobotics.org/rep-2000/>`_ to determine the minimum CMake version you should support.
Currently the minimum version of any supported ROS distro is **3.14.4** (ROS Humble on macOS).

Style
Expand Down
20 changes: 10 additions & 10 deletions source/The-ROS2-Project/Contributing/Developer-Guide.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ Some principles are common to all ROS 2 development:
Quality Practices
-----------------

Packages can ascribe to different levels of quality based on the development practices they adhere to, as per the guidelines in `REP 2004: Package Quality Categories <https://www.ros.org/reps/rep-2004.html>`_.
Packages can ascribe to different levels of quality based on the development practices they adhere to, as per the guidelines in `REP 2004: Package Quality Categories <https://reps.openrobotics.org/rep-2004/>`_.
The categories are differentiated by their policies on versioning, testing, documentation, and more.

The following sections are the specific development rules we follow to ensure core packages are of the highest quality ('Level 1').
Expand Down Expand Up @@ -145,7 +145,7 @@ Change control process

* DCO is *not* required for pull requests that only address whitespace removal, typo correction, and other `trivial changes <http://cr.openjdk.java.net/~jrose/draft/trivial-fixes.html>`_.

* Always run CI jobs for all `tier 1 platforms <https://www.ros.org/reps/rep-2000.html#support-tiers>`_ for every pull request and include links to jobs in the pull request.
* Always run CI jobs for all `tier 1 platforms <https://reps.openrobotics.org/rep-2000/#support-tiers>`_ for every pull request and include links to jobs in the pull request.
(If you don't have access to the Jenkins jobs someone will trigger the jobs for you.)

* A minimum of 1 approval from a fellow developer who did not author the pull request is required to consider it approved.
Expand Down Expand Up @@ -261,7 +261,7 @@ General Practices

Some practices are common to all ROS 2 development.

These practices don't affect package quality level as described in `REP 2004 <https://www.ros.org/reps/rep-2004.html>`_, but are still highly recommended for the development process.
These practices don't affect package quality level as described in `REP 2004 <https://reps.openrobotics.org/rep-2004/>`_, but are still highly recommended for the development process.

Issues
^^^^^^
Expand Down Expand Up @@ -393,7 +393,7 @@ For example, a new function ``rmw_foo()`` introduced to the RMW API must be impl
* `rmw_fastrtps <https://github.com/ros2/rmw_fastrtps>`__

Updates for non-Tier 1 middleware libraries should also be considered if feasible (e.g. depending on the size of the change).
See `REP-2000 <https://www.ros.org/reps/rep-2000.html>`__ for the list of middleware libraries and their tiers.
See `REP-2000 <https://reps.openrobotics.org/rep-2000/>`__ for the list of middleware libraries and their tiers.

Tracking tasks
^^^^^^^^^^^^^^
Expand Down Expand Up @@ -426,7 +426,7 @@ Package Naming Conventions
Names play an important role in ROS and following naming conventions simplifies the process of learning and understanding large systems.

The ROS packages occupy a flat namespace, so naming should be done carefully and consistently.
There is a standard for package naming in `REP-144 <https://www.ros.org/reps/rep-0144.html>`__
There is a standard for package naming in `REP-144 <https://reps.openrobotics.org/rep-0144/>`__

* Package names should follow common C variable naming conventions: lower case, start with a letter, use underscore separators, e.g. laser_viewer

Expand Down Expand Up @@ -454,10 +454,10 @@ There is a standard for package naming in `REP-144 <https://www.ros.org/reps/rep
Units of Measure and Coordinate System Conventions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Standard units and coordinate conventions for use in ROS have been formalized in `REP-103 <https://www.ros.org/reps/rep-0103.html>`__.
Standard units and coordinate conventions for use in ROS have been formalized in `REP-0103 <https://reps.openrobotics.org/rep-0103/>`__.
All messages should follow these guidelines unless there's a very strong reason which is very clearly documented to avoid confusion.

Representation of special conditions within distance measurements like "too close" or "too far" in ROS have been formalized in `REP-0117 <https://www.ros.org/reps/rep-0117.html>`__.
Representation of special conditions within distance measurements like "too close" or "too far" in ROS have been formalized in `REP-0117 <https://reps.openrobotics.org/rep-0117/>`__.

Programming conventions
^^^^^^^^^^^^^^^^^^^^^^^
Expand Down Expand Up @@ -499,7 +499,7 @@ Package layout
* ``msg``: contains all ROS Message definitions
* ``srv``: contains all ROS Service definitions
* ``action``: contains all ROS Action definitions
* ``package.xml``: as defined by `REP-0140 <https://www.ros.org/reps/rep-0140.html>`_ (may be updated for prototyping)
* ``package.xml``: as defined by `REP-0140 <https://reps.openrobotics.org/rep-0140/>`_ (may be updated for prototyping)
* ``CMakeLists.txt``: only ROS packages which use CMake
* ``setup.py``: only ROS packages which use Python code only
* ``README``: can be rendered on GitHub as a landing page for the project
Expand All @@ -513,7 +513,7 @@ Package layout
* This might include license implication, e.g. when using the Apache 2 License.

* ``LICENSE``: a copy of the license or licenses for this package
* ``CHANGELOG.rst``: `REP-0132 <https://www.ros.org/reps/rep-0132.html>`_ compliant changelog
* ``CHANGELOG.rst``: `REP-0132 <https://reps.openrobotics.org/rep-0132/>`_ compliant changelog

Repository layout
~~~~~~~~~~~~~~~~~
Expand Down Expand Up @@ -676,7 +676,7 @@ Design document review

Once the design is ready for review, a pull request should be opened and appropriate reviewers should be assigned.
It is recommended to include project owner(s) -
maintainers of all impacted packages (as defined by ``package.xml`` maintainer field, see `REP-140 <https://www.ros.org/reps/rep-0140.html#maintainer-multiple-but-at-least-one>`__) - as reviewers.
maintainers of all impacted packages (as defined by ``package.xml`` maintainer field, see `REP-140 <https://reps.openrobotics.org/rep-0140/#required-tags>`__) - as reviewers.

* If the design doc is complex or reviewers have conflicting schedules, an optional design review meeting can be set up.
In this case,
Expand Down