Pull Request Template

pull-request-template-sample.md

Instructions

Be sure your feature branch is correctly named to reference the corresponding issue in JIRA. (e.g. BUS-275_my_new_feature)

Description

A few sentences describing the overall goals of the pull request's commits.

Impacted Areas in Application

List general components of the application that this PR will affect:

Type of change

Please delete options that are not relevant.

• Bug fix (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 change requires a documentation update

Todos

• Tests
• Documentation

Steps to Test or Reproduce

Outline the steps to test or reproduce the PR here.

git pull --prune
git checkout <feature_branch>
bundle; script/server

Where has this been tested?

Local Docker Container: YES | NO

Sandbox: YES | NO

Related PRs

List related PRs against other branches and projects:

repo	branch	PR
other_pr_production	other_pr_production	link
other_pr_master	other_pr_master	link

A PR template would be an awesome addition to our git workflow! I think trying to find a balance between what should be in a PR and what should be in the corresponding JIRA ticket (because most every PR will have a PBI) is key. I have the following suggestions/simplifications:

• Combine "Description" with "Impacted areas in Application" (or get rid of impacted areas section) - This is a critical thing I find myself best conveying to the reader in a free flow way i.e. description. Reading the description and seeing the list of file changes should be sufficient to orient reviewers as to the components that are changing.
• Really like the "Type of Change" section. Even more important than the components that are changing is the how are they changing. This same type of field should be in our JIRA tickets (don't think it currently is though). However, I think it will provide major benefit to the reviewer to bear in mind the consequence of the given PR in their review process, especially since one of the most important reasons of the PR process is to communicate these types of changes... I would add this to it as well:
  [ ] This change requires a salt config update
• Curious, how will the todo's work? They are todos for the one who opened the PR and should be validated by the one reviewing?
  I like the idea of a TODO list as a reminder of good things to check. Here is another I think is a good reminder.
  [ ] Commented code, particularly in hard-to-understand areas
• Remove "Steps to Reproduce" - I imagine this will just be "run pytest"
• "Where has this been tested" - I imagine this will simply be "my machine" for the majority of PR's. Maybe if we start getting more exotic in pre-dev testing this would be more useful.
• "Related PRs" - Found in JIRA ticket.

These are just my suggestions (as one user of our github) mainly in order to keep friction low in the PR process (we already have quite a bit for any given PR). And perhaps there is room to customize PR templates between our git repos in case some sections prove useful to other repo's.