github.com/operator-framework/operator-lifecycle-manager@v0.30.0/CONTRIBUTING.md (about)

     1  # How to contribute
     2  
     3  Operator Lifecycle Manager (OLM) is an Apache 2.0 licensed project and accepts contributions via GitHub pull requests (PRs).
     4  
     5  This document outlines some of the conventions on commit message formatting, contact points for developers, and other resources to help get contributions into the OLM project.
     6  
     7  ## Communication
     8  
     9  - Email: [operator-framework@googlegroups.com][operator_framework]
    10  - Slack: [#olm-dev][olm-dev]
    11  - Working Group: [olm-wg][olm-wg]
    12  
    13  ## Getting started
    14  
    15  - Fork the repository on GitHub
    16  - See the [developer guide](./DEVELOPMENT.md) for build instructions
    17  - Read the [code of conduct](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/code-of-conduct.md)
    18  
    19  ## Reporting bugs and creating issues
    20  
    21  Reporting bugs is one of the best ways to contribute. However, a good bug report has some very specific qualities, so please read over our short document on [reporting bugs](./doc/dev/reporting_bugs.md) before submitting a bug report. Before filing a bug report, ensure the bug hasn't already been reported by searching through the OLM project [Issues][issues].
    22  
    23  Any new contribution should be accompanied by a new or existing issue. This issue can help track work, discuss the design and implementation, and help avoid wasted efforts or multiple people working on the same issue, compared to submitting a PR first. Trivial changes, like fixing a typo in the documentation, do not require the creation of a new issue.
    24  
    25  Proposing larger changes to the OLM project may require an enhancement be created in the [operator-framework/enhancements](https://github.com/operator-framework/enhancements/) repository. Enhancements are the primary mechanism for proposing new features to the OLM codebase. Any change to OLM's behavior or existing features, APIs, or architectural changes to the testing harness likely require an enhancement.
    26  
    27  ## Contribution flow
    28  
    29  This is a rough outline of what a contributor's workflow looks like:
    30  
    31  - Identify or create an issue.
    32  - Create a topic branch from where to base the contribution. This is usually the master branch.
    33  - Make commits of logical units.
    34  - Push changes in a topic branch to a personal fork of the repository.
    35  - Submit a pull request to the operator-framework/operator-lifecycle-manager repository.
    36  - Wait and respond to feedback from the maintainers listed in the OWNERS file.
    37  
    38  Thanks for contributing!
    39  
    40  ### Code Review
    41  
    42  Contributing PRs with a reasonable title and description can go a long way with helping ease the burden of the review process.
    43  
    44  It can be helpful after submitting a PR to self-review your changes. This allows you to communicate sections that reviewers should spend time combing over, asking for feedback on a particular implementation, or providing justification for a set of changes in-line ahead of time.
    45  
    46  When opening PRs that are in a rough draft or WIP state, prefix the PR description with `WIP: ...` or create a draft PR. This can help save reviewer's time by communicating the state of a PR ahead of time. Draft/WIP PRs can be a good way to get early feedback from reviewers on the implementation, focusing less on smaller details, and more on the general approach of changes.
    47  
    48  When contributing changes that require a new dependency, check whether it's feasible to directly vendor that code [without introducing a new dependency](https://go-proverbs.github.io/).
    49  
    50  Each PR must be labeled with at least one "lgtm" label and at least one "approved" label before it can be merged. Maintainers that have approval permissions are listed in the "approvers" column in the root [OWNERS][owners] file.
    51  
    52  ### Code style
    53  
    54  The coding style suggested by the Golang community is used throughout the OLM project:
    55  
    56  - CodeReviewComments <https://github.com/golang/go/wiki/CodeReviewComments>
    57  - EffectiveGo: <https://golang.org/doc/effective_go>
    58  
    59  In addition to the linked style documentation, OLM formats Golang packages using the [`gofmt`][gofmt] and [`goimports`][goimports] tooling. Before submitting a PR, please run `make lint` locally and commit the results. This will help expedite the review process, focusing less on style conflicts, and more on the design and implementation details.
    60  
    61  Please follow this style to make the OLM project easier to review, maintain and develop.
    62  
    63  ### Developer Certificate of Origin ([DCO][DCO])
    64  
    65  By contributing to this project you agree to the Developer Certificate of Origin (DCO).  This document was created by the Linux Kernl community and is a simple statement that you, as a contributor, have the legal right to make the contribution.  See the [DCO][dco] file for details.
    66  
    67  ## Documentation
    68  
    69  If the contribution changes the existing APIs or user interface it must include sufficient documentation to explain the use of the new or updated feature.
    70  
    71  The OLM documentation mainly lives in the [operator-framework/olm-docs][olm-docs] repository.
    72  
    73  [operator_framework]: <https://groups.google.com/forum/#!forum/operator-framework>
    74  [dco]: <https://developercertificate.org/>
    75  [owners]: <https://github.com/operator-framework/operator-lifecycle-manager/blob/master/OWNERS>
    76  [issues]: <https://github.com/operator-framework/operator-lifecycle-manager/issues>
    77  [olm-docs]: <https://github.com/operator-framework/olm-docs>
    78  [olm-dev]: <https://kubernetes.slack.com/archives/C0181L6JYQ2>
    79  [olm-wg]: <https://docs.google.com/document/d/1Zuv-BoNFSwj10_zXPfaS9LWUQUCak2c8l48d0-AhpBw/edit?usp=sharing>
    80  [sign-off]: <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff>
    81  [goimports]: <https://pkg.go.dev/golang.org/x/tools/cmd/goimports>
    82  [gofmt]: <https://pkg.go.dev/cmd/gofmt>