Contributor Guide

Code of Conduct

Be excellent to each other. Please refer to our Kubernetes Community Code of Conduct.

License Agreement

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
"priority/important-soon" or "priority/important-longterm" - high impact issues that need to be addressed in the next couple of releases.
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 /assign to assign it to yourself

clone `minikube`

After forking minikube you can clone for best practices use the following instruction:

bash

git clone [email protected]:kubernetes/minikube.git
cd minikube
git remote rename origin upstream
git remote set-url --push upstream NO_PUSH
git remote add origin [email protected]:<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.

Style Guides

For coding, refer to the Kubernetes Coding Conventions

For documentation, refer to the Kubernetes Documentation Style Guide