From 1ba4c37e7c4d22b41e2d92630f8566503b347de3 Mon Sep 17 00:00:00 2001 From: "Project Mu UEFI Bot [bot]" <45776386+uefibot@users.noreply.github.com> Date: Fri, 9 Aug 2024 11:55:28 -0400 Subject: [PATCH] Repo File Sync: synced file(s) with microsoft/mu_devops (#202) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- CONTRIBUTING.md | 53 ++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c6ff888b8..dc0f5763e 100644 --- a/CONTRIBUTING.md +++ b/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