|
1 | | -## Changes |
2 | | -<!-- Summary of your changes that are easy to understand --> |
| 1 | +## What changes are proposed in this pull request? |
3 | 2 |
|
4 | | -## Tests |
5 | | -<!-- |
6 | | -How is this tested? Please see the checklist below and also describe any other relevant tests |
7 | | ---> |
| 3 | +Provide the readers and reviewers with the information they need to understand |
| 4 | +this PR in a comprehensive manner. |
8 | 5 |
|
9 | | -- [ ] `make test` run locally |
10 | | -- [ ] `make fmt` applied |
11 | | -- [ ] relevant integration tests applied |
| 6 | +Specifically, try to answer the two following questions: |
12 | 7 |
|
| 8 | +- **WHAT** changes are being made in the PR? This should be a summary of the |
| 9 | + major changes to allow the reader to quickly understand the PR without having |
| 10 | + to look at the code. |
| 11 | +- **WHY** are these changes needed? This should provide the context that the |
| 12 | + reader might be missing. For example, were there any decisions behind the |
| 13 | + change that are not reflected in the code itself? |
| 14 | + |
| 15 | +The “why part” is the most important of the two as it usually cannot be |
| 16 | +inferred from the code itself. A well-written PR description will help future |
| 17 | +developers (including your future self) to know how to interact and update your |
| 18 | +code. |
| 19 | + |
| 20 | +## How is this tested? |
| 21 | + |
| 22 | +Describe any tests you have done; especially if test tests are not part of |
| 23 | +the unit tests (e.g. local tests). |
| 24 | + |
| 25 | +**ALWAYS ANSWER THIS QUESTION:** Answer with "N/A" if tests are not applicable |
| 26 | +to your PR (e.g. if the PR only modifies comments). Do not be afraid of |
| 27 | +answering "Not tested" if the PR has not been tested. Being clear about what |
| 28 | +has been done and not done provides important context to the reviewers. |
0 commit comments