|
| 1 | +Thank you for your PR. Please follow the steps in this template to ensure a |
| 2 | +swift review. |
| 3 | + |
| 4 | +1. Read and follow the guidelines for contributing here: |
| 5 | + https://github.com/grpc/grpc-go/blob/master/CONTRIBUTING.md |
| 6 | + |
| 7 | + Note: if you are submitting a PR that does not address an open issue with an |
| 8 | + agreed resolution, it is much more likely your PR will be rejected. |
| 9 | + |
| 10 | +2. Read and follow the guidelines for PR titles and descriptions here: |
| 11 | + https://google.github.io/eng-practices/review/developer/cl-descriptions.html |
| 12 | + |
| 13 | + *Particularly* the sections "First Line" and "Body is Informative". |
| 14 | + |
| 15 | + Note: your PR description will be used as the git commit message in a |
| 16 | + squash-and-merge if your PR is approved. We may make changes to this as |
| 17 | + necessary. |
| 18 | + |
| 19 | +3. PR titles should start with the name of the component being addressed, or the |
| 20 | + type of change. Examples: transport, client, server, round_robin, xds, |
| 21 | + cleanup, deps. |
| 22 | + |
| 23 | +4. Does this PR relate to an open issue? On the first line, please use the tag |
| 24 | + `Fixes #<issue>` to ensure the issue is closed when the PR is merged. Or use |
| 25 | + `Updates #<issue>` if the PR is related to an open issue, but does not fix |
| 26 | + it. Consider filing an issue if one does not already exist. |
| 27 | + |
| 28 | +5. PR descriptions *must* conclude with release notes as follows: |
| 29 | + |
| 30 | + ``` |
| 31 | + RELEASE NOTES: |
| 32 | + * <componenet>: <summary> |
| 33 | + ``` |
| 34 | + |
| 35 | + This need not match the PR title. |
| 36 | + |
| 37 | + The summary must: |
| 38 | + |
| 39 | + * be something that gRPC users will understand. |
| 40 | + |
| 41 | + * clearly explain the feature being added, the issue being fixed, or the |
| 42 | + behavior being changed, etc. If fixing a bug, be clear about how the bug |
| 43 | + can be triggered by an end-user. |
| 44 | + |
| 45 | + * begin with a capital letter and use complete sentences. |
| 46 | + |
| 47 | + * be as short as possible to describe the change being made. |
| 48 | + |
| 49 | + If a PR is not end-user visible -- e.g. a cleanup, testing change, or |
| 50 | + github-related, use `RELEASE NOTES: n/a`. |
| 51 | + |
| 52 | +6. Self-review your code changes before sending your PR. |
| 53 | + |
| 54 | +7. Delete all of the above before sending your PR. |
0 commit comments