github.com/SupersunnySea/draft@v0.16.0/CONTRIBUTING.md (about) 1 # Contributing 2 3 The Draft project accepts contributions via GitHub pull requests. This document outlines the process to help get your contribution accepted. 4 5 ## Reporting a Security Issue 6 7 Most of the time, when you find a bug in Draft, it should be reported using GitHub issues. However, if you are reporting a security vulnerability, please email a report to one of the [core maintainers][owners] directly. This will give the maintainers a chance to try to fix the issue before it is exploited in the wild. 8 9 ## Contributor License Agreements 10 11 We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles. 12 13 Community contributors to code repositories open sourced by Microsoft must sign the [Microsoft Contributor License Agreement][cla]. By signing a CLA, we ensure that the community is free to use your contributions. 14 15 Once you are CLA'ed, we'll be able to accept your pull requests. For any issues that you face during this process, please write a comment explaining the issue and we will help get it sorted out. 16 17 When you contribute to a Microsoft open source project on GitHub with a new pull request, a bot will evaluate whether you have signed the CLA. If required, the bot will comment on the pull request, including a link to the CLA system to accept the agreement. 18 19 ## Pull Requests 20 21 Like any good open source project, we use Pull Requests to track code changes. 22 23 PRs that are currently in progress are more than welcome. They are a great way to keep track of important work that is in-flight, but useful for others to see. If a PR is a work in progress, it must be prefaced with "WIP: [title]". Once the PR is ready for review, remove "WIP" from the title. 24 25 The maintainer in charge of triaging will apply the proper labels for the issue. This should include at least a category label (like `area/docs`), and a bug or feature label. This allows us to more efficiently triage the issue queue. 26 27 When reviewing pull requests, Draft uses a LGTM (Looks Good To Me!) policy. Because of the velocity of the project in its given state (pre-v1.0), the LGTM policy is as follows: 28 29 ### Pull Requests Submitted by Admirals 30 31 Small PRs submitted by an Admiral only requires a single LGTM from another Admiral or a Commodore. 32 This is because an Admiral is identified as an individual with significant experience with the 33 project, so it is assumed that smaller features have already been "signed off". 34 35 Larger PRs that alter behaviour significantly from what's in master needs to be signed off by two 36 Admirals or Commodores, but only one of them needs to review it. This is to ensure a proper transfer 37 of knowledge is passed on to other Admirals and Commodores, reducing overall 38 [bus factor][], while still ensuring the project can 39 continue at its current velocity. 40 41 The sign-off process is completely informal. A "full steam ahead!" on Slack is more than acceptable. 42 43 Scenario: there are two Admirals and a Commodore. Admiral "a" proposes a certain feature that alters 44 how Draft operates in a significant way. Admiral "b" and the Commodore both approve the proposal 45 (informally), and Admiral "b" reviews the pull request. 46 47 ### Pull Requests Submitted by Commodores 48 49 The same policy applied to Admirals also applies to Commodores. Commodores are seen in the same 50 light as Admirals when it comes to code contributions; they just have less overall responsibility to 51 maintain the project's direction and governance. 52 53 ### Pull Requests Submitted by the Community 54 55 All PRs, small or big, need to be signed off by two Admirals/Commodores and reviewed by one. 56 57 ### Merging PRs 58 59 PRs should stay open until merged or if they have not been active for more than 30 days. This will help keep the PR queue to a manageable size and reduce noise. Should the PR need to stay open (like in the case of a WIP), the `wip` label can be added. 60 61 If the owner of the PR is listed in OWNERS, that user may merge their own PRs or explicitly request another OWNER do that for them. 62 63 If the owner of a PR is not listed in OWNERS, any OWNER may merge the PR once it is approved. 64 65 ## Code of Conduct 66 67 This project has adopted the [Microsoft Open Source Code of Conduct][coc]. For more information see the [Code of Conduct FAQ][coc faq] or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments. 68 69 70 [bus factor]: https://en.wikipedia.org/wiki/Bus_factor 71 [cla]: https://cla.opensource.microsoft.com/ 72 [coc]: https://opensource.microsoft.com/codeofconduct/ 73 [coc faq]: https://opensource.microsoft.com/codeofconduct/faq/ 74 [owners]: OWNERS 75 [semver]: http://semver.org/