kyverno/CONTRIBUTING.md

Contributing to Kyverno

• Introduction
• Contributing Code
• Disclosing vulnerabilities
• Code Style
• Pull request procedure
• Communication
• Conduct

Introduction

Please note: We take Kyverno security and our users' trust very seriously. If you believe you have found a security issue in Kyverno, please responsibly disclose by contacting us at support@nirmata.com.

First: if you're unsure or afraid of anything, just ask or submit the issue or pull request anyways. You won't be yelled at for giving it your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions, and don't want a wall of rules to get in the way of that.

That said, if you want to ensure that a pull request is likely to be merged, talk to us! You can find out our thoughts and ensure that your contribution won't clash or be obviated by Kyverno normal direction. A great way to do this is via the Kyverno Community

Contributing Code

Unless you are fixing a known bug, we strongly recommend discussing it with the core team via a GitHub issue or in our chat before getting started to ensure your work is consistent with Kyverno roadmap and architecture.

All contributions are made via pull request. Note that all patches from all contributors get reviewed. After a pull request is made other contributors will offer feedback, and if the patch passes review a maintainer will accept it with a comment. When pull requests fail testing, authors are expected to update their pull requests to address the failures until the tests pass and the pull request merges successfully.

At least one review from a maintainer is required for all patches (even patches from maintainers).

Reviewers should leave a "LGTM" comment once they are satisfied with the patch. If the patch was submitted by a maintainer with write access, the pull request should be merged by the submitter after review.

Disclosing vulnerabilities

Please disclose vulnerabilities exclusively to support@nirmata.com. Do not use GitHub issues.

Code Style

We follow the community provided standard code structure. Please follow these guidelines when formatting source code:

• Go code should match the output of gofmt -s

Pull request procedure

To make a pull request, you will need a GitHub account; if you are unclear on this process, see GitHub's documentation on forking and pull requests. Pull requests should be targeted at the master branch. Before creating a pull request, go through this checklist:

1. Create a feature branch off of master so that changes do not get mixed up.
2. Rebase your local changes against the master branch.
3. Run the full project test suite with the go test ./... (or equivalent) command and confirm that it passes.
4. Run gofmt -s (if the project is written in Go).
5. Ensure that each commit has a subsystem prefix (ex: controller:).

Pull requests will be treated as "review requests," and maintainers will give feedback on the style and substance of the patch.

Normally, all pull requests must include tests that test your change. Occasionally, a change will be very difficult to test for. In those cases, please include a note in your commit message explaining why.

Communication

We use Slack. You are welcome to drop in and ask questions, discuss bugs, etc.