From d52c1fda65e0a249a5cffd4397e374c089d30320 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:56:02 -0400 Subject: [PATCH] Repo File Sync: synced file(s) with microsoft/mu_devops (#317) 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 --- .github/pull_request_template.md | 29 ++--------------- CONTRIBUTING.md | 53 +++++++++++++++++++++++++++++++- 2 files changed, 55 insertions(+), 27 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 0f216b6d50..60a2b7af1b 100644 --- a/.github/pull_request_template.md +++ b/.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 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c6ff888b87..dc0f5763ec 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