PR template: Request manual repro instructions #35102
Conversation
Code reviewers working in other areas of the ecosystem have found this to be a useful habit. It's not always practical, but when it is, it's nice.
.github/pull_request_template.md
Outdated
| @@ -2,6 +2,8 @@ | |||
|
|
|||
| Describe in detail the changes you are proposing, and the rationale. | |||
|
|
|||
| Also, if it's practical, please provide an example config and commands for manually testing this change with Terraform CLI. (This isn't always possible, but it can enable better and faster reviews for your PR.) | |||
There was a problem hiding this comment.
Perhaps we could add some headings so the contributor can just fill them in?
e.g. #Old behaviour, #New behaviour, #How to test ##Example config ##Commands
There was a problem hiding this comment.
@kmoe That's a good idea!
I updated the PR to give that a try; it might have too many headers, but let's see what folks think.
| ## Reason for change | ||
|
|
||
| ## Old behavior | ||
|
|
||
| ## New behavior |
There was a problem hiding this comment.
I have two related concerns:
- Adding all these fields makes the PR template pretty long and could be a potential barrier to someone submitting a PR, especially if it's something simple.
- Our contributing guide already sets the standard that changes should be proposed in a GitHub issue first, so that would be the right place to describe this information, and not in the PR itself.
Thankfully both of these concerns can be addressed by a single solution: emphasize that a GitHub issue is the place to include this info, which simplifies the PR template quite a bit.
| ## Reason for change | |
| ## Old behavior | |
| ## New behavior |
| ## New behavior | ||
|
|
||
| ## How to verify | ||
|
|
There was a problem hiding this comment.
| <!-- If practical, describe how to manually test the change; this isn't always possible, but it makes PRs easier and faster to review. --> | |
| @@ -1,13 +1,25 @@ | |||
| <!-- | |||
|
|
|||
| Describe in detail the changes you are proposing, and the rationale. | |||
| Describe in detail the changes you are proposing, and the rationale. If practical, describe how to manually test the change; this isn't always possible, but it makes PRs easier and faster to review. | |||
There was a problem hiding this comment.
| Describe in detail the changes you are proposing, and the rationale. If practical, describe how to manually test the change; this isn't always possible, but it makes PRs easier and faster to review. | |
| Your pull request should be accompanied by a GitHub issue that describes in detail the changes you are proposing, and the rationale. |
| @@ -1,13 +1,25 @@ | |||
| <!-- | |||
|
|
|||
| Describe in detail the changes you are proposing, and the rationale. | |||
| Describe in detail the changes you are proposing, and the rationale. If practical, describe how to manually test the change; this isn't always possible, but it makes PRs easier and faster to review. | |||
|
|
|||
| See the contributing guide: | |||
|
|
|||
| https://github.com/hashicorp/terraform/blob/main/.github/CONTRIBUTING.md | |||
|
|
|||
| --> | |||
|
|
|||
There was a problem hiding this comment.
| Fixes # | |
| <!-- Link all GitHub issues fixed by this PR, and add references to prior related PRs. --> |
Bring this up to the top since it's the most important thing.
| <!-- | ||
|
|
||
| Link all GitHub issues fixed by this PR, and add references to prior |
There was a problem hiding this comment.
| <!-- | |
| Link all GitHub issues fixed by this PR, and add references to prior |
Remove this plus lines 26 through 31. (GitHub UI is not letting me make that suggestion for whatever reason.)
| ## How to verify | ||
|
|
||
| ### Example config | ||
|
|
There was a problem hiding this comment.
Can we give an example here in a <!-- comment -->?
| ### Example config | ||
|
|
||
| ### Commands | ||
|
|
There was a problem hiding this comment.
Can we give an example here in a <!-- comment -->?
Code reviewers working in other areas of the ecosystem have found this to be a useful habit. It's not always practical, but when it is, it's nice.
(no changelog entry, no code changes.)