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