microsoft/mu_feature_ffa
Publicmirrored fromhttps://github.com/microsoft/mu_feature_ffaAvailable
CONTRIBUTING.md
102lines · modecode
| 1 | # Contributing to Project Mu |
| 2 | |
| 3 | Welcome, and thank you for your interest in contributing to Project Mu! |
| 4 | |
| 5 | There are many ways in which you can contribute, beyond writing code. The goal of this document is to provide a |
| 6 | high-level overview of how you can get involved. |
| 7 | |
| 8 | If this is your first time working with Project Mu, please keep in mind that many project details are maintained in |
| 9 | the [Project Mu Documentation](https://microsoft.github.io/mu/). |
| 10 | |
| 11 | ## Asking Questions |
| 12 | |
| 13 | Have a question? Rather than opening an issue, please post your question under the `Q&A` category in the `Discussions` |
| 14 | section of the relevant Project Mu GitHub repo. |
| 15 | |
| 16 | ## Reporting Issues |
| 17 | |
| 18 | Every Project Mu repo has an `Issues` section. Bug reports, feature requests, and documentation requests can all be |
| 19 | submitted in the issues section. |
| 20 | |
| 21 | ## Security Vulnerabilities |
| 22 | |
| 23 | Please review the repos `Security Policy` but in general every Project Mu repo has `Private vulnerability reporting` |
| 24 | enabled. Please use the security tab to report a potential issue. |
| 25 | |
| 26 | ### Identify Where to Report |
| 27 | |
| 28 | Project Mu is distributed across multiple repositories. Use features such as issues and discussions in the repository |
| 29 | most relevant to the topic. |
| 30 | |
| 31 | Although we prefer items to be filed in the most relevant repo, if you're unsure which repo is most relevant, the item |
| 32 | can be filed in the [Project Mu Documentation Repo](https://github.com/microsoft/mu) and we will review the request and |
| 33 | move it to the relevant repo if necessary. |
| 34 | |
| 35 | ### Look For an Existing Issue |
| 36 | |
| 37 | Before you create a new issue, please do a search in the issues section of the relevant repo to see if the issue or |
| 38 | feature request has already been filed. |
| 39 | |
| 40 | If you find your issue already exists, make relevant comments and add your |
| 41 | [reaction](https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments). Use a reaction in place |
| 42 | of a "+1" comment: |
| 43 | |
| 44 | * 👍 - upvote |
| 45 | * 👎 - downvote |
| 46 | |
| 47 | If you cannot find an existing issue that describes your bug or feature, create a new issue using the guidelines below. |
| 48 | |
| 49 | ### Follow Your Issue |
| 50 | |
| 51 | Please continue to follow your request after it is submitted to assist with any additional information that might be |
| 52 | requested. |
| 53 | |
| 54 | ### Pull Request Best Practices |
| 55 | |
| 56 | Pull requests for UEFI code can become large and difficult to review due to the large number of build and |
| 57 | configuration files. To aid maintainers in reviewing your code, we suggest adhering to the following guidelines: |
| 58 | |
| 59 | 1. Do keep code reviews single purpose; don't add more than one feature at a time. |
| 60 | 2. Do fix bugs independently of adding features. |
| 61 | 3. Do provide documentation and unit tests. |
| 62 | 4. Do introduce code in digestible amounts. |
| 63 | * If the contribution logically be broken up into separate pull requests that independently build and function |
| 64 | successfully, do use multiple pull requests. |
| 65 | |
| 66 | #### Code Categories |
| 67 | |
| 68 | To keep code digestible, you may consider breaking large pull requests into three categories of commits within the pull |
| 69 | request. |
| 70 | |
| 71 | 1. **Interfaces**: .h, .inf, .dec, documentation |
| 72 | 2. **Implementation**: .c, unit tests, unit test build file; unit tests should build and run at this point |
| 73 | 3. **Integration/Build**: .dec, .dsc, .fdf, (.yml) configuration files, integration tests; code added to platform and |
| 74 | affects downstream consumers |
| 75 | |
| 76 | By breaking the pull request into these three categories, the pull request reviewers can digest each piece |
| 77 | independently. |
| 78 | |
| 79 | If your commits are still very large after adhering to these categories, consider further breaking the pull request |
| 80 | down by library/driver; break each component into its own commit. |
| 81 | |
| 82 | #### Implementation Limits |
| 83 | |
| 84 | Implementation is ultimately composed of functions as logical units of code. |
| 85 | |
| 86 | To help maintainers review the code and improve long-term maintainability, limit functions to 60 lines of code. If your |
| 87 | function exceeds 60 lines of code, it likely has also exceeded a single responsibility and should be broken up. |
| 88 | |
| 89 | Files are easier to review and maintain if they contain functions that serves similar purpose. Limit files to around |
| 90 | 1,000 lines of code (excluding comments). If your file exceeds 1,000 lines of code, it may have functions that should |
| 91 | be split into separate files. |
| 92 | |
| 93 | --- |
| 94 | |
| 95 | By following these guidelines, your pull requests will be reviewed faster, and you'll avoid being asked to refactor the |
| 96 | code to follow the guidelines. |
| 97 | |
| 98 | Feel free to create a draft pull request and ask for suggestions on how to split the pull request if you are unsure. |
| 99 | |
| 100 | ## Thank You |
| 101 | |
| 102 | Thank you for your interest in Project Mu and taking the time to contribute! |
| 103 | |