ROS-Industrial Development Process

Overview

ROS-Industrial is a community project. We welcome contributions from any source, from those who are extremely active to casual users. To make contribution a smooth process and to avoid potential frustration, development is done according to a specific workflow that is shown in Figure 1 below. The figure shows a high level overview of the various actors involved in the ROS-Industrial development process, together with the typical flow of information between these actors (numbered arrows) and the resulting division of work.

Refer to the next sections for further clarification.

Figure 1: The ROS-Industrial Development Process (click for the full-size version).

The process

The following sections each describe one phase in the development workflow and software life-cycle. This ranges from ideation, design and implementation to release, usage and maintenance.

To make the examples given more concrete, some sections refer to repositories, clones, forks, branches, pull and push. This terminology is used in the context of Git, the version control system most popular in ROS and ROS-Industrial. For more information on the "Fork and Branch" Git workflow we use, refer to the following article: Using the Fork-and-Branch Git Workflow.

Note that section numbering corresponds to the marked arrows in the diagram above, so Section 2.3 describes the Fork and Pull Request practice numbered ③.

Requirements gathering

Before any development is undertaken, a contributor would communicate a need or the discovery of a problem to the ROS-Industrial community. This can be done by submitting a bug report to the appropriate GitHub issue repository, the central ROS-Industrial Issues repository, or by emailing the users group. Doing so may save you time if similar development is underway or an issue already known, and ensure that whatever approach you take is acceptable to the community of reviewers once it is submitted.

Design/Implementation

In the case of new development or bug fixing, the second step would be to implement the design or correct the identified problem(s). If you are working on a code contribution, we highly recommend you utilise the ROS Qt-Creator plugin. Verify your change successfully builds and passes all tests locally (by running all the unit and integration tests).

Contribution via Pull Requests

Next, push your changes to a feature branch in your personal fork of the repository and create a Pull Request (PR). The PR allows maintainers to review the submitted code. Before the PR can be accepted, the maintainer and contributor must agree that the contribution is implemented appropriately. This process can take several back and forth steps (example). Contributors should expect to spend as much time reviewing/changing the code as on the initial implementation. This time can be minimised by communicating early with the ROS-Industrial community and good design before any contribution is made.

Quality Assurance

Text.

Pull Request approval

Text.

Status labelling

Text.

Release management

Text.

Package distribution

Text.

End-users

Text.

Support/Bug reporting

Text.