|
| 1 | +# How to Contribute |
| 2 | + |
| 3 | +The cluster-version operator is [Apache 2.0 licensed](LICENSE) and accepts contributions via GitHub pull requests. |
| 4 | +This document outlines some of the conventions on development workflow, commit message formatting, contact points and other resources to make it easier to get your contribution accepted. |
| 5 | + |
| 6 | +## Security Response |
| 7 | + |
| 8 | +If you've found a security issue that you'd like to disclose confidentially, please contact Red Hat's Product Security team. |
| 9 | +Details [here][security]. |
| 10 | + |
| 11 | +## Getting Started |
| 12 | + |
| 13 | +- Fork the repository on GitHub. |
| 14 | +- Read the [README](README.md) and [developer documentation](docs/dev) for build and test instructions. |
| 15 | +- Play with the project, submit bugs, submit patches! |
| 16 | + |
| 17 | +### Contribution Flow |
| 18 | + |
| 19 | +Anyone may [file issues][new-issue]. |
| 20 | +For contributors who want to work up pull requests, the workflow is roughly: |
| 21 | + |
| 22 | +1. Create a topic branch from where you want to base your work (usually master). |
| 23 | +2. Make commits of logical units. |
| 24 | +3. Make sure your commit messages are in the proper format (see [below](#commit-message-format)). |
| 25 | +4. If necessary, you may use `make update-codegen` to update generated code. |
| 26 | +5. Make sure the tests pass (`go test ./...`), and add any new tests as appropriate. |
| 27 | +6. Push your changes to a topic branch in your fork of the repository. |
| 28 | +7. Submit a pull request to the original repository. |
| 29 | +8. The [repo owners](OWNERS) will respond to your issue promptly, following [the ususal Prow workflow][prow-review]. |
| 30 | + |
| 31 | +Thanks for your contributions! |
| 32 | + |
| 33 | +## Coding Style |
| 34 | + |
| 35 | +The coding style suggested by the Golang community is used in installer. |
| 36 | +See the [style doc][golang-style] for details. |
| 37 | +Please follow them when working on your contributions. |
| 38 | +You may also `go fmt ./...` to have Go automatically format your . |
| 39 | + |
| 40 | +## Commit Message Format |
| 41 | + |
| 42 | +We follow a rough convention for commit messages that is designed to answer two questions: what changed and why. |
| 43 | +The subject line should feature the what and the body of the commit should describe the why. |
| 44 | + |
| 45 | +``` |
| 46 | +scripts: add the test-cluster command |
| 47 | +
|
| 48 | +this uses tmux to set up a test cluster that you can easily kill and |
| 49 | +start for debugging. |
| 50 | +
|
| 51 | +Fixes #38 |
| 52 | +``` |
| 53 | + |
| 54 | +The format can be described more formally as follows: |
| 55 | + |
| 56 | +``` |
| 57 | +<subsystem>: <what changed> |
| 58 | +<BLANK LINE> |
| 59 | +<why this change was made> |
| 60 | +<BLANK LINE> |
| 61 | +<footer> |
| 62 | +``` |
| 63 | + |
| 64 | +The first line is the subject and should be no longer than 70 characters, the second line is always blank, and other lines should be wrapped at 80 characters. |
| 65 | +This allows the message to be easier to read on GitHub as well as in various Git tools. |
| 66 | + |
| 67 | +[golang-style]: https://github.com/golang/go/wiki/CodeReviewComments |
| 68 | +[new-issue]: https://github.com/openshift/cluster-version-operator/issues/new |
| 69 | +[prow-review]: https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process |
| 70 | +[security]: https://access.redhat.com/security/team/contact |
0 commit comments