1. 贡献者指南
本文内容主要介绍，如何成为 minikube 的贡献者
1.1.1. 行为准则
善待彼此。
请参阅我们的 Kubernetes社区行为准则
1.1.2. 许可协议
我们很乐意接受你们的补丁！在我们可以使用它们之前，请填写个人或公司贡献者许可协议(CLA)
1.1.3. 找到需要解决的问题
- "good first issue" - 有明确的解决方法的问题
- "help wanted" - 我们已经确定需要但没有资源来解决的问题
"priority/important-soon" or "priority/important-longterm" - 需要在接下来的两个版本中解决的重大问题
如果你不确定，可以在 #minikube Slack 上询问
一旦你发现了需要解决的问题:
- 添加你计划解决这个问题的评论
- 提交一个解决该问题的 PR
- 用
/assign来评论这个问题，把它分配给你自己
1.1.4. clone minikube
在 fork minikube 分支后，您可以使用以下指导来 “clone” 最佳实践:
git clone git@github.com:kubernetes/minikube.git
cd minikube
git remote rename origin upstream
git remote set-url --push upstream NO_PUSH
git remote add origin git@github.com:<YOUR_GITHUB_USERNAME>/minikube.git
1.1.5. 贡献一个 Patch
- 提交一个 issue 描述您提议的变更的问题
- 审稿人会及时回复你的问题。
- 如果您提议的变更被接受，并且您还没有这样做，那么请签署贡献者许可协议(CLA)
- Fork minikube 代码库，开发并测试代码更改。
- 在测试前，你可能需要安装一些东西 prerequisites.
- 提交一个 PR（Pull Request）
1.2. 较大内容的贡献
对于有加大功能变动的的反馈，请使用 MEP(miniube 增强建议)模板创建包含您的想法的 PR 。通过这种方式，其他贡献者可以在早期就设计问题发表评论，但也欢迎您并行处理代码。
如果你在没有 MEP 的情况下发布了一个大的修改，准备好被其他贡献者要求包含在PR中。
1.2.1. 编码风格指南
对于代码，请参考 Kubernetes Coding Conventions
对于文档，清参考 Kubernetes Documentation Style Guide