Kubernetes 贡献者入门指南从零开始参与社区开发的完整路线图【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本文是 Kubernetes 社区仓库community中 contributors/guide/README.md 的深度解读。它面向所有想要参与 Kubernetes 开发的开发者系统梳理了从注册 GitHub 账号、签署 CLA到理解社区角色、加入 SIG、提交第一个 PR 的完整路径。读完本文你将掌握参与 Kubernetes 开发所需的全部前置步骤、社区沟通渠道与协作规范并能基于仓库内的实际文件如 OWNERS、OWNERS_ALIASES、community-membership.md理解背后的自动化机制。Welcome这份指南是什么你是否想过为云原生领域最核心的开源项目贡献代码Kubernetes 社区仓库 中的这份贡献者指南Contributor Guide正是为此而生。它帮助新贡献者理解 Kubernetes 项目的整体组织方式并指引你找到最佳的上手路径认领 issue、编写代码修复问题、提交 PR 并通过评审被合入主线。官方明确表示这份文档是如何向 Kubernetes 代码库贡献的唯一权威来源single source of truth。社区欢迎任何人浏览 [open issues] 并提出新问题所有反馈都会被认真对待。当前仓库正是这一指南的实际载体你可以直接在本仓库中浏览对应文档contributors/guide/README.md。Contributor Guide建议按顺序阅读的章节Kubernetes 官方建议新贡献者按以下顺序走完整个指南每一步都建立在前一步的基础上Welcome本文所在页面—— 了解项目整体与入门路径Prerequisites前置条件—— 在开始贡献前必须完成的准备工作Your First Contribution —— 第一次贡献前需要知道的事Contributing —— 贡献 Kubernetes 的主要参考指南。此外contributor cheatsheet若有位于contributors/guide/contributor-cheatsheet/提供了一页速查的贡献者资源索引适合作为日常查阅的手册。Prerequisites提交代码前的四项准备在向 Kubernetes 提交代码之前必须先完成以下前置条件。这些步骤会在你第一次提交时由机器人自动检查提前完成会让首次贡献顺利得多。对应仓库根目录的 CLA.md、code-of-conduct.md、values.md 等文件给出了完整细节。创建 GitHub 账号一切开始之前你需要先注册一个 GitHub 用户账号。这是后续提交 PR、被机器人自动检查身份的账户基础。签署 CLA贡献者许可协议Kubernetes只接受已签署 CLA 的原创源代码。根据仓库根目录的 CLA.mdCloud Native Computing FoundationCNCF定义了两种类型的贡献者许可协议Individual Contributor个人贡献者以个人身份贡献Corporate Contributor企业贡献者代表雇主或其他组织贡献。需要注意的是该政策不适用于third_party和vendor目录下的第三方依赖代码。签署 CLA 的最简单方式是向kubernetes-sigs/contributor-playground仓库提交一个练习性质的 PR。提交 PR 时请按照提供的模板填写描述。EasyCLA 签署流程共六步来自 CLA.md创建你的第一个 PR 后linux-foundation-easycla机器人会在 PR 中回复你的 CLA 状态与签署链接。若以企业贡献者身份签署请确保已将企业邮箱关联到 GitHub 账号不要求是主邮箱否则可能导致 CLA 系统校验失败点击 Please click here to be authorized 链接跳转到 GitHub 授权页并点击 Authorize LF-Engineering授权 Linux Foundation 只读读取你 GitHub 账号关联的邮箱列表授权完成后页面会要求你选择贡献者类型Individual Contributor以个人身份或 Corporate Contributor代表组织选择类型后通过 DocuSign 完成签署流程点击 Finish 后会自动跳转回你的 PR留意邮箱中来自 EasyCLA 的成功通知邮件可下载已签署的 CLA 的 PDF回到 PR在评论区回复/easycla以更新该 PR 的 CLA 状态。如果更换雇主还需要在cncf/gitdm仓库中更新你的开发者归属信息affiliation格式如下Jorge O. Castro*: jorge!heptio.com, jorge!ubuntu.com, jorge.castro!gmail.com Heptio Canonical until 2017-03-31若签署过程中遇到问题可通过 EasyCLA 机器人响应中的支持链接提交工单或使用备用邮箱联系 CNCF。仓库管理员如需为自己的仓库配置 CNCF CLA 检查可参考 github-management/setting-up-cla-check.md。遵守行为准则与社区价值观请务必阅读并遵守 Code of Conduct 与 Community Values。Kubernetes 是一个社区项目其健康发展完全依赖社区成员共同营造高效、友好、协作的环境。行为准则适用于社区所有的沟通平台见 communication/README.md。搭建开发环境官方明确说明仅参与社区贡献如文档、issue 等并不强制要求搭建开发环境。但如果你计划提交代码修改请查阅 developer resources 页面了解如何配置环境。其中包含本地开发、编码与调试的完整指引contributors/devel/目录下还按 SIG 细分了开发文档如 development.md、running-locally.md。理解社区期望与角色Kubernetes 高度依赖社区请提前了解协作中的代码与评审期望以及各类贡献者角色的职责阅读 Community Expectations理解代码与评审期望例如所有活跃参与者都被期望同时成为活跃的评审者评审者reviewer应对活跃 PR 及时响应若长时间不可用应设置 GitHub 状态为 busy 以阻止机器人自动指派长期不可用则应将自己从 OWNERS 文件中移除并提名继任者活跃 PR 指带有cla:yes标签且无需 rebase 即可合并的 PR查看 Community Membership 了解各角色的职责清单并鼓励随着经验积累逐步向上攀登贡献者阶梯。community-membership.md 中定义了四个核心角色及其定义方式角色职责定义方式Member社区中的活跃贡献者Kubernetes GitHub 组织成员Reviewer评审其他成员的贡献OWNERS 文件 reviewers 条目Approver接受贡献的审批人OWNERS 文件 approvers 条目Subproject owner为子项目设定方向与优先级sigs.yaml 子项目对应的 OWNERS 文件 owners 条目例如成为Member的基本要求包括开启 GitHub 双重认证、在 CNCF gitdm 中保持账号归属信息最新、做出多次能体现持续长期承诺的贡献至少有一个已合入的 PR、订阅devkubernetes.io邮件列表、阅读本贡献者指南、由 2 位 reviewer 推荐且两位 sponsor 必须来自不同公司以体现跨社区整合最终在kubernetes/org仓库提交 membership 申请 issue 并让 sponsor 回复1。Kubernetes Contributor Playground安全的练习场如果你希望在一个安全的环境中熟悉 Kubernetes 的 PR 与 issue 评审流程Kubernetes Contributor Playground 是最合适的去处。它不仅是 CLA 注册的渠道更是一个练习提交第一个 PR 的仓库——正如 contributors/guide/README.md 所强调的提交新 PR 时请按照模板撰写描述。此外New Contributor Workshop 的视频大纲可以在本仓库的 events/2019/11-contributor-summit 目录中找到配套的 YouTube 视频合辑对新手极具参考价值。Community加入 Kubernetes 社区Kubernetes 是一个庞大、活跃、友好的开源社区。如同许多开源项目一样它的持续发展依赖源源不断的新成员加入并成为常规代码贡献者。请考虑加入 Kubernetes并沿着贡献者阶梯稳步向上。沟通渠道社区遵循统一的沟通政策详见 communication/README.md。该文档列出了上游贡献者的沟通平台与资源包括按社区组尤其是各 SIG组织的邮件列表、Slack 频道、Zoom 会议、会议议程/纪要等。所有平台都受 code-of-conduct.md 约束并明确禁止未经请求的商业内容如 Slack 上的广告式私信、会议中的产品推销但允许在合适频道提问商业产品使用问题。官方决策信息主要沉淀在kubernetes-dev邮件列表、各关联仓库的 GitHub Issues/PRs 以及 KEPKubernetes Enhancement Proposals中。事件与峰会Kubernetes 每年在中国、欧洲、北美举办三次 KubeCon CloudNativeCon 峰会CNCF 官网提供了这些社区事件的详细信息。仓库中 events/ 目录记录了历年 Contributor Summit 的历史资料可供回顾。Meetups所有 Kubernetes Meetup 均遵循 Cloud Native Computing Foundation 的社区组Community Groups指南你也可以通过邮箱联系 CNCF 负责社区组项目的员工咨询相关问题。导师计划Mentorship想获得更有经验的社区成员一对一指导请阅读 mentoring/README.md 了解 Kubernetes 的导师计划。仓库 mentoring/ 目录下还包含新贡献者导向new-contributor-orientation、流程processes与各类项目programs的详细材料。进阶主题OWNERS 文件与自动化进阶主题面向需要深入理解仓库治理机制的贡献者。Kubernetes 组织通过OWNERS 文件管理代码归属每个包含独立代码或内容单元unit of independent code的目录都可以包含一个OWNERS文件它作用于该目录下的所有内容包括自身、同级文件与子目录。OWNERS 文件是项目两阶段代码评审流程的实现机制受 Chromium OWNERS 启发也启发了 GitHub 的 CODEOWNERS。详细规范见 contributors/guide/owners.md其核心语法如下approvers: - alice - bob # this is a comment reviewers: - carol - david # this is another comment - sig-foo # this is an alias关键字段approvers可以使用/approve命令的 GitHub 用户名或别名列表reviewers适合/lgtm一个 PR 的候选人列表labels自动应用到 PR 的 GitHub 标签列表emeritus_approvers曾经是 approvers、但不再活跃审批的成员被 Prow 忽略分配但可被查阅咨询options.no_parent_owners默认为false为true时排除父目录 OWNERS 文件的影响filters键为 Go 正则表达式、值为简单 OWNERS 配置的映射正则匹配相对于该 OWNERS 文件的路径。一旦使用filtersapprovers/reviewers/labels等必须定义在filters内只有options例外例如filters: .*: labels: - re/all \\.go$: labels: - re/go本仓库根目录的 OWNERS 就是一个真实示例——它通过filters对annual-report-.*\.md$文件自动打上area/annual-reports标签对charter.md指定了required_reviewerssteering-committee与committee/steering标签。而 OWNERS_ALIASES 定义了sig-*-leads等别名组alias用别名替代 GitHub Teams是因为 Teams 的变更无法公开审计。两阶段评审流程owners.md 中的简化描述Phase 0 自动化作者提交 PR 后自动化Blunderbuss 插件根据变更代码最近的 OWNERS 文件推荐至少 2 位 reviewer并为每个 OWNERS 文件推荐一位 approver 写入评论Phase 1 人工评审reviewer 关注代码质量、正确性、工程风格满意则评论/lgtm改主意则/lgtm cancel。Prow 机器人据此打上lgtm标签Phase 2 人工审批作者/assign所有建议的 approver只有相关 OWNERS 文件中列出直接或通过别名的人才能/approve全部 approver 批准后 Prow 打上approved标签Phase 3 自动化合并当所需标签齐全如lgtm、approved、无阻塞标签如do-not-merge/hold、needs-rebase且预提交 Prow 任务通过后PR 被自动合并。该流程由 Prow 生态实现Tide 负责批量测试与合并、Blunderbuss 插件负责推荐 reviewer、assign/approve/lgtm 插件负责响应/assign、/approve、/lgtm命令repoowners包负责解析 OWNERS 与 OWNERS_ALIAS 文件。迈出第一步你的首次贡献完成前置条件后first-contribution.md 会带你找到第一个可贡献的方向找到要做的事改进文档、澄清可重命名的代码/变量/函数、编写测试、帮助 issue 分类triage都是很好的起点也可以在带good first issue标签的 issue 中寻找任务该标签意味着 Kubernetes 成员承诺为新贡献者提供额外协助认领 issue在 issue 下回复/assign或/assign yourselfk8s-ci-robot 会自动把 issue 分配给你你的名字会出现在 Assignees 列表了解 SIGKubernetes 社区按 Special Interest GroupsSIGs组织以改进工作流。SIG 是开放社区任何人都可以加入修复 issue、评论设计提案、评审代码且 SIG 有对所有人开放的定期视频会议、Slack 频道与会议纪要。可通过 sig-list.md 查阅全部 SIG 的联系信息例如提交 CNIContainer Networking Interface相关 issue 时在评论中回复/sig network即可打上 Network SIG 标签SIG 专属贡献指南部分 SIG 在社区目录下有专属的CONTRIBUTING.md如 sig-apps/CONTRIBUTING.md、sig-cli/CONTRIBUTING.md、sig-multicluster/CONTRIBUTING.md、sig-node/CONTRIBUTING.md、sig-storage/CONTRIBUTING.md、sig-windows/CONTRIBUTING.md提交 issue尚未准备好写代码但发现了问题请在合适的子仓库提交 issue如文档问题提交到 kubernetes/website并遵循提示的提交规范详见 issue-triage.md。深入贡献主指南与 GitHub 工作流当你要正式提交代码时contributing.md 是主参考文档。其要点包括PR 的 Kubernetes 特色Kubernetes 遵循标准的 GitHub PR 流程但增加了一层 Kubernetes 特有甚至 SIG 特有的差异——机器人会自动给 PR 打结构化标签并在评论中提示可用的/command命令用于自动打标签与通知新贡献者常见问题首个 PR 前未正确签署 CLA找不到正确的 SIG/reviewerPR 上出现与改动无关的测试失败flaky tests未遵循 scalability-good-practices.md在 commit message 中写了mentions或fixes #xxxx等关键字这些应放在 PR 描述而非提交信息中评审建议遵循 coding-conventions.md写出清晰有意义的提交信息把大的改动拆分成逻辑上独立、易于理解的小补丁PR 关注度不够时可在 Slack 的#pr-reviews频道求助测试类型单元测试UnitGo 原生 testing 包与被测代码同目录、集成测试Integration覆盖组件间或与 etcd 等外部资源的交互、端到端测试e2e需要完整集群见 e2e-tests.md、一致性测试Conformance由 SIG Architecture 批准定义所有发行版必须支持的核心特性集。CI 会以预提交/后提交方式运行这些测试结果展示在 testgrid 上相关自动化由 sig-testing 与 test-infra 仓库维护Issue 管理与分类Triage通过为 GitHub issue 添加多种描述性标签加速问题路由详见 issue-triage.md。动手前请参考 github-workflow.md 的完整流程在云端 forkkubernetes/kubernetes→ clone 到本地并添加upstreamremote并设置git remote set-url --push upstream no_push防止误推上游→ 基于upstream/master创建工作分支myfeature→ 用git fetch upstream git rebase upstream/master保持分支同步避免使用git pull产生多余的 merge commit→ 提交时保持 commit 清晰易懂。下图直观展示了这一流程结语从注册账号、签署 CLA到加入 SIG、完成第一个 PRKubernetes 的贡献体系环环相扣。这份入门指南contributors/guide/README.md是整个流程的起点配合 first-contribution.md、contributing.md、community-membership.md 与 OWNERS 治理机制你已经拥有了一条完整的、可执行的上手路径。社区的强大来自每一位成员——欢迎加入 Kubernetes【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes 贡献者入门指南：从零开始参与社区开发的完整路线图
Kubernetes 贡献者入门指南从零开始参与社区开发的完整路线图【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本文是 Kubernetes 社区仓库community中 contributors/guide/README.md 的深度解读。它面向所有想要参与 Kubernetes 开发的开发者系统梳理了从注册 GitHub 账号、签署 CLA到理解社区角色、加入 SIG、提交第一个 PR 的完整路径。读完本文你将掌握参与 Kubernetes 开发所需的全部前置步骤、社区沟通渠道与协作规范并能基于仓库内的实际文件如 OWNERS、OWNERS_ALIASES、community-membership.md理解背后的自动化机制。Welcome这份指南是什么你是否想过为云原生领域最核心的开源项目贡献代码Kubernetes 社区仓库 中的这份贡献者指南Contributor Guide正是为此而生。它帮助新贡献者理解 Kubernetes 项目的整体组织方式并指引你找到最佳的上手路径认领 issue、编写代码修复问题、提交 PR 并通过评审被合入主线。官方明确表示这份文档是如何向 Kubernetes 代码库贡献的唯一权威来源single source of truth。社区欢迎任何人浏览 [open issues] 并提出新问题所有反馈都会被认真对待。当前仓库正是这一指南的实际载体你可以直接在本仓库中浏览对应文档contributors/guide/README.md。Contributor Guide建议按顺序阅读的章节Kubernetes 官方建议新贡献者按以下顺序走完整个指南每一步都建立在前一步的基础上Welcome本文所在页面—— 了解项目整体与入门路径Prerequisites前置条件—— 在开始贡献前必须完成的准备工作Your First Contribution —— 第一次贡献前需要知道的事Contributing —— 贡献 Kubernetes 的主要参考指南。此外contributor cheatsheet若有位于contributors/guide/contributor-cheatsheet/提供了一页速查的贡献者资源索引适合作为日常查阅的手册。Prerequisites提交代码前的四项准备在向 Kubernetes 提交代码之前必须先完成以下前置条件。这些步骤会在你第一次提交时由机器人自动检查提前完成会让首次贡献顺利得多。对应仓库根目录的 CLA.md、code-of-conduct.md、values.md 等文件给出了完整细节。创建 GitHub 账号一切开始之前你需要先注册一个 GitHub 用户账号。这是后续提交 PR、被机器人自动检查身份的账户基础。签署 CLA贡献者许可协议Kubernetes只接受已签署 CLA 的原创源代码。根据仓库根目录的 CLA.mdCloud Native Computing FoundationCNCF定义了两种类型的贡献者许可协议Individual Contributor个人贡献者以个人身份贡献Corporate Contributor企业贡献者代表雇主或其他组织贡献。需要注意的是该政策不适用于third_party和vendor目录下的第三方依赖代码。签署 CLA 的最简单方式是向kubernetes-sigs/contributor-playground仓库提交一个练习性质的 PR。提交 PR 时请按照提供的模板填写描述。EasyCLA 签署流程共六步来自 CLA.md创建你的第一个 PR 后linux-foundation-easycla机器人会在 PR 中回复你的 CLA 状态与签署链接。若以企业贡献者身份签署请确保已将企业邮箱关联到 GitHub 账号不要求是主邮箱否则可能导致 CLA 系统校验失败点击 Please click here to be authorized 链接跳转到 GitHub 授权页并点击 Authorize LF-Engineering授权 Linux Foundation 只读读取你 GitHub 账号关联的邮箱列表授权完成后页面会要求你选择贡献者类型Individual Contributor以个人身份或 Corporate Contributor代表组织选择类型后通过 DocuSign 完成签署流程点击 Finish 后会自动跳转回你的 PR留意邮箱中来自 EasyCLA 的成功通知邮件可下载已签署的 CLA 的 PDF回到 PR在评论区回复/easycla以更新该 PR 的 CLA 状态。如果更换雇主还需要在cncf/gitdm仓库中更新你的开发者归属信息affiliation格式如下Jorge O. Castro*: jorge!heptio.com, jorge!ubuntu.com, jorge.castro!gmail.com Heptio Canonical until 2017-03-31若签署过程中遇到问题可通过 EasyCLA 机器人响应中的支持链接提交工单或使用备用邮箱联系 CNCF。仓库管理员如需为自己的仓库配置 CNCF CLA 检查可参考 github-management/setting-up-cla-check.md。遵守行为准则与社区价值观请务必阅读并遵守 Code of Conduct 与 Community Values。Kubernetes 是一个社区项目其健康发展完全依赖社区成员共同营造高效、友好、协作的环境。行为准则适用于社区所有的沟通平台见 communication/README.md。搭建开发环境官方明确说明仅参与社区贡献如文档、issue 等并不强制要求搭建开发环境。但如果你计划提交代码修改请查阅 developer resources 页面了解如何配置环境。其中包含本地开发、编码与调试的完整指引contributors/devel/目录下还按 SIG 细分了开发文档如 development.md、running-locally.md。理解社区期望与角色Kubernetes 高度依赖社区请提前了解协作中的代码与评审期望以及各类贡献者角色的职责阅读 Community Expectations理解代码与评审期望例如所有活跃参与者都被期望同时成为活跃的评审者评审者reviewer应对活跃 PR 及时响应若长时间不可用应设置 GitHub 状态为 busy 以阻止机器人自动指派长期不可用则应将自己从 OWNERS 文件中移除并提名继任者活跃 PR 指带有cla:yes标签且无需 rebase 即可合并的 PR查看 Community Membership 了解各角色的职责清单并鼓励随着经验积累逐步向上攀登贡献者阶梯。community-membership.md 中定义了四个核心角色及其定义方式角色职责定义方式Member社区中的活跃贡献者Kubernetes GitHub 组织成员Reviewer评审其他成员的贡献OWNERS 文件 reviewers 条目Approver接受贡献的审批人OWNERS 文件 approvers 条目Subproject owner为子项目设定方向与优先级sigs.yaml 子项目对应的 OWNERS 文件 owners 条目例如成为Member的基本要求包括开启 GitHub 双重认证、在 CNCF gitdm 中保持账号归属信息最新、做出多次能体现持续长期承诺的贡献至少有一个已合入的 PR、订阅devkubernetes.io邮件列表、阅读本贡献者指南、由 2 位 reviewer 推荐且两位 sponsor 必须来自不同公司以体现跨社区整合最终在kubernetes/org仓库提交 membership 申请 issue 并让 sponsor 回复1。Kubernetes Contributor Playground安全的练习场如果你希望在一个安全的环境中熟悉 Kubernetes 的 PR 与 issue 评审流程Kubernetes Contributor Playground 是最合适的去处。它不仅是 CLA 注册的渠道更是一个练习提交第一个 PR 的仓库——正如 contributors/guide/README.md 所强调的提交新 PR 时请按照模板撰写描述。此外New Contributor Workshop 的视频大纲可以在本仓库的 events/2019/11-contributor-summit 目录中找到配套的 YouTube 视频合辑对新手极具参考价值。Community加入 Kubernetes 社区Kubernetes 是一个庞大、活跃、友好的开源社区。如同许多开源项目一样它的持续发展依赖源源不断的新成员加入并成为常规代码贡献者。请考虑加入 Kubernetes并沿着贡献者阶梯稳步向上。沟通渠道社区遵循统一的沟通政策详见 communication/README.md。该文档列出了上游贡献者的沟通平台与资源包括按社区组尤其是各 SIG组织的邮件列表、Slack 频道、Zoom 会议、会议议程/纪要等。所有平台都受 code-of-conduct.md 约束并明确禁止未经请求的商业内容如 Slack 上的广告式私信、会议中的产品推销但允许在合适频道提问商业产品使用问题。官方决策信息主要沉淀在kubernetes-dev邮件列表、各关联仓库的 GitHub Issues/PRs 以及 KEPKubernetes Enhancement Proposals中。事件与峰会Kubernetes 每年在中国、欧洲、北美举办三次 KubeCon CloudNativeCon 峰会CNCF 官网提供了这些社区事件的详细信息。仓库中 events/ 目录记录了历年 Contributor Summit 的历史资料可供回顾。Meetups所有 Kubernetes Meetup 均遵循 Cloud Native Computing Foundation 的社区组Community Groups指南你也可以通过邮箱联系 CNCF 负责社区组项目的员工咨询相关问题。导师计划Mentorship想获得更有经验的社区成员一对一指导请阅读 mentoring/README.md 了解 Kubernetes 的导师计划。仓库 mentoring/ 目录下还包含新贡献者导向new-contributor-orientation、流程processes与各类项目programs的详细材料。进阶主题OWNERS 文件与自动化进阶主题面向需要深入理解仓库治理机制的贡献者。Kubernetes 组织通过OWNERS 文件管理代码归属每个包含独立代码或内容单元unit of independent code的目录都可以包含一个OWNERS文件它作用于该目录下的所有内容包括自身、同级文件与子目录。OWNERS 文件是项目两阶段代码评审流程的实现机制受 Chromium OWNERS 启发也启发了 GitHub 的 CODEOWNERS。详细规范见 contributors/guide/owners.md其核心语法如下approvers: - alice - bob # this is a comment reviewers: - carol - david # this is another comment - sig-foo # this is an alias关键字段approvers可以使用/approve命令的 GitHub 用户名或别名列表reviewers适合/lgtm一个 PR 的候选人列表labels自动应用到 PR 的 GitHub 标签列表emeritus_approvers曾经是 approvers、但不再活跃审批的成员被 Prow 忽略分配但可被查阅咨询options.no_parent_owners默认为false为true时排除父目录 OWNERS 文件的影响filters键为 Go 正则表达式、值为简单 OWNERS 配置的映射正则匹配相对于该 OWNERS 文件的路径。一旦使用filtersapprovers/reviewers/labels等必须定义在filters内只有options例外例如filters: .*: labels: - re/all \\.go$: labels: - re/go本仓库根目录的 OWNERS 就是一个真实示例——它通过filters对annual-report-.*\.md$文件自动打上area/annual-reports标签对charter.md指定了required_reviewerssteering-committee与committee/steering标签。而 OWNERS_ALIASES 定义了sig-*-leads等别名组alias用别名替代 GitHub Teams是因为 Teams 的变更无法公开审计。两阶段评审流程owners.md 中的简化描述Phase 0 自动化作者提交 PR 后自动化Blunderbuss 插件根据变更代码最近的 OWNERS 文件推荐至少 2 位 reviewer并为每个 OWNERS 文件推荐一位 approver 写入评论Phase 1 人工评审reviewer 关注代码质量、正确性、工程风格满意则评论/lgtm改主意则/lgtm cancel。Prow 机器人据此打上lgtm标签Phase 2 人工审批作者/assign所有建议的 approver只有相关 OWNERS 文件中列出直接或通过别名的人才能/approve全部 approver 批准后 Prow 打上approved标签Phase 3 自动化合并当所需标签齐全如lgtm、approved、无阻塞标签如do-not-merge/hold、needs-rebase且预提交 Prow 任务通过后PR 被自动合并。该流程由 Prow 生态实现Tide 负责批量测试与合并、Blunderbuss 插件负责推荐 reviewer、assign/approve/lgtm 插件负责响应/assign、/approve、/lgtm命令repoowners包负责解析 OWNERS 与 OWNERS_ALIAS 文件。迈出第一步你的首次贡献完成前置条件后first-contribution.md 会带你找到第一个可贡献的方向找到要做的事改进文档、澄清可重命名的代码/变量/函数、编写测试、帮助 issue 分类triage都是很好的起点也可以在带good first issue标签的 issue 中寻找任务该标签意味着 Kubernetes 成员承诺为新贡献者提供额外协助认领 issue在 issue 下回复/assign或/assign yourselfk8s-ci-robot 会自动把 issue 分配给你你的名字会出现在 Assignees 列表了解 SIGKubernetes 社区按 Special Interest GroupsSIGs组织以改进工作流。SIG 是开放社区任何人都可以加入修复 issue、评论设计提案、评审代码且 SIG 有对所有人开放的定期视频会议、Slack 频道与会议纪要。可通过 sig-list.md 查阅全部 SIG 的联系信息例如提交 CNIContainer Networking Interface相关 issue 时在评论中回复/sig network即可打上 Network SIG 标签SIG 专属贡献指南部分 SIG 在社区目录下有专属的CONTRIBUTING.md如 sig-apps/CONTRIBUTING.md、sig-cli/CONTRIBUTING.md、sig-multicluster/CONTRIBUTING.md、sig-node/CONTRIBUTING.md、sig-storage/CONTRIBUTING.md、sig-windows/CONTRIBUTING.md提交 issue尚未准备好写代码但发现了问题请在合适的子仓库提交 issue如文档问题提交到 kubernetes/website并遵循提示的提交规范详见 issue-triage.md。深入贡献主指南与 GitHub 工作流当你要正式提交代码时contributing.md 是主参考文档。其要点包括PR 的 Kubernetes 特色Kubernetes 遵循标准的 GitHub PR 流程但增加了一层 Kubernetes 特有甚至 SIG 特有的差异——机器人会自动给 PR 打结构化标签并在评论中提示可用的/command命令用于自动打标签与通知新贡献者常见问题首个 PR 前未正确签署 CLA找不到正确的 SIG/reviewerPR 上出现与改动无关的测试失败flaky tests未遵循 scalability-good-practices.md在 commit message 中写了mentions或fixes #xxxx等关键字这些应放在 PR 描述而非提交信息中评审建议遵循 coding-conventions.md写出清晰有意义的提交信息把大的改动拆分成逻辑上独立、易于理解的小补丁PR 关注度不够时可在 Slack 的#pr-reviews频道求助测试类型单元测试UnitGo 原生 testing 包与被测代码同目录、集成测试Integration覆盖组件间或与 etcd 等外部资源的交互、端到端测试e2e需要完整集群见 e2e-tests.md、一致性测试Conformance由 SIG Architecture 批准定义所有发行版必须支持的核心特性集。CI 会以预提交/后提交方式运行这些测试结果展示在 testgrid 上相关自动化由 sig-testing 与 test-infra 仓库维护Issue 管理与分类Triage通过为 GitHub issue 添加多种描述性标签加速问题路由详见 issue-triage.md。动手前请参考 github-workflow.md 的完整流程在云端 forkkubernetes/kubernetes→ clone 到本地并添加upstreamremote并设置git remote set-url --push upstream no_push防止误推上游→ 基于upstream/master创建工作分支myfeature→ 用git fetch upstream git rebase upstream/master保持分支同步避免使用git pull产生多余的 merge commit→ 提交时保持 commit 清晰易懂。下图直观展示了这一流程结语从注册账号、签署 CLA到加入 SIG、完成第一个 PRKubernetes 的贡献体系环环相扣。这份入门指南contributors/guide/README.md是整个流程的起点配合 first-contribution.md、contributing.md、community-membership.md 与 OWNERS 治理机制你已经拥有了一条完整的、可执行的上手路径。社区的强大来自每一位成员——欢迎加入 Kubernetes【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考