Kubernetes 社区 GitHub 管理请求指南如何正确提出 Issue 与 PR 并完成升级【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇指南以 Kubernetes 社区仓库中 github-management/opening-a-request.md 为核心骨架系统讲解在 Kubernetes 项目中遇到权限、组织成员、Webhook、仓库创建/迁移/归档、Bot 自动化等问题时应如何选择正确的处理渠道、提交 Issue 或 PR并在请求紧急时通过kubernetes/owners、test-infra on-call 与 Slack 频道完成升级。读完本文你将掌握一套可直接对照执行的问题分类、提交与升级速查流程并理解其背后由 GitHub Administration Team、peribolos、Prow 等机制构成的自动化治理体系。一、文档定位什么场景下需要开一个请求Kubernetes 项目在 GitHub 上拥有kubernetes、kubernetes-sigs、kubernetes-client、kubernetes-csi、kubernetes-security、kubernetes-retired、kubernetes-nightly等多个组织详见 github-management/README.md日常运维涉及组织成员管理、权限分配、仓库生命周期、自动化机器人等大量事务。由于这些操作大多需要组织级权限普通贡献者无法直接执行因此社区约定了一套统一的请求入口根据问题类型在指定仓库提交 Issue 或 PR而不是直接联系管理员或私下处理。Kubernetes 项目将 GitHub 管理请求划分为三类对应三条截然不同的处理路径请求类型处理渠道紧急升级渠道权限、组织成员、集成、仓库生命周期等配置类问题在kubernetes/org仓库开 Issuekubernetes/owners或 Slack#github-management团队创建 / 加成员 / 重命名对kubernetes/org仓库提交 PR同上Bot 配置、自动合并、Issue 打标等自动化问题在kubernetes/test-infra仓库开 Issuetest-infra on-call 或 Slack#testing-ops敏感信息邮件至私有列表githubkubernetes.io—下面逐一展开。二、配置类问题在 kubernetes/org 仓库开 Issue如果你需要以下任一方面帮助请对kubernetes/org仓库提交一个描述你问题的 Issue提交入口由该仓库的 issue 模板提供权限问题Permissions issues组织成员资格Organization membership第三方集成Third-party integrationsWebhooks仓库创建 / 迁移Repository creation/migration仓库归档Repository archivalProject Board 创建Project Board creation其他仓库与配置问题提交 Issue 时应完整描述请求背景、涉及的组织/仓库/团队名称以及期望的结果便于 GitHub Administration Team 快速评估。紧急情况的升级路径如果请求是紧急的请升级处理在 Issue 中 提及[kubernetes/owners]团队该团队由 GitHub Administration Team 成员组成详见 github-management/README.md或在 Slack 的#github-management频道中联系。值得说明的是kubernetes/org仓库不仅是 Issue 的接收地也是整个 GitHub 配置的事实来源团队成员列表、仓库权限、组织设置都由该仓库中的 YAML 配置定义再经 peribolos 等工具自动应用到 GitHub详见下文背后的自动化机制。三、团队管理类请求对 kubernetes/org 提交 PR与开 Issue不同创建新团队、向团队添加成员、重命名团队这三类操作必须通过对kubernetes/org仓库提交 PR 来完成且应遵循 github-management/org-owners-guide.md 中的团队指导规范Team Guidance。这与 Issue 流程的本质区别在于团队成员变更属于对仓库配置的代码级修改需要经过评审Review与批准Approval而不是一次性的支持请求。团队命名规范按照 Team Guidance每个组织应包含以下团队以仓库foo为例foo-admins授予foo仓库的 admin 权限foo-maintainers授予foo仓库的 write 权限foo-reviewers授予foo仓库的 read 权限用作感兴趣的/活跃贡献者的通知机制bots包含k8s-ci-robot、thelinuxfoundation等组织与仓库自动化所需的机器人账号owners由所有拥有组织 owner 权限的人组成方便以团队为单位集中 提及时不用逐个搜索成员。注意当前并非所有组织都完全遵循该模型社区正逐步向这一模型收敛foo-reviewers团队被视为kubernetes-sig-foo-pr-reviews团队的历史子集理想情况下应尽量使用 OWNERS 文件替代此类团队。创建与重命名团队的操作细节重命名团队在团队的配置中添加previously: 旧团队名字段并将name改为新名称创建团队除kubernetes/owners团队成员外新成员必须加入团队的members列表由于 GitHub API 的工作方式kubernetes/owners成员必须加入maintainers列表团队的privacy必须为closed。审批要求新团队创建或成员添加的 PR 必须得到相关OWNERS或 SIG 负责人的批准。例如向foo-maintainers添加成员必须由仓库foo的OWNERS或该仓库所属 SIG 的负责人批准github-management/org-owners-guide.md。关于成员加入组织的完整前置条件如开启 2FA、加入 k-dev 邮件列表、列出活跃贡献与子项目、双 sponsor 且 sponsor 需来自不同公司等可参考 github-management/new-membership-procedure.md。四、Bot / 自动化类问题在 kubernetes/test-infra 仓库开 Issue如果你的问题属于以下范畴请对kubernetes/test-infra仓库开 Issue 描述问题Bot 配置Bot configuration自动合并Automatic mergingIssue 打标Issue labelling自动化反馈与功能请求Automation feedback and feature requests这类请求与配置类请求分开管理是因为自动化系统由不同的团队与不同的 on-call 机制负责。若请求紧急请升级到test-infra on-call值班入口见https://go.k8s.io/oncall或在 Slack 的#testing-ops频道中联系。相关自动化工具概览Kubernetes 的 GitHub 管理自动化主要基于 Prow 体系sigs.k8s.io/prow其中与 GitHub 管理强相关的工具包括peribolos基于定义的 YAML 配置管理 GitHub 组织与团队成员branchprotector跨组织强制执行分支保护设置label_sync基于定义的 YAML 配置在组织范围内增删改标签。这些工具在 github-management/README.md 中有完整说明。当你在kubernetes/test-infra中提交自动化相关问题例如 bot 命令失效、标签不同步、自动合并异常时处理者会借助上述工具链定位并修复问题。五、敏感问题的上报渠道如果涉及敏感信息Sensitive issues不要在任何公开 Issue 或 Slack 频道中透露请直接发送邮件至私有列表githubkubernetes.io。该渠道用于处理不适合公开讨论的安全、隐私或保密性相关事项。六、请求时效SLO与升级机制了解处理时效有助于你判断何时该升级。GitHub Administration Team 承诺按以下时限处理请求github-management/org-owners-guide.md组织邀请满足所有成员条件即获得全部 1后一周内处理仓库创建或迁移Issue 打开后 72 小时内响应若需补充信息或满足特定要求则在全部要求满足后 72 小时内创建仓库安全或审核请求尽可能立即处理且需保证跨时区、跨国家的覆盖其他所有请求Issue 打开后一周内响应具体解决时间视请求内容而定。如果请求超出上述时限或有紧急需求请在关联 Issue 中 提及[kubernetes/owners]寻求协助。这与 github-management/opening-a-request.md 中的升级路径完全一致构成提交 → 等待 → 超时升级的完整闭环。七、背后的治理机制谁在处理这些请求理解处理方有助于你写出更高效的请求。这些流程由Contributor Experience SIG 下属的 GitHub Management 子项目负责制定与维护github-management/subproject-responsibilities.md其职责包括制定组织成员、组织权限、仓库创建/管理等常规 GitHub 管理任务的政策与标准建立Org Owner权限策略制定 bot 账号、服务账号、webhook 与第三方集成的策略以及组建负责具体执行的GitHub Administration Team。GitHub Administration Team 成员即kubernetes/owners团队持有所有活跃 Kubernetes 组织的 Org Owner 权限负责依据政策执行各类 GitHub 管理任务github-management/README.md。该团队的提名来自 Contributor Experience SIG并需经 Steering Committee 确认成员选择时会考虑时区与国家分布以确保北美工作时间之外和节假日也有足够覆盖。从权限模型看github-management/permissions.mdGitHub 原生的组织级权限只有 owner / member 两级仓库级只有 admin / write / read 三级粒度粗糙且非全即无。Kubernetes 通过自动化bot 命令、OWNERS 文件门控审批、自动化合并规避这些限制将大部分操作交由机器执行而需要人工介入的高频例外操作就通过本文所述的 Issue/PR 渠道流转——这正是开一个请求流程存在的根本原因。八、请求处理速查提交前对照清单提交请求前请先对照以下清单确认渠道无误可显著加快处理速度问题是否属于配置类权限 / 成员 / 集成 / Webhook / 仓库创建迁移归档 / Project Board→ 对kubernetes/org开 Issue问题是否属于团队变更创建团队 / 添加成员 / 重命名团队→ 对kubernetes/org提交 PR并确保满足 github-management/org-owners-guide.md 的命名、privacy: closed、审批要求问题是否属于自动化类Bot 配置 / 自动合并 / 打标→ 对kubernetes/test-infra开 Issue是否包含敏感信息→ 邮件至githubkubernetes.io切勿公开发布是否紧急 / 是否超时→ 在 Issue 中 kubernetes/owners或在#github-management、#testing-opsSlack 频道中联系对应团队。提示仓库创建 / 迁移类请求在 Issue 获批后后续的团队与权限分配仍需按 Team Guidance 提交 PR并由 peribolos 在 postsubmit 中自动创建团队并分配访问权限仓库最终还需要加入 sigs.yaml 中的对应子项目详见 github-management/org-owners-guide.md 与 github-management/kubernetes-repositories.md。因此一个完整的仓库创建请求往往包含Issue 审批 PR 配置两个阶段请预留足够时间。通过遵循上述分类与渠道规则你可以让自己的请求被 GitHub Administration Team、GitHub Management 子项目或 test-infra 团队正确接收并及时处理避免因渠道错投而延误。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes 社区 GitHub 管理请求指南：如何正确提出 Issue 与 PR 并完成升级
Kubernetes 社区 GitHub 管理请求指南如何正确提出 Issue 与 PR 并完成升级【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇指南以 Kubernetes 社区仓库中 github-management/opening-a-request.md 为核心骨架系统讲解在 Kubernetes 项目中遇到权限、组织成员、Webhook、仓库创建/迁移/归档、Bot 自动化等问题时应如何选择正确的处理渠道、提交 Issue 或 PR并在请求紧急时通过kubernetes/owners、test-infra on-call 与 Slack 频道完成升级。读完本文你将掌握一套可直接对照执行的问题分类、提交与升级速查流程并理解其背后由 GitHub Administration Team、peribolos、Prow 等机制构成的自动化治理体系。一、文档定位什么场景下需要开一个请求Kubernetes 项目在 GitHub 上拥有kubernetes、kubernetes-sigs、kubernetes-client、kubernetes-csi、kubernetes-security、kubernetes-retired、kubernetes-nightly等多个组织详见 github-management/README.md日常运维涉及组织成员管理、权限分配、仓库生命周期、自动化机器人等大量事务。由于这些操作大多需要组织级权限普通贡献者无法直接执行因此社区约定了一套统一的请求入口根据问题类型在指定仓库提交 Issue 或 PR而不是直接联系管理员或私下处理。Kubernetes 项目将 GitHub 管理请求划分为三类对应三条截然不同的处理路径请求类型处理渠道紧急升级渠道权限、组织成员、集成、仓库生命周期等配置类问题在kubernetes/org仓库开 Issuekubernetes/owners或 Slack#github-management团队创建 / 加成员 / 重命名对kubernetes/org仓库提交 PR同上Bot 配置、自动合并、Issue 打标等自动化问题在kubernetes/test-infra仓库开 Issuetest-infra on-call 或 Slack#testing-ops敏感信息邮件至私有列表githubkubernetes.io—下面逐一展开。二、配置类问题在 kubernetes/org 仓库开 Issue如果你需要以下任一方面帮助请对kubernetes/org仓库提交一个描述你问题的 Issue提交入口由该仓库的 issue 模板提供权限问题Permissions issues组织成员资格Organization membership第三方集成Third-party integrationsWebhooks仓库创建 / 迁移Repository creation/migration仓库归档Repository archivalProject Board 创建Project Board creation其他仓库与配置问题提交 Issue 时应完整描述请求背景、涉及的组织/仓库/团队名称以及期望的结果便于 GitHub Administration Team 快速评估。紧急情况的升级路径如果请求是紧急的请升级处理在 Issue 中 提及[kubernetes/owners]团队该团队由 GitHub Administration Team 成员组成详见 github-management/README.md或在 Slack 的#github-management频道中联系。值得说明的是kubernetes/org仓库不仅是 Issue 的接收地也是整个 GitHub 配置的事实来源团队成员列表、仓库权限、组织设置都由该仓库中的 YAML 配置定义再经 peribolos 等工具自动应用到 GitHub详见下文背后的自动化机制。三、团队管理类请求对 kubernetes/org 提交 PR与开 Issue不同创建新团队、向团队添加成员、重命名团队这三类操作必须通过对kubernetes/org仓库提交 PR 来完成且应遵循 github-management/org-owners-guide.md 中的团队指导规范Team Guidance。这与 Issue 流程的本质区别在于团队成员变更属于对仓库配置的代码级修改需要经过评审Review与批准Approval而不是一次性的支持请求。团队命名规范按照 Team Guidance每个组织应包含以下团队以仓库foo为例foo-admins授予foo仓库的 admin 权限foo-maintainers授予foo仓库的 write 权限foo-reviewers授予foo仓库的 read 权限用作感兴趣的/活跃贡献者的通知机制bots包含k8s-ci-robot、thelinuxfoundation等组织与仓库自动化所需的机器人账号owners由所有拥有组织 owner 权限的人组成方便以团队为单位集中 提及时不用逐个搜索成员。注意当前并非所有组织都完全遵循该模型社区正逐步向这一模型收敛foo-reviewers团队被视为kubernetes-sig-foo-pr-reviews团队的历史子集理想情况下应尽量使用 OWNERS 文件替代此类团队。创建与重命名团队的操作细节重命名团队在团队的配置中添加previously: 旧团队名字段并将name改为新名称创建团队除kubernetes/owners团队成员外新成员必须加入团队的members列表由于 GitHub API 的工作方式kubernetes/owners成员必须加入maintainers列表团队的privacy必须为closed。审批要求新团队创建或成员添加的 PR 必须得到相关OWNERS或 SIG 负责人的批准。例如向foo-maintainers添加成员必须由仓库foo的OWNERS或该仓库所属 SIG 的负责人批准github-management/org-owners-guide.md。关于成员加入组织的完整前置条件如开启 2FA、加入 k-dev 邮件列表、列出活跃贡献与子项目、双 sponsor 且 sponsor 需来自不同公司等可参考 github-management/new-membership-procedure.md。四、Bot / 自动化类问题在 kubernetes/test-infra 仓库开 Issue如果你的问题属于以下范畴请对kubernetes/test-infra仓库开 Issue 描述问题Bot 配置Bot configuration自动合并Automatic mergingIssue 打标Issue labelling自动化反馈与功能请求Automation feedback and feature requests这类请求与配置类请求分开管理是因为自动化系统由不同的团队与不同的 on-call 机制负责。若请求紧急请升级到test-infra on-call值班入口见https://go.k8s.io/oncall或在 Slack 的#testing-ops频道中联系。相关自动化工具概览Kubernetes 的 GitHub 管理自动化主要基于 Prow 体系sigs.k8s.io/prow其中与 GitHub 管理强相关的工具包括peribolos基于定义的 YAML 配置管理 GitHub 组织与团队成员branchprotector跨组织强制执行分支保护设置label_sync基于定义的 YAML 配置在组织范围内增删改标签。这些工具在 github-management/README.md 中有完整说明。当你在kubernetes/test-infra中提交自动化相关问题例如 bot 命令失效、标签不同步、自动合并异常时处理者会借助上述工具链定位并修复问题。五、敏感问题的上报渠道如果涉及敏感信息Sensitive issues不要在任何公开 Issue 或 Slack 频道中透露请直接发送邮件至私有列表githubkubernetes.io。该渠道用于处理不适合公开讨论的安全、隐私或保密性相关事项。六、请求时效SLO与升级机制了解处理时效有助于你判断何时该升级。GitHub Administration Team 承诺按以下时限处理请求github-management/org-owners-guide.md组织邀请满足所有成员条件即获得全部 1后一周内处理仓库创建或迁移Issue 打开后 72 小时内响应若需补充信息或满足特定要求则在全部要求满足后 72 小时内创建仓库安全或审核请求尽可能立即处理且需保证跨时区、跨国家的覆盖其他所有请求Issue 打开后一周内响应具体解决时间视请求内容而定。如果请求超出上述时限或有紧急需求请在关联 Issue 中 提及[kubernetes/owners]寻求协助。这与 github-management/opening-a-request.md 中的升级路径完全一致构成提交 → 等待 → 超时升级的完整闭环。七、背后的治理机制谁在处理这些请求理解处理方有助于你写出更高效的请求。这些流程由Contributor Experience SIG 下属的 GitHub Management 子项目负责制定与维护github-management/subproject-responsibilities.md其职责包括制定组织成员、组织权限、仓库创建/管理等常规 GitHub 管理任务的政策与标准建立Org Owner权限策略制定 bot 账号、服务账号、webhook 与第三方集成的策略以及组建负责具体执行的GitHub Administration Team。GitHub Administration Team 成员即kubernetes/owners团队持有所有活跃 Kubernetes 组织的 Org Owner 权限负责依据政策执行各类 GitHub 管理任务github-management/README.md。该团队的提名来自 Contributor Experience SIG并需经 Steering Committee 确认成员选择时会考虑时区与国家分布以确保北美工作时间之外和节假日也有足够覆盖。从权限模型看github-management/permissions.mdGitHub 原生的组织级权限只有 owner / member 两级仓库级只有 admin / write / read 三级粒度粗糙且非全即无。Kubernetes 通过自动化bot 命令、OWNERS 文件门控审批、自动化合并规避这些限制将大部分操作交由机器执行而需要人工介入的高频例外操作就通过本文所述的 Issue/PR 渠道流转——这正是开一个请求流程存在的根本原因。八、请求处理速查提交前对照清单提交请求前请先对照以下清单确认渠道无误可显著加快处理速度问题是否属于配置类权限 / 成员 / 集成 / Webhook / 仓库创建迁移归档 / Project Board→ 对kubernetes/org开 Issue问题是否属于团队变更创建团队 / 添加成员 / 重命名团队→ 对kubernetes/org提交 PR并确保满足 github-management/org-owners-guide.md 的命名、privacy: closed、审批要求问题是否属于自动化类Bot 配置 / 自动合并 / 打标→ 对kubernetes/test-infra开 Issue是否包含敏感信息→ 邮件至githubkubernetes.io切勿公开发布是否紧急 / 是否超时→ 在 Issue 中 kubernetes/owners或在#github-management、#testing-opsSlack 频道中联系对应团队。提示仓库创建 / 迁移类请求在 Issue 获批后后续的团队与权限分配仍需按 Team Guidance 提交 PR并由 peribolos 在 postsubmit 中自动创建团队并分配访问权限仓库最终还需要加入 sigs.yaml 中的对应子项目详见 github-management/org-owners-guide.md 与 github-management/kubernetes-repositories.md。因此一个完整的仓库创建请求往往包含Issue 审批 PR 配置两个阶段请预留足够时间。通过遵循上述分类与渠道规则你可以让自己的请求被 GitHub Administration Team、GitHub Management 子项目或 test-infra 团队正确接收并及时处理避免因渠道错投而延误。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考