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

synced local file(s) with
[microsoft/mu_devops](https://github.com/microsoft/mu_devops).

🤖: View the [Repo File Sync Configuration
File](https://github.com/microsoft/mu_devops/blob/main/.sync/Files.yml)
to see how files are synced.



---

This PR was created automatically by the
[repo-file-sync-action](https://github.com/BetaHuhn/repo-file-sync-action)
workflow run
[#10316616855](https://github.com/microsoft/mu_devops/actions/runs/10316616855)

Signed-off-by: Project Mu UEFI Bot <[email protected]>

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