Repo File Sync: synced file(s) with microsoft/mu_devops

.github/pull_request_template.md

@@ -1,41 +1,18 @@
-# Preface
-
-Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior
-to submitting the pull request. In particular,
-[pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices).
-
 ## Description
 
-<_Please include a description of the change and why this change was made._>
+<_Include a description of the change and why this change was made._>
 
-For each item, place an "x" in between `[` and `]` if true. Example: `[x]`.
-_(you can also check items in the GitHub UI)_
+For details on how to complete to complete these options and their meaning refer to [CONTRIBUTING.md](https://github.com/microsoft/mu/blob/HEAD/CONTRIBUTING.md).
 
 - [ ] Impacts functionality?
-  - **Functionality** - Does the change ultimately impact how firmware functions?
-  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
 - [ ] Impacts security?
-  - **Security** - Does the change have a direct security impact on an application,
-    flow, or firmware?
-  - Examples: Crypto algorithm change, buffer overflow fix, parameter
-    validation improvement, ...
 - [ ] Breaking change?
-  - **Breaking change** - Will anyone consuming this change experience a break
-    in build or boot behavior?
-  - Examples: Add a new library class, move a module to a different repo, call
-    a function in a new library class in a pre-existing module, ...
 - [ ] Includes tests?
-  - **Tests** - Does the change include any explicit test code?
-  - Examples: Unit tests, integration tests, robot tests, ...
 - [ ] Includes documentation?
-  - **Documentation** - Does the change contain explicit documentation additions
-    outside direct code modifications (and comments)?
-  - Examples: Update readme file, add feature readme file, link to documentation
-    on an a separate Web page, ...
 
 ## How This Was Tested
 
-<_Please describe the test(s) that were run to verify the changes._>
+<_Describe the test(s) that were run to verify the changes._>
 
 ## Integration Instructions
 

CONTRIBUTING.md

@@ -21,7 +21,7 @@ submitted in the issues section.
 ## Security Vulnerabilities
 
 Please review the repos `Security Policy` but in general every Project Mu repo has `Private vulnerability reporting`
-enabled.  Please use the security tab to report a potential issue.  
+enabled.  Please use the security tab to report a potential issue.
 
 ### Identify Where to Report
 
@@ -63,6 +63,57 @@ configuration files. To aid maintainers in reviewing your code, we suggest adher
    * If the contribution logically be broken up into separate pull requests that independently build and function
      successfully, do use multiple pull requests.
 
+#### Pull Request Description Checkboxes
+
+Project Mu pull requests autopopulate a PR description from a template in most repositories. You should:
+
+1. **Replace** this text with an actual descrption:
+
+   ```txt
+   <_Include a description of the change and why this change was made._>
+   ```
+
+2. **Remove** this line of instructions so the PR description shows cleanly in release notes:
+
+   `"For details on how to complete to complete these options and their meaning refer to [CONTRIBUTING.md](https://github.com/microsoft/mu/blob/HEAD/CONTRIBUTING.md)."`
+
+3. For each checkbox in the PR description, **place an "x"** in between `[` and `]` if true. Example: `[x]`.
+   _(you can also check items in the GitHub UI)_
+
+   * **[] Impacts functionality?**
+     * **Functionality** - Does the change ultimately impact how firmware functions?
+     * Examples: Add a new library, publish a new PPI, update an algorithm, ...
+   * **[] Impacts security?**
+     * **Security** - Does the change have a direct security impact on an application,
+       flow, or firmware?
+     * Examples: Crypto algorithm change, buffer overflow fix, parameter
+       validation improvement, ...
+   * **[] Breaking change?**
+     * **Breaking change** - Will anyone consuming this change experience a break
+       in build or boot behavior?
+     * Examples: Add a new library class, move a module to a different repo, call
+       a function in a new library class in a pre-existing module, ...
+   * [] **Includes tests?**
+     * **Tests** - Does the change include any explicit test code?
+     * Examples: Unit tests, integration tests, robot tests, ...
+   * [] **Includes documentation?**
+     * **Documentation** - Does the change contain explicit documentation additions
+       outside direct code modifications (and comments)?
+     * Examples: Update readme file, add feature readme file, link to documentation
+      on an a separate Web page, ...
+
+4. **Replace** this text as instructed:
+
+   ```txt
+   <_Describe the test(s) that were run to verify the changes._>
+   ```
+
+5. **Replace** this text as instructed:
+
+   ```txt
+   <_Describe how these changes should be integrated. Use N/A if nothing is required._>
+   ```
+
 #### Code Categories
 
 To keep code digestible, you may consider breaking large pull requests into three categories of commits within the pull