chore: add pull request templates

[liamnwhite1]

Pull request templates need to be added for the following pull request types:

• feature
• refactor
• bugfix
• chore

[streeve]

Very useful, but I'm not following the need to split out the different types of MR - am I missing things other than the auto-tagging?

Here's an attempt to combine your template with others I've found useful for clear and direct reviews:

Merge Request Description

Related Issues/Pull Requests

• Closes: #
• Related to: #
• Depends on: #

Reviewer Focus Areas

Merge Request Checklist

This checklist must be completed prior to merging. The person responsible
for checking the box indicating completeness of each item is listed at the
start of the item. Boxes that do not pertain to the MR (e.g. unit tests for a
pure documentation MR) can be checked with a ~ to indicate it is not
applicable.

Assignments

• (Developer) Lead developer assigned.
• (Developer) Lead reviewer and (optional) secondary reviewer(s) assigned.
  If a lead reviewer participates in development a secondary reviewer is strongly encouraged.

Description

• (Reviewer) MR objectives and summary clearly defined by the developer in the MR description
  or in an issue which the MR closes.

Validation

• (Reviewer) MR is covered by unit tests for new functionality and/or bug fixes
• (Reviewer) MR is well documented (e.g. comments, examples, etc.)
• (Reviewer) MR code is maintainable (see definition HERE)
• (Reviewer) MR contains (if applicable) regression tests for new functionality

[liamnwhite1]

@streeve No you're not missing anything! It was just easier on my end to create separate templates to test some of the workflow automations before actually merging them. And I agree that a single template is more robust and what we should eventually merge. I figured there would be change requests which is why I left the PR as a draft. I just wanted to get something in front of you to review.

Regarding your suggestions:

• I would advise against us referring to Pull Requests as Merge Requests. I am 100% on board with you that Merge Requests make more sense but with the focus of these changes being to integrate GitHub Copilot, we should use the language of the land which in this case is Pull Requests. Regardless of the underlying model, the overlay that GitHub puts on top will target "Pull Requests" to speed up searches and codebase traversals. I'm not saying it won't work if we change the terminology, but my personal philosophy when working with llms is to use the same language with which they are trained. Ultimately, I'll leave this up to you though.

• Assignments will be automated for all contributors to the pull request and all required reviewers so I would say we probably don't need the Assigments checklist.

• Regarding checklists in general, I tend to look at them as reminders for the person opening the pull request. If we want to enforce certain ones I always recommend adding git hooks for them.

Let me know your thoughts on these points and I'll get started on merging the PR templates into a single file!

[streeve]

I would advise against us referring to Pull Requests as Merge Requests. I am 100% on board with you that Merge Requests make more sense but with the focus of these changes being to integrate GitHub Copilot, we should use the language of the land which in this case is Pull Requests. Regardless of the underlying model, the overlay that GitHub puts on top will target "Pull Requests" to speed up searches and codebase traversals. I'm not saying it won't work if we change the terminology, but my personal philosophy when working with llms is to use the same language with which they are trained. Ultimately, I'll leave this up to you though.

Just a copy paste mistake on my part - I agree with you here

Assignments will be automated for all contributors to the pull request and all required reviewers so I would say we probably don't need the Assigments checklist.

This was a point of issue on another project, but I'm fine removing (I doubt we'll have the same problems)

Regarding checklists in general, I tend to look at them as reminders for the person opening the pull request. If we want to enforce certain ones I always recommend adding git hooks for them.

We've found them useful for both the developer and reviewer. As for automation, that sounds like a good follow-on