github.com/newrelic/newrelic-client-go@v1.1.0/CONTRIBUTING.md (about)

     1  # Contributing
     2  
     3  Contributions are always welcome. Before contributing please read the
     4  [code of conduct](CODE_OF_CONDUCT.md) and [search the issue tracker](../../issues); your issue may have already been discussed or fixed in `main`. To contribute,
     5  [fork](https://help.github.com/articles/fork-a-repo/) this repository, commit your changes, and [send a Pull Request](https://help.github.com/articles/using-pull-requests/).
     6  
     7  Note that our [code of conduct](CODE_OF_CONDUCT.md) applies to all platforms and venues related to this project; please follow it in all your interactions with the project and its participants.
     8  
     9  ## Feature Requests
    10  
    11  Feature requests should be submitted in the [Issue tracker](../../issues), with a description of the expected behavior & use case, where they’ll remain closed until sufficient interest, [e.g. :+1: reactions](https://help.github.com/articles/about-discussions-in-issues-and-pull-requests/), has been [shown by the community](issues?q=label%3A%22votes+needed%22+sort%3Areactions-%2B1-desc).
    12  Before submitting an Issue, please search for similar ones in the
    13  [closed issues](issues?q=is%3Aissue+is%3Aclosed+label%3Aenhancement).
    14  
    15  ## Commit messages
    16  
    17  To keep a style and allow us to automate the generating of a change log, we
    18  require that that commit messages adhere to a standard.
    19  
    20  TL;DR The commit message must match this regular expression.
    21  
    22      (chore|docs|feat|fix|refactor|tests?)(\([^\)]+\))?: .*
    23  
    24  For more information on commit messages, we mostly follow [this standard][conventional_commits].
    25  
    26  ## Pull Requests
    27  
    28  1. Ensure any install or build dependencies are removed before the end of the layer when doing a build.
    29  2. Increase the version numbers in any examples files and the README.md to the new version that this Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/).
    30  3. You may merge the Pull Request in once you have the sign-off of two other developers, or if you do not have permission to do that, you may request the second reviewer to merge it for you.
    31  
    32  ## Contributor License Agreement
    33  
    34  Keep in mind that when you submit your Pull Request, you'll need to sign the CLA via the click-through using CLA-Assistant. If you'd like to execute our corporate CLA, or if you have any questions, please drop us an email at opensource@newrelic.com.
    35  
    36  For more information about CLAs, please check out Alex Russell’s excellent post,
    37  [“Why Do I Need to Sign This?”](https://infrequently.org/2008/06/why-do-i-need-to-sign-this/).
    38  
    39  # Slack
    40  
    41  For contributors and maintainers of open source projects hosted by New Relic, we host a public Slack with a channel dedicated to this project. If you are contributing to this project, you're welcome to request access to that community space.