github.com/rohankumardubey/draft-classic@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/