-
Notifications
You must be signed in to change notification settings - Fork 146
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
Update PULL_REQUEST_TEMPLATE.md #574
Conversation
|
||
# How was the feature tested? | ||
|
||
- [ ] Unit tests |
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.
maybe leave this in? Not sure if people are using it. If not, just delete :D
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.
Imo "how was this feature tested" is too broad. GH already shows you below which types of tests are passing or failing, and there's info in the main README about what each type of test is useful for.
The most important PR considerations in my mind are:
- what new or existing tests are acting as regression tests
- what new or existing tests are validating new behavior.
Just my two cents :), not trying to take things away that people like
Inspired by a talk @MSalopek and I just had. Only include things that're neccessary, merge agreements etc. should be defined elsewhere or enforced by reviewers and GH rules.
The
Type of Change
section will be important in reducing the effort it takes to review PRs. If a PR is aFeature
andRefactor
for example, this template will explicitly call out that the changes should likely be split up.