Skip to content

How_to_contribute

Cccolt edited this page Mar 29, 2024 · 4 revisions

How to contribute to RMVL

As a person working in the robotics industry, or a RoboMaster team member, whether you are still in the competition or not, whether you are a member of the Vision team or not, we welcome and hope that you will contribute some code that you have thought about independently. All the bug fixes, new functionality, new tutorials etc. should be submitted via the GitHub's mechanism of pull requests.

If you are not familiar with the mechanism - do not worry, it's very simple. Keep reading.

1. Before you start contributing you should

  • Make sure you agree to contribute your code under RMVL (Apache 2.0) license.
  • If you are submitting a new algorithm implementation, do a quick search over internet to see whether the algorithm is patented or not.
  • If you are going to fix a bug, check that it still exists.
  • Make sure that nobody beat you into fixing or reporting the issue by doing a search on the Github RMVL issues page, and making sure that there isn't someone working on it. In the latter case you might provide support or suggestion in the issue or in the linked pull request.

Before you open up anything on the RMVL GitHub page, be sure that you are at the right place with your problem.

2. "Fork & Pull Request model" for code contribution

The instruction in brief

  1. Install Git。
  2. Register at GitHub. Create your fork of RMVL repository https://github.com/cv-rmvl/rmvl .
  3. Choose a task for yourself. It could be a bugfix or some new code.
  4. Choose a base branch for your work.
  5. Clone your fork to your computer.
  6. Create a new branch (with a meaningful name) from the base branch you chose.
  7. Modify/add the code following our coding style guide.
  8. Run test suite locally:
    • enable testing: cmake -D BUILD_TESTS=ON ..
    • execute each test binary from the build directory, You can directly use and run the ctest command line test tool for testing
  9. When you are done, push your branch to your GitHub fork; then create a pull request from your branch to the base branch.

3. Making a good pull request

Following these guidelines will increase the likelihood of your pull request being accepted:

  1. Before pushing your PR to the repository, make sure that it builds perfectly fine on your local system.
  2. Add enough information, like a meaningful title, the reason why you made the commit and a link to the issue page if you opened one for this PR.
  3. Scope your PR to one issue. Before submitting, make sure the diff contains no unrelated changes. If you want to cover more than one issue, submit your changes for each as separate pull requests.
  4. If you have added new functionality, you should update/create the relevant documentation, as well as add tests for it to the test suite. By the way, RMVL use GoogleTest for unit test.
  5. Try not to include "oops" commits - ones that just fix an error in the previous commit. If you have those, then before submitting squash those fixes directly into the commits where they belong.
  6. Make sure to choose the right base branch and to follow the coding style guide for your code.
  7. Make sure to add tests for new functionality or test that reproduces fixed bug with related test data. Please do not add extra images or videos, if some of existing media files are suitable.
  8. Make sure to add performance tests, if you propose optimization or the patch could affect performance of major functionality. RMVL use Benchmark as a performance test tool.

4. Testing and merging pull requests

  1. Your pull request will be automatically tested by RMVL Github Actions (testing status can be checked here: https://github.com/cv-rmvl/rmvl/actions). If any builders have failed, you should fix the issue. If you want to rerun builders, for Github Action, there is a button in the upper right corner of the status page. If you submit a wrong code, you just push changes to your branch on GitHub. No need to close pull request and open a new one!
  2. Once all the builders are "green", one of RMVL developers will review your code. Reviewer could ask you to modify your pull request. Please provide timely response for reviewers, otherwise your submission could be postponed or even rejected.

Here is the flow-chart of the process:

5. Happy End

  1. Once the reviewer is satisfied with the pull request, your PR will be reviewed for approval, which indicates that the RMVL maintenance staff can merge your PR.
  2. Last but not least, make sure you got credits. We try to memorize all the contributions and list major ones in the ChangeLog and release announcements, but we may forget to do that, unintentionally. Please, do not hesitate to remind us, and we will update the ChangeLog accordingly.

Happy End

This document provide a detailed guide for developers to contribute to RMVL. Of course, the content of this document also needs to be gradually revised and improved. If anything in this article is not properly described, please provide feedback to members of the cv-rmvl organization.