Describe the big picture of your changes, explain your motivation and give as much context as possible. If it fixes a bug or resolves a feature request, be sure to link to that issue (use Github's auto-closing keywords.
Don't forget to set a meaningful title and use appropriate labels.
What types of changes does your code introduce?
- Bugfix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality to not work as expected)
This is the most important question to answer, as it can point out problems where you are making too many changes in one commit or branch. One or two bullet points for related changes may be okay, but five or six are likely indicators of a commit that is doing too many things.
Tell the reviewer what to expect, how to reproduce the original bug and how to test your changes.
Example:
- Login as
admin - Go to
/settings - Click on
Teamin the sidebar - Invite a new user
Do a mini review yourself before opening a pull request:
- Are the commits in good order, clean, and tidy?
- Are there extraneous things in any commits that should be split into their own?
- Are the commit messages clear and informative?
- Should anything be opened in it's own pull request?
Checkpoints for the reviewer:
- I reviewed the diff
- I have checked for linting issues
- I checked for missing or redundant test coverage
- I checked for missing translations
- Includes necessary documentation (optional)
- Includes offline node packages (optional)
- Code follows contribution guidelines
- Commit messages follow Angular's git commit guidelines
- All tests are passing
- Deployed to Netlify
- Branch name follows naming conventions
- Branch was deleted after successful merge
If your changes affect the UI, please include a screenshot.
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...