Feature/issue 63 pr template

[JohnHalleyGotway]

Pull Request Testing

• [x] Describe testing already performed for these changes:
  None really. Just adding this PR template. I copied/pasted the proposed template into this PR by way of example.

• [x] Recommend testing for the reviewer(s) to perform:
  For multiple reviewers, list specific instructions for each:
  No real testing necessary. @jwolff-ncar and @fossell, please just review the content of the PR template. Any additions or changes?

• [x] Are any changes to the online tutorial required for this PR? [No]
  If yes, please describe:
  

• [x] Will this PR change the output of any of the existing cases? [No]
  If yes, please describe:
  

• [x] Please complete this pull request review by [Thursday 9/16/21].
  Review should only take a couple of minutes.

Pull Request Checklist

• [x] Ensure the PR title matches the feature or bugfix branch name.
• [x] Define the PR metadata, as permissions allow: Select: Reviewer(s), Projects(s), and Milestone.
• [x] After submitting the PR, select Linked issues with the original issue number.
• [x] After the PR is approved, merge your changes, as permissions allow.
• [x] Close the linked issue and delete your feature or bugfix branch from GitHub.

[fossell]

@JohnHalleyGotway - I think this is a good start and don't have much to add for these testing checklists. I'd need to use it for the project a bit to see if there are gaps or changes to help improve it, so my vote would be to merge and enhance later.

More generally, should we expand this template to also include things like description of changes, issues this fixes, etc.? We could just start with this to streamline our testing/review requests and add to the template as time allows too.

[JohnHalleyGotway]

Kate,

Thanks for the feedback. Personally no, I do not think the nitty gritty details about description of changes belong in the pull request. Instead, all of those details should live in the issue... either in the body of the issue or in comments to it. And we can certainly create issue templates to cover those details, if warranted. The PR should remain focused on testing those changes and making note of their expected impacts on existing systems.

I've gotten used to the following naming conventions in METplus and find them to be very helpful:

• Write up an issue to describe some work to be done, and make note of that issue number.
• Create a feature branch that includes that issue number followed by a very concise description, like "feature/issue_63_pr_template".
• Do the work on that feature branch (or in a fork if you don't have permission) and push it up to GitHub.
• Submit a PR to merge the feature branch into the source branch (i.e. main) and set the PR name = feature branch name.
• Link the PR to the source issue (I realize that I failed to include that step in our PR template, but will add it now).

This process keeps the issues that describe the work well linked to the PR's that describe their impacts.

[fossell]

@JohnHalleyGotway - That makes sense, I know it varies by project, some have all info in PR. I don't have a strong preference, as long as we define what we're doing here for this project and stick to it. I'll approve this now, and then if we wan tto discuss adding/changing in the future when we have time that is fine too.

[JohnHalleyGotway]

@jwolff-ncar are you still planning to review, or should I remove you as a reviewer and proceed with only the review from @fossell?