|
| 1 | +### Requirements for Contributing to this repository |
| 2 | + |
| 3 | +* Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion. |
| 4 | +* The pull request must only fix one issue, or add one feature, at the time. |
| 5 | +* The pull request must update the test suite to demonstrate the changed functionality. |
| 6 | +* After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see [CONTRIBUTING](/CONTRIBUTING.md). |
| 7 | + |
| 8 | +### What does this PR do? |
| 9 | + |
| 10 | +<!-- |
| 11 | +
|
| 12 | +What inspired you to submit this pull request? |
| 13 | +Link to the issue describing the bug that you're fixing. |
| 14 | +
|
| 15 | +If there is not yet an issue for your bug, please open a new issue and then link to that issue in your pull request. |
| 16 | +Note: In some cases, one person's "bug" is another person's "feature." If the pull request does not address an existing issue with the "bug" label, the maintainers have the final say on whether the current behavior is a bug. |
| 17 | +
|
| 18 | +--> |
| 19 | + |
| 20 | +### Description of the Change |
| 21 | + |
| 22 | +<!-- |
| 23 | +
|
| 24 | +A brief description of the change being made with this pull request. |
| 25 | +
|
| 26 | +We must be able to understand the design of your change from this description. |
| 27 | +If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. |
| 28 | +Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts. |
| 29 | +
|
| 30 | +--> |
| 31 | + |
| 32 | +### Alternate Designs |
| 33 | + |
| 34 | +<!-- Explain what other alternates were considered and why the proposed version was selected --> |
| 35 | + |
| 36 | +### Possible Drawbacks |
| 37 | + |
| 38 | +<!-- What are the possible side-effects or negative impacts of the code change? --> |
| 39 | + |
| 40 | +### Verification Process |
| 41 | + |
| 42 | +<!-- |
| 43 | +
|
| 44 | +What process did you follow to verify that your change has the desired effects? |
| 45 | +
|
| 46 | +- How did you verify that all new functionality works as expected? |
| 47 | +- How did you verify that all changed functionality works as expected? |
| 48 | +- How did you verify that the change has not introduced any regressions? |
| 49 | +
|
| 50 | +Describe the actions you performed (including scripts, commands you ran, etc.), and describe the results you observed. |
| 51 | +
|
| 52 | +--> |
| 53 | + |
| 54 | +### Additional Notes |
| 55 | + |
| 56 | +<!-- Anything else we should know when reviewing? --> |
| 57 | + |
| 58 | +### Release Notes |
| 59 | + |
| 60 | +<!-- |
| 61 | +
|
| 62 | +If the PR title is not enough to describe the changes in a single line that explains this improvement in |
| 63 | +terms that a user can understand. This text will be added in release notes. |
| 64 | +
|
| 65 | +For example, you can provide additionnal notes about feature deprecation or backward incompatible changes. |
| 66 | +
|
| 67 | +--> |
| 68 | + |
| 69 | +### Review checklist (to be filled by reviewers) |
| 70 | + |
| 71 | +- [ ] Feature or bug fix MUST have appropriate tests (unit, integration, etc...) |
| 72 | +- [ ] PR title must be written as a CHANGELOG entry [(see why)](/CONTRIBUTING.md#pull-request-title) |
| 73 | +- [ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR) |
| 74 | +- [ ] PR must have one `changelog/` label attached. If applicable it should have the `backward-incompatible` label attached. |
| 75 | +- [ ] PR should not have `do-not-merge/` label attached. |
| 76 | +- [ ] If Applicable, issue must have `kind/` and `severity/` labels attached at least. |
| 77 | + |
0 commit comments