-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PR template: Request manual repro instructions #35102
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<!-- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<!-- | |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we give an example here in a <!-- comment -->
?
### Example config | ||
|
||
### Commands | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.)