Code of Conduct
Be excellent to each another. Please refer to our Kubernetes Community Code of Conduct.
We’d love to accept your patches! Before we can take them, please fill out either the individual or corporate Contributor License Agreement (CLA)
Finding issues to work on
“good first issue” - issues where there is a clear path to resolution
“help wanted” - issues where we’ve identified a need but not resources to work on them
Ask on the #minikube Slack if you aren’t sure
Once you’ve discovered an issue to work on:
- Add a comment mentioning that you plan to work on the issue
- Send a PR out that mentions the issue
- Comment on the issue with
/assignto assign it to yourself
After forking minikube you can
clone for best practices use the following instruction:
git clone firstname.lastname@example.org:kubernetes/minikube.git cd minikube git remote rename origin upstream git remote set-url --push upstream NO_PUSH git remote add origin email@example.com:<YOUR_GITHUB_USERNAME>/minikube.git
Contributing A Patch
- Submit an issue describing your proposed change
- A reviewer will respond to your issue promptly.
- If your proposed change is accepted, and you haven’t already done so, sign the Contributor License Agreement (CLA)
- Fork the minikube repository, develop and test your code changes.
- Before test, you may need to install some prerequisites.
- Submit a pull request.
Contributing larger changes
To get feedback on a larger, more ambitious changes, create a PR containing your idea using the MEP (minikube enhancement proposal) template. This way other contributors can comment on design issues early on, though you are welcome to work on the code in parallel.
If you send out a large change without a MEP, prepare to be asked by other contributors for one to be included within the PR.
For coding, refer to the Kubernetes Coding Conventions
For documentation, refer to the Kubernetes Documentation Style Guide