docs: Update PR templates

[jbkyang-nvi]

What does the PR do?

This PR adds a guideline template that all PRs should follow, so that Triton maintains its code quality.
This will populate any new PRs with this description.
ref

Checklist

• PR title reflects the change and is of format <commit_type>: <Title>
• Changes are described in the pull request.
• Related issues are referenced.
• Populated github labels field
• Added test plan and verified test passes.
• Verified that the PR passes existing CI.
• Verified copyright is correct on all changed files.
• Added succinct git squash message before merging ref.
• All template sections are filled out.
• Optional: Additional screenshots for behavior/output changes with before/after.

Commit Type:

Check the conventional commit type
box here and add the label to the github PR.

• build
• chore
• ci
• docs
• feat
• fix
• perf
• refactor
• revert
• style
• test

Related PRs:

No related PRs

Where should the reviewer start?

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

Test plan:

No e2e tests added, this page should test if it works

• CI Pipeline ID: N/A

Internal contribution view: pull_request_template
external contribution view: pull_request_template_external_contrib.md

Caveats:

Reviewers are in charge of verifying the fields are all populated

Background

Currently Triton PRs have been getting merged with many lines of redundant git commits (not squashed), or have been neglected in testing. This is an effort to improve this behavior

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

None

[GuanLuo]

MTGL. Left some comments for style.

[tanmayv25]

can you include checking/updating copyright years in this checklist?

[rmccorm4]

Thoughts on:

1. One template, adding an "External Contributor" section with a reminder of CLA requirement
   or
2. Two templates: Internal and External Contributor? External one having CLA requirement as well has possibly fewer section like no Pipeline ID?

[rmccorm4]

Aiming to reduce the overhead of external PRs having the extra round trip of "Hey, did you sign the CLA?"

[nnshah1]

I think two templates make sense - as it also would could have a section on pre-commit / code ql

[rmccorm4]

Should we just use the Conventional Commits list if that's what we're going for here?

[
  'build',
  'chore',
  'ci',
  'docs',
  'feat',
  'fix',
  'perf',
  'refactor',
  'revert',
  'style',
  'test'
];

https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional

[rmccorm4]

And do we want to enforce having it in the PR title for automatic release notes / change logs?

ex:

chore: Update PR Template

[nnshah1]

like the idea of referencing an existing standard / practice

[rmccorm4]

It looks like there are some github actions that can do either/both:

1. enforce PR titles follow the structure <conventional_commit_type>: <Title>
2. enforce all commit messages follow <conventional_commit_type>: <commit_message>

I think (2) may be overkill or more of a "shock" to current workflows, but (1) could be a nice start for automating the check - maybe consider (2) later IMO.

I didn't find any particular action/tool/repo that seemed like more of a gold standard than the others, so may need to poke around at what some other big projects do that we like.

[matthewkotila]

In general, looks good to me--thanks for helping us improve our code quality 🙏