Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests. Please see the CLA guidelines for more info
- Submit an issue describing your proposed change to the repo in question.
- The repo owners will respond to your issue promptly.
- If your proposed change is accepted, and you haven't already done so, sign a Contributor License Agreement (see details above).
- Fork the desired repo, develop and test your code changes.
- Submit a pull request.
- All code PR must be labeled with one of
⚠️ (:warning:, major or breaking changes)- ✨ (:sparkles:, feature additions)
- 🐛 (:bug:, patch and bugfixes)
- 📖 (:book:, documentation or proposals)
- 🌱 (:seedling:, minor or other)
- All code PR must be labeled with one of
We broadly follow the requirements from the Kubernetes Community Membership.
When making changes to OWNER_ALIASES please check that the sig-cluster-lifecycle-leads, cluster-api-admins and cluster-api-maintainers are correct.
If you would like to become a reviewer, then please ask one of the current maintainers.
We generally try to follow the requirements for a reviewer from upstream Kubernetes. But if you feel that you don't fully meet the requirements then reach out to us, they are not set in stone.
A reviewer can get PRs automatically assigned for review, and can /lgtm PRs.
To become a reviewer, ensure you are a member of the kubernetes-sigs Github organisation following kubernetes/org/issues/new/choose.
The steps to add someone as a reviewer are:
- Add the GitHub alias to the cluster-api-vsphere-reviewers section of OWNERS_ALIASES
- Create a PR with the change that is held (i.e. by using
/hold) - Announce the change within the CAPV slack channel and as a PSA in the next CAPV office hours
- After 7 days of lazy consensus or after the next CAPV office hours (whichever is longer) the PR can be merged
If you have made significant contributions to Cluster API Provider vSphere, a maintainer may nominate you to become a maintainer for the project.
We generally follow the requirements for a approver from upstream Kubernetes. However, if you don't fully meet the requirements then a quorum of maintainers may still propose you if they feel you will make significant contributions.
Maintainers are able to approve PRs, as well as participate in release processes and have write access to the repo. As a maintainer you will be expected to run the office hours, especially if no one else wants to.
Maintainers require membership of the Kubernetes Github organisation via kubernetes/org/issues/new/choose
The steps to add someone as a maintainer are:
- Add the GitHub alias to the cluster-api-vsphere-maintainers and remove them from cluster-api-vsphere-reviewers sections of OWNERS_ALIASES
- Create a PR with the change that is held (i.e. by using
/hold) - Announce the change within the CAPV slack channel and as a PSA in the next CAPV office hours
- After 7 days of lazy consensus or after the next CAPV office hours (whichever is longer) the PR can be merged
- Open PR to add Github username to cluster-api-provider-vsphere-maintainers to kubernetes/org/config/kubernetes-sigs/sig-cluster-lifecycle/teams.yaml
- Open PR to add Github username to kubernetes/test-infra/config/jobs/kubernetes-sigs/cluster-api-provider-vsphere/OWNERS
- Open PR to add Google ID to the [email protected] and [email protected] Google groups in kubernetes/k8s.io/groups/sig-cluster-lifecycle/groups.yaml
- Open PR to add approvers/reviewers to CAPV image promotion.
- Open PR to image-builder to modify
cluster-api-vsphere-maintainersin OWNERS_ALIASES
After a period of time one of the existing CAPV or CAPI admins may propose you to become an admin of the CAPV project.
Admins have GitHub admin access to perform tasks on the repo.
The steps to add someone as an admin are:
- Open PR to add Github username to cluster-api-provider-vsphere-admins to kubernetes/org/config/kubernetes-sigs/sig-cluster-lifecycle/teams.yaml