Before Start Programming

  1. Write a design document and verify it with all others, please use the template
  2. Create an issue to track progress. Adhere to the template questions provided while the issue is created.
  3. In addition, include the following content in the issue:
    1. A brief description of why the issue is required.
    2. Any external links or documents complementing the content of the issue.
    3. A set of acceptance criteria used for validating the pull request.
    4. Component label to which the issue belongs. Example, optimizer, state management, etc.

Scheduling

Common mode: If the issue is created and you want to work on it, you have to groom it in the next upcoming scrum meeting. In this session, you will present and describe the issue to the others. If everybody is aware of what has to be done and the acceptance criteria and doing are clear, we will schedule the issue for the next sprint. Then, you can start working on it.

Bypass mode: If the change is a hot-fix or required bug-fix, the issue can be directly worked on but has to be scheduled in the current sprint board.

Coding

  1. When it is clear what has to be done, start coding and open PR for peer-review once the issue is done.
  2. Start your branch name with the issue number, for example: 123-my-awesome-feature.
  3. While committing changes to your branch use the issue number before the commit message, for example: “#123: added a new method to support my awesome feature”.
  4. Add descriptive commit messages and avoid committing with messages like “test”, “WIP”, “fixed”, “123”, etc.
  5. Make sure you adhere to the code_guidelines
  6. Make sure to use the right log level logging
  7. Make sure all tests are green in debug and release build (the CI will run the release build)

Review

Once you are sure you have everything done in the issue, open a PR, and link the issue there. Request review from at least two people. If you got the approval of all of them, either merge your PR into master or ask a admin to do this. Usually, the review process takes several iterations.

Rule for comments:

  • If you did what the reviewer asked you, you can resolve the open common
  • If you did not understand what the reviewer asked for or there is the need for a discussion, contact the reviewer or reply with a comment

Finalization

  1. Once PR is accepted and the changes are merged, please make sure to delete your branch to keep the repository clean.

Git Configuration

Please, make sure to have git configured as follows:

git config –global pull.rebase true

 
how_to_contribute_code.txt · Last modified: 2021/03/11 13:53 by 134.96.191.189
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki