|
|
|
## General
|
|
|
|
|
|
|
|
* be polite
|
|
|
|
* encourage contributors (especially new ones)
|
|
|
|
* always give a lot of contexts
|
|
|
|
|
|
|
|
## Checks
|
|
|
|
|
|
|
|
* No merge issue
|
|
|
|
* Ensure up-to-date scripts
|
|
|
|
* Author of the PR is linked to a GitHub account
|
|
|
|
* Ensure the Technical Committee is on CC
|
|
|
|
|
|
|
|
### Target branch
|
|
|
|
|
|
|
|
Depending if this is a breaking change, the target branch needs to be different.
|
|
|
|
|
|
|
|
TODO: add more details about this.
|
|
|
|
|
|
|
|
## Review
|
|
|
|
|
|
|
|
It should be clear what the PR is changing (link to an issue, explanation, small OpenAPI Spec to reproduce the issue).
|
|
|
|
|
|
|
|
Unit tests are always great.
|
|
|
|
|
|
|
|
Test locally if needed.
|
|
|
|
|
|
|
|
Do not approve changes you do not understand.
|
|
|
|
|
|
|
|
If the change is in the common part (is applied for all languages), be extra careful.
|
|
|
|
Ask for a second review.
|
|
|
|
|
|
|
|
If necessary, ask the author about his change.
|
|
|
|
|
|
|
|
## Never merge your own PR
|
|
|
|
|
|
|
|
Somebody else needs to approve
|
|
|
|
|
|
|
|
Exception to the rule:
|
|
|
|
|
|
|
|
* The PR is only about updating the samples
|
|
|
|
* The PR is only about updating the docs
|
|
|
|
* The PR is only about adding a unit-test and CI is green
|
|
|
|
|
|
|
|
## Merge the Pull Request
|
|
|
|
|
|
|
|
Use the "Squash and merge" option:
|
|
|
|
|
|
|
|
<img width="300" alt="GitHub usage" src="https://user-images.githubusercontent.com/1222165/38855163-06c8e4f2-4223-11e8-970b-71f7d3cf3d07.png">
|
|
|
|
|
|
|
|
The history looks more clean with this option
|
|
|
|
|
|
|
|
### After merge tasks
|
|
|
|
|
|
|
|
* Ensure the milestone is set
|
|
|
|
* Ensure the labels are set correctly
|
|
|
|
|
