Update PULL_REQUEST_TEMPLATE.md
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index cd0ac47..430df57 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,60 +1,15 @@
-<!-- ----------------------------------------------------------------
- If you're editing this as a result of an invocation of a GitHub CLI
- tool, note that lines that begin with '#' are stripped. To preserve the
- markdown that begins with '#' below, be sure to preserve the leading
- whitespace on those lines.
--->
+#### Problem
+What is being fixed? Examples:
+* Fix crash on startup
+* Fixes #12345 12345 Frobnozzle is leaky (exactly like that, so GitHub will auto-close the issue).
- #### Problem
- <<<<<FILL ME IN - the issue this PR is intended to address>>>>>
+#### Change overview
+What's in this PR
-<!-- ----------------------------------------------------------------
- In the Problem section please describe what motivates the proposed changes.
-
- Please do your best to couch the motivation as a problem you're
- trying to address. This makes reviewers' jobs easier: they
- can verify that the code actually targets the problem and
- pick out code that maybe should be in another PR because it
- targets another problem.
-
- "Do" examples:
- "CHIP does not support IP-rendezvous"
- "SystemTimer::Cancel() causes a crash when the aContext is null"
- "OpCert generation can overflow the output buffer"
-
- "Don't" examples:
- "updating codeowners"
- ""
- "add BLE support"
--->
-
- #### Summary of Changes
- <<<<<FILL ME IN - what's in this PR>>>>>
-
-<!-- ----------------------------------------------------------------
- In the Summary of Changes section please describe, as completely as possible,
- what changes you've made. A bulleted list of items is great here, and if
- your PR is a draft, you can use checkboxes as you make progress through your
- planned steps. The goal of this section is again to aid reviewer's work. A
- reviewer can tick down the list looking at how your changes affect the code,
- that your list covers what's changed, and that your changes address the
- problem (and not another problem).
--->
-
- Fixes #<<<<<FILL ME IN - issue number(s). If no issue, please create one>>>>>
-
-<!-- ----------------------------------------------------------------
- In the Fixes section, replace the text between and including the <>
- with an issue number.
-
- "Do" examples:
- "fixes #2927"
- "fixes #2927, fixes #2928" (for multiple issues)
- "fixes #2927, fixes other_user/other_repo#2928"
-
- "Don't" examples:
- "fixes #<2927>"
- "fixes <#2927>
-
- See https://docs.github.com/en/enterprise/2.16/user/github/managing-your-work-on-github/closing-issues-using-keywords
--->
+#### Testing
+How was this tested? (at least one bullet point required)
+ • If unit tests were added, how do they cover this issue?
+ • If unit tests existed, how were they fixed/modified to prevent this in future?
+ • If integration tests were added, how do they verify this change?
+ • If manually tested, what platforms controller and device platforms were manually tested, and how?
+ • If no testing is required, why not?
