|
| 1 | +# How to Contribute |
| 2 | + |
| 3 | +Metal3 projects are [Apache 2.0 licensed](LICENSE) and accept contributions via |
| 4 | +GitHub pull requests. Those guidelines are the same as the |
| 5 | +[Cluster API guidelines](https://github.com/kubernetes-sigs/cluster-api/blob/master/CONTRIBUTING.md) |
| 6 | + |
| 7 | +<!-- START doctoc generated TOC please keep comment here to allow auto update --> |
| 8 | +<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> |
| 9 | + |
| 10 | +- [Certificate of Origin](#certificate-of-origin) |
| 11 | +- [Finding Things That Need Help](#finding-things-that-need-help) |
| 12 | +- [Contributing a Patch](#contributing-a-patch) |
| 13 | +- [Backporting a Patch](#backporting-a-patch) |
| 14 | + - [Merge Approval](#merge-approval) |
| 15 | + - [Google Doc Viewing Permissions](#google-doc-viewing-permissions) |
| 16 | + - [Issue and Pull Request Management](#issue-and-pull-request-management) |
| 17 | + |
| 18 | +<!-- END doctoc generated TOC please keep comment here to allow auto update --> |
| 19 | + |
| 20 | +## Certificate of Origin |
| 21 | + |
| 22 | +By contributing to this project you agree to the Developer Certificate of |
| 23 | +Origin (DCO). This document was created by the Linux Kernel community and is a |
| 24 | +simple statement that you, as a contributor, have the legal right to make the |
| 25 | +contribution. See the [DCO](DCO) file for details. |
| 26 | + |
| 27 | +## Finding Things That Need Help |
| 28 | + |
| 29 | +If you're new to the project and want to help, but don't know where to start, we |
| 30 | +have a semi-curated list of issues that |
| 31 | +should not need deep knowledge of the system. [Have a look and see if anything |
| 32 | +sounds interesting](https://github.com/metal3-io/cluster-api-provider-metal3/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22). |
| 33 | +Alternatively, read some of the docs on other controllers and try to write your |
| 34 | +own, file and fix any/all issues that come up, including gaps in documentation! |
| 35 | + |
| 36 | +## Contributing a Patch |
| 37 | + |
| 38 | +1. If you haven't already done so, sign a Contributor License Agreement (see |
| 39 | + details above). |
| 40 | +1. Fork the desired repo, develop and test your code changes. |
| 41 | +1. Submit a pull request. |
| 42 | + |
| 43 | +All code PR must be labeled with one of |
| 44 | + |
| 45 | +- ⚠️ (:warning:, major or breaking changes) |
| 46 | +- ✨ (:sparkles:, minor or feature additions) |
| 47 | +- 🐛 (:bug:, patch and bugfixes) |
| 48 | +- 📖 (:book:, documentation or proposals) |
| 49 | +- 🏃 (:running:, other) |
| 50 | + |
| 51 | +All changes must be code reviewed. Coding conventions and standards are |
| 52 | +explained in the official [developer |
| 53 | +docs](https://github.com/kubernetes/community/tree/master/contributors/devel). |
| 54 | +Expect reviewers to request that you |
| 55 | +avoid common [go style |
| 56 | +mistakes](https://github.com/golang/go/wiki/CodeReviewComments) in your PRs. |
| 57 | + |
| 58 | +## Backporting a Patch |
| 59 | + |
| 60 | +Cluster API maintains older versions through `release-X.Y` branches. We accept |
| 61 | +backports of bug fixes to the most recent |
| 62 | +release branch. For example, if the most recent branch is `release-0.2`, and the |
| 63 | +`master` branch is under active |
| 64 | +development for v0.3.0, a bug fix that merged to `master` that also affects |
| 65 | +`v0.2.x` may be considered for backporting |
| 66 | +to `release-0.2`. We generally do not accept PRs against older release branches. |
| 67 | + |
| 68 | +## Breaking Changes |
| 69 | + |
| 70 | +Breaking changes are generally allowed in the `master` branch, as this is the |
| 71 | +branch used to develop the next minor release of Cluster API. |
| 72 | + |
| 73 | +There may be times, however, when `master` is closed for breaking changes. This |
| 74 | +is likely to happen as we near the release of a new minor version. |
| 75 | + |
| 76 | +Breaking changes are not allowed in release branches, as these represent minor |
| 77 | +versions that have already been released. |
| 78 | +These versions have consumers who expect the APIs, behaviors, etc. to remain |
| 79 | +stable during the life time of the patch stream for the minor release. |
| 80 | + |
| 81 | +Examples of breaking changes include: |
| 82 | + |
| 83 | +- Removing or renaming a field in a CRD |
| 84 | +- Removing or renaming a CRD |
| 85 | +- Removing or renaming an exported constant, variable, type, or function |
| 86 | +- Updating the version of critical libraries such as controller-runtime, |
| 87 | + client-go, apimachinery, etc. |
| 88 | +- Some version updates may be acceptable, for picking up bug fixes, but |
| 89 | + maintainers must exercise caution when reviewing. |
| 90 | + |
| 91 | +There may, at times, need to be exceptions where breaking changes are allowed in |
| 92 | +release branches. These are at the discretion of the project's maintainers, and |
| 93 | +must be carefully considered before merging. An example of an allowed |
| 94 | +breaking change might be a fix for a behavioral bug that was released in an |
| 95 | +initial minor version (such as `v0.3.0`). |
| 96 | + |
| 97 | +### Merge Approval |
| 98 | + |
| 99 | +Please see the [Kubernetes community document on pull |
| 100 | +requests](https://git.k8s.io/community/contributors/guide/pull-requests.md) for |
| 101 | +more information about the merge process. |
| 102 | + |
| 103 | +### Google Doc Viewing Permissions |
| 104 | + |
| 105 | +To gain viewing permissions to google docs in this project, please join the |
| 106 | +[metal3-dev](https://groups.google.com/forum/#!forum/metal3-dev) google |
| 107 | +group. |
| 108 | + |
| 109 | +### Issue and Pull Request Management |
| 110 | + |
| 111 | +Anyone may comment on issues and submit reviews for pull requests. However, in |
| 112 | +order to be assigned an issue or pull request, you must be a member of the |
| 113 | +[Metal3-io organization](https://github.com/metal3-io) GitHub organization. |
| 114 | + |
| 115 | +Metal3 maintainers can assign you an issue or pull request by leaving a |
| 116 | +`/assign <your Github ID>` comment on the issue or pull request. |
0 commit comments