尧图网站建设 
Kubernetes 新贡献者 Workshop 实战从找到第一个 Issue 到成为社区成员【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文以 first-issue-help.md 这份 New Contributor Workshop 现场教学手册为骨架系统讲解 Kubernetes 新贡献者如何通过help-wanted与good-first-issue标签找到并认领第一个 Issue、如何在正确的 SIG 中获得支持以及如何沿着社区成员阶梯完成从“路人贡献者”到“正式 Member”的跨越。读完本文你既能获得一份可直接复用的 20 分钟 Workshop 授课脚本也能掌握一套自己动手找 Issue、认领 Issue、联系 SIG、发起 membership 申请的完整操作流程。一、这一讲在 Workshop 中的定位为参与者铺一条“到成功为止”的路在 live-workshop 目录 里New Contributor Workshop 按参与者水平分为 Beginner 与 Intermediate 两条 Track而“Find Your First Issue”这一讲都是压轴环节Beginner TrackWelcome → Live PR Demo → Contributor Paths → Communication → Community Groups → Repo Tour → Workspace Setup → Local BuildTest → Pull Request Exercise →Find Your First IssueIntermediate TrackWelcome → Live PR Demo → Contributor Paths → Communication → Community Groups → Repo Tour → k/k Walkthrough → Local BuildTest → Labels, Bots and Git Workflow →Find Your First Issue该讲的标准时长为20 分钟任务目标Task Overview只有一句话“把参与者尽可能放到一条通往贡献者成功的铺好路paved path上。”也就是说到了这个环节参与者已经完成了环境搭建、PR 流程演练应当明确“自己想解决哪一类问题”接下来要做的是帮他们锁定一个真实可落地的 Issue而不是继续讲理论。从教学编排上看这一讲是前面所有环节的收口Labels, Bots and Git Workflow讲过的标签与机器人命令详见 labels-and-bots.mdCommunity Groups讲过的 SIG 结构详见 community-groups.md到这里全部转化为一次真实认领动作。因此本文既面向 Workshop 组织者如何设计这 20 分钟也面向每一个想自己找到第一个 Issue 的贡献者。二、核心标签体系help-wanted与good-first-issue2.1 两个标签的关系子集与增强Kubernetes 用两个标签标识“专门为新贡献者挑选过的问题”规范定义在 contributors/guide/help-wanted.mdhelp wanted问题已被社区认可、适合外部贡献者解决good first issue是help wanted的子集表示社区成员承诺为提交者提供额外协助、会“护送”这个 PR 走完全部流程。关键规则是所有good first issue同时带有help wanted标签反之则不一定。good first issue面向第一次参与的新人社区会额外盯着这类 PR当新人完成 12 个good first issue后就应转向普通的help wanted任务。2.2help wanted的硬性标准标注者视角仓库文档为打上help wanted标签的 Issue 规定了三条标准标准要求Clear Task任务清晰任务已达成共识、无需再在社区中讨论API 与 CLI 行为应在 Issue 原文中明确例如“新命令语法为svcat unbind NAME [--orphan] [--timeout 5m]”并注明预期的校验逻辑若该区域代码未测试应明确指出并可能需要新增测试夹具fixtureGoldilocks priority优先级适中不能高到核心贡献者应该亲自做也不能低到核心贡献者不值得花时间 review、答疑、协助合入Up-To-Date保持最新这类 Issue 经常过期——可能已完成、不再需要、不再合理或优先级/难度已变化需要持续维护2.3good first issue的额外六条标准在满足help wanted全部要求之上good first issue还要满足No Barrier to Entry新人无需高级环境配置或领域知识即可上手Solution Explained推荐解法已在 Issue 中清楚描述Provides Context如需背景知识必须明确说明并附推荐阅读清单Gives Examples链接相似的既有实现给新人当参考Identifies Relevant Code指明需要改动的代码与测试文件Ready to Test已有可修改的测试或有可复制的测试用例若该区域无测试先补一个 test fixture 再打标签——补 fixture 本身就是个不错的help wanted任务。2.4 通过 Prow 机器人命令管理标签在 GitHub Issue 评论区输入以下命令即可管理标签由 Prow/k8s-ci-robot 执行命令效果/help给 Issue 添加help wanted标签/remove-help移除help wanted标签若同时存在good first issue也会一并移除/good-first-issue添加good first issue若help wanted尚未存在则同时添加/remove-good-first-issue仅移除good first issue标签这套命令体系在 labels-and-bots.md 中被归纳为 Workshop 的独立环节10–15 分钟组织者通常会引导参与者在 kubernetes-sigs/contributor-playground。三、如何“认领”一个 Issue非成员无法自助分配的现实与对策3.1 成员与非成员的权限差异这一讲特别强调了一个社区现实非组织成员无法在 GitHub 上自助Assign自己。根据 community-membership.md只有MemberKubernetes GitHub 组织成员才能“被分配”Issue 和 PR、参与 SIG 的 GitHub Team其 PR 会自动运行测试也可以直接执行/lgtm。对于尚未入会的参与者认领 Issue 的推荐姿势是在 Issue 评论区回复/assign或/assign yourself详见 contributors/guide/first-contribution.md 的 Issue Assignment 一节k8s-ci-robot 会自动把 Issue 分配给你你的名字出现在Assignees栏。但实际执行时非成员经常遇到机器人拒绝的情况。Workshop 手册给出的思路是由现场的组织者、SIG 成员或导览者代为协调——在 20 分钟内直接帮参与者确认“这个 Issue 可以归你”并引导他们在评论区留言、通过/cc username召唤相关人员。这样既绕开了权限门槛也让参与者体验真实的协作方式。3.2 认领前先检查三件事结合 help-wanted.md 与 issue-triage.md认领前应确认标签是否还挂在 Issue 上避免认领已过期/已完成的 Issue是否已有其他人在评论区表达了认领意向优先让位给先到者Issue 中是否给出了相关代码、测试文件与示例链接good first issue应当满足全部六条标准。四、与 SIG 协同找到对的社区、获得对的帮助4.1 从 Issue 反查 SIGKubernetes 社区按SIGSpecial Interest Group组织每个 SIG 拥有自己的一部分仓库、Slack 频道、例会与文档结构总览见 community-groups.md。找到 Issue 所属 SIG 后可在该 SIG 的频道中提问、在例会上露脸获得比“盲提交”高得多的响应速度。first-contribution.md 给出了具体做法如果你不确定归属可查看 sig-list.md 中每个 SIG 的联系方式并在 Issue 评论区用/sig network这类命令打上 SIG 标签例子里network对应 sig-network。PR 场景下自动分配的 reviewer 也会帮你补上 SIG 标签。此外多个 SIG 维护了自己的 CONTRIBUTING.md 与额外指南例如 sig-apps/CONTRIBUTING.md、sig-cli/CONTRIBUTING.md、sig-node/CONTRIBUTING.md、sig-storage/CONTRIBUTING.md 等动手前值得一读。4.2 OWNERS 文件谁是“能帮你的人”仓库通过每个目录下的 OWNERS 文件来标识 reviewer 与 approver规范详见 contributors/guide/owners.md。一个典型的 OWNERS 文件形如reviewers: - sig-apps-leads approvers: - sig-apps-leads labels: - sig/apps上例节选自 sig-apps/OWNERS其中sig-apps-leads是定义在 OWNERS_ALIASES 中的别名。认领 Issue 后查看相关目录的 OWNERS 文件就能知道该找谁 review、该 谁Prow 会自动把 PR 分配给合适的 reviewer。Workshop 现场组织者可以顺手教参与者“从 OWNERS 读出这条代码谁负责”。4.3 关于“新出现的 sandbox 项目”手册提到的 “Up and coming sandbox projects” 指向一类机会Kubernetes 生态中处于早期、正在建设中、非常缺人手的新仓库例如 kubernetes-sigsKubernetes 各 Org/仓库总览——组织者可以结合它准备一个“当前缺人、欢迎新人”的项目清单。五、从贡献者到成员社区成员阶梯与 membership 路径5.1 四个角色及其定义community-membership.md 定义了 Kubernetes 社区的角色阶梯这是“Path to membership”环节的核心讲稿素材角色职责核心要求定义方式Member社区活跃贡献者2 位 reviewer 担保 多次贡献Kubernetes GitHub 组织成员Reviewer审查他人贡献在某子项目中有 review 与 authorship 历史OWNERS 文件 reviewer 条目Approver批准贡献合入对子项目有丰富经验且持续活跃OWNERS 文件 approver 条目Subproject Owner制定子项目方向与优先级展现出责任感与优秀技术判断力sigs.yaml 子项目 OWNERS 的 owners 条目5.2 成为 Member 的具体要求Member 是整个阶梯的入口其要求包括启用 GitHub两步验证2FA在 CNCF gitdm 与 openprofile.dev 中保持用户名、公司归属、邮箱最新无公司归属则标记为 “Independent”有多次贡献证明持续、长期的投入至少包含一个已合入的 PR例如一个推动数周的 KEP、数月内的一批小 PR或一批需要与社区协作解决的高难度 PR订阅 devkubernetes.io活跃贡献 1 个以上子项目由2 位 reviewer 担保担保人必须与你有密切互动如代码/设计 review、协调 Issue且至少在某个 Kubernetes 组织仓库的 OWNERS 中担任 reviewer 或 approver两位担保人须来自不同公司在 kubernetes/org 仓库 提交 membership 申请 Issue 两位担保人并逐项完成申请模板清单担保人回复1后由 Kubernetes GitHub Admin 团队按 SLO 审核。5.3 如何在 20 分钟内讲清“路径”手册提示的要点是明确告诉参与者“现在还不能自我分配但成为 Member 后就可以了”并把 community-membership.md 作为下一步的行动文档发给参与者。一个可用的讲稿框架展示角色阶梯表Member → Reviewer → Approver → Subproject Owner强调 Member 的三个收益可被分配 Issue/PR、PR 自动跑测试、可执行/lgtm给出“第一次 PR 合入 → 继续 2–3 次贡献 → 找 2 位来自不同公司的 reviewer 担保 → 提交 org 申请”的路线图提醒参与者关注 contributors/guide/expectations.md 中的社区期望响应 review、维护自己合入的代码等。六、20 分钟授课脚本Ideas 的具体落地原手册的 “Ideas” 部分是给 Workshop 组织者的实操建议这里展开为可执行的步骤6.1 留出讨论时间让参与者互相帮助手册建议 “Give folks time to discuss and help each other”。20 分钟建议这样切分5 分钟讲解标签与认领方法 → 10 分钟“现场认领”参与者两两一组互相检查对方的候选 Issue 是否符合good first issue标准→ 5 分钟集体答疑与收尾。让刚认领成功的人现场分享“你是怎么判断这个 Issue 可做的”比讲师单方面输出更有效。6.2 提前从 SIG 收集“谁需要帮助、什么难度”手册建议通过 Slack、Twitter 等渠道在 Workshop 前向各 SIG 收集信息哪些 SIG 缺人、缺什么层级的人。组织者可提前与 SIG 联络人确认 35 个“确定可认领”的 Issue 及其难度分级形成一份现场分发清单避免参与者认领后石沉大海。这与 mentoring/programs/README.md 中“mentoring 会议与 New Contributor Workshop 会议合办”的机制互为补充——组织者本身就可以是各 SIG 的联络人。6.3 准备一份 Issue 清单现场直接分配“Prepare a list of issues and assign folks right there”——建议把清单做成表格Issue 链接、所属 SIG、所需技能、预估难度对照help-wanted的 Goldilocks 标准、是否已有认领人。对于非成员无法自助分配的情况现场由 SIG 成员在 Issue 下留言或使用/assign代劳并把操作过程投影出来让全场看到完整流程。6.4 连接 mentoring 轨道手册建议 “Connect participants to mentoring tracks if available (e.g. Release Team Shadow)”。仓库中的 shadow-roles.md 记录了 Release Team Shadow 这类短期深度辅导项目此外 mentoring/programs 下还整理有 group-mentoring.md、office-hours.md、the1-on-1hour.md 等机制。组织者应把“找到了 Issue”进一步升级为“找到了长期陪伴”——把参与者接入对应 SIG 的例会、Slack 频道与 mentoring 项目这才是把一次性贡献者变成回归贡献者的关键。七、给参与者的行动清单Workshop 结束可带走最后把这一讲浓缩成 8 步行动清单既可用于 Workshop 收尾投影也可作为独立读者的自查表在 go.k8s.io/good-first-issue 或 go.k8s.io/help-wanted 按标签筛选候选 Issue对照good first issue六条标准无障碍、有解法、有上下文、有示例、指明代码、可测试筛选出 23 个候选在 Issue 评论区输入/assign尝试认领失败则联系 SIG 成员协助打开 sig-list.md 找到对应 SIG加入其 Slack 频道并注明“我正在做 #xxx”阅读该仓库的 CONTRIBUTING.md 与该目录的 OWNERS 文件确认 review 路径提交 PR利用/cc召唤 reviewer若带good first issue标签社区成员会主动护航合入首个 PR 后继续完成 12 个good first issue或help wanted积累多次贡献记录按 community-membership.md 的要求找 2 位跨公司 reviewer 担保在 kubernetes/org 仓库提交 membership 申请完成从贡献者到 Member 的升级。参考资料索引本讲原始手册 first-issue-help.md标签规范 contributors/guide/help-wanted.md首次贡献指南 contributors/guide/first-contribution.md成员阶梯 community-membership.mdSIG 清单 sig-list.md组织者手册 new-contributor-workshop-lead.md【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes 新贡献者 Workshop 实战：从找到第一个 Issue 到成为社区成员
Kubernetes 新贡献者 Workshop 实战从找到第一个 Issue 到成为社区成员【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文以 first-issue-help.md 这份 New Contributor Workshop 现场教学手册为骨架系统讲解 Kubernetes 新贡献者如何通过help-wanted与good-first-issue标签找到并认领第一个 Issue、如何在正确的 SIG 中获得支持以及如何沿着社区成员阶梯完成从“路人贡献者”到“正式 Member”的跨越。读完本文你既能获得一份可直接复用的 20 分钟 Workshop 授课脚本也能掌握一套自己动手找 Issue、认领 Issue、联系 SIG、发起 membership 申请的完整操作流程。一、这一讲在 Workshop 中的定位为参与者铺一条“到成功为止”的路在 live-workshop 目录 里New Contributor Workshop 按参与者水平分为 Beginner 与 Intermediate 两条 Track而“Find Your First Issue”这一讲都是压轴环节Beginner TrackWelcome → Live PR Demo → Contributor Paths → Communication → Community Groups → Repo Tour → Workspace Setup → Local BuildTest → Pull Request Exercise →Find Your First IssueIntermediate TrackWelcome → Live PR Demo → Contributor Paths → Communication → Community Groups → Repo Tour → k/k Walkthrough → Local BuildTest → Labels, Bots and Git Workflow →Find Your First Issue该讲的标准时长为20 分钟任务目标Task Overview只有一句话“把参与者尽可能放到一条通往贡献者成功的铺好路paved path上。”也就是说到了这个环节参与者已经完成了环境搭建、PR 流程演练应当明确“自己想解决哪一类问题”接下来要做的是帮他们锁定一个真实可落地的 Issue而不是继续讲理论。从教学编排上看这一讲是前面所有环节的收口Labels, Bots and Git Workflow讲过的标签与机器人命令详见 labels-and-bots.mdCommunity Groups讲过的 SIG 结构详见 community-groups.md到这里全部转化为一次真实认领动作。因此本文既面向 Workshop 组织者如何设计这 20 分钟也面向每一个想自己找到第一个 Issue 的贡献者。二、核心标签体系help-wanted与good-first-issue2.1 两个标签的关系子集与增强Kubernetes 用两个标签标识“专门为新贡献者挑选过的问题”规范定义在 contributors/guide/help-wanted.mdhelp wanted问题已被社区认可、适合外部贡献者解决good first issue是help wanted的子集表示社区成员承诺为提交者提供额外协助、会“护送”这个 PR 走完全部流程。关键规则是所有good first issue同时带有help wanted标签反之则不一定。good first issue面向第一次参与的新人社区会额外盯着这类 PR当新人完成 12 个good first issue后就应转向普通的help wanted任务。2.2help wanted的硬性标准标注者视角仓库文档为打上help wanted标签的 Issue 规定了三条标准标准要求Clear Task任务清晰任务已达成共识、无需再在社区中讨论API 与 CLI 行为应在 Issue 原文中明确例如“新命令语法为svcat unbind NAME [--orphan] [--timeout 5m]”并注明预期的校验逻辑若该区域代码未测试应明确指出并可能需要新增测试夹具fixtureGoldilocks priority优先级适中不能高到核心贡献者应该亲自做也不能低到核心贡献者不值得花时间 review、答疑、协助合入Up-To-Date保持最新这类 Issue 经常过期——可能已完成、不再需要、不再合理或优先级/难度已变化需要持续维护2.3good first issue的额外六条标准在满足help wanted全部要求之上good first issue还要满足No Barrier to Entry新人无需高级环境配置或领域知识即可上手Solution Explained推荐解法已在 Issue 中清楚描述Provides Context如需背景知识必须明确说明并附推荐阅读清单Gives Examples链接相似的既有实现给新人当参考Identifies Relevant Code指明需要改动的代码与测试文件Ready to Test已有可修改的测试或有可复制的测试用例若该区域无测试先补一个 test fixture 再打标签——补 fixture 本身就是个不错的help wanted任务。2.4 通过 Prow 机器人命令管理标签在 GitHub Issue 评论区输入以下命令即可管理标签由 Prow/k8s-ci-robot 执行命令效果/help给 Issue 添加help wanted标签/remove-help移除help wanted标签若同时存在good first issue也会一并移除/good-first-issue添加good first issue若help wanted尚未存在则同时添加/remove-good-first-issue仅移除good first issue标签这套命令体系在 labels-and-bots.md 中被归纳为 Workshop 的独立环节10–15 分钟组织者通常会引导参与者在 kubernetes-sigs/contributor-playground。三、如何“认领”一个 Issue非成员无法自助分配的现实与对策3.1 成员与非成员的权限差异这一讲特别强调了一个社区现实非组织成员无法在 GitHub 上自助Assign自己。根据 community-membership.md只有MemberKubernetes GitHub 组织成员才能“被分配”Issue 和 PR、参与 SIG 的 GitHub Team其 PR 会自动运行测试也可以直接执行/lgtm。对于尚未入会的参与者认领 Issue 的推荐姿势是在 Issue 评论区回复/assign或/assign yourself详见 contributors/guide/first-contribution.md 的 Issue Assignment 一节k8s-ci-robot 会自动把 Issue 分配给你你的名字出现在Assignees栏。但实际执行时非成员经常遇到机器人拒绝的情况。Workshop 手册给出的思路是由现场的组织者、SIG 成员或导览者代为协调——在 20 分钟内直接帮参与者确认“这个 Issue 可以归你”并引导他们在评论区留言、通过/cc username召唤相关人员。这样既绕开了权限门槛也让参与者体验真实的协作方式。3.2 认领前先检查三件事结合 help-wanted.md 与 issue-triage.md认领前应确认标签是否还挂在 Issue 上避免认领已过期/已完成的 Issue是否已有其他人在评论区表达了认领意向优先让位给先到者Issue 中是否给出了相关代码、测试文件与示例链接good first issue应当满足全部六条标准。四、与 SIG 协同找到对的社区、获得对的帮助4.1 从 Issue 反查 SIGKubernetes 社区按SIGSpecial Interest Group组织每个 SIG 拥有自己的一部分仓库、Slack 频道、例会与文档结构总览见 community-groups.md。找到 Issue 所属 SIG 后可在该 SIG 的频道中提问、在例会上露脸获得比“盲提交”高得多的响应速度。first-contribution.md 给出了具体做法如果你不确定归属可查看 sig-list.md 中每个 SIG 的联系方式并在 Issue 评论区用/sig network这类命令打上 SIG 标签例子里network对应 sig-network。PR 场景下自动分配的 reviewer 也会帮你补上 SIG 标签。此外多个 SIG 维护了自己的 CONTRIBUTING.md 与额外指南例如 sig-apps/CONTRIBUTING.md、sig-cli/CONTRIBUTING.md、sig-node/CONTRIBUTING.md、sig-storage/CONTRIBUTING.md 等动手前值得一读。4.2 OWNERS 文件谁是“能帮你的人”仓库通过每个目录下的 OWNERS 文件来标识 reviewer 与 approver规范详见 contributors/guide/owners.md。一个典型的 OWNERS 文件形如reviewers: - sig-apps-leads approvers: - sig-apps-leads labels: - sig/apps上例节选自 sig-apps/OWNERS其中sig-apps-leads是定义在 OWNERS_ALIASES 中的别名。认领 Issue 后查看相关目录的 OWNERS 文件就能知道该找谁 review、该 谁Prow 会自动把 PR 分配给合适的 reviewer。Workshop 现场组织者可以顺手教参与者“从 OWNERS 读出这条代码谁负责”。4.3 关于“新出现的 sandbox 项目”手册提到的 “Up and coming sandbox projects” 指向一类机会Kubernetes 生态中处于早期、正在建设中、非常缺人手的新仓库例如 kubernetes-sigsKubernetes 各 Org/仓库总览——组织者可以结合它准备一个“当前缺人、欢迎新人”的项目清单。五、从贡献者到成员社区成员阶梯与 membership 路径5.1 四个角色及其定义community-membership.md 定义了 Kubernetes 社区的角色阶梯这是“Path to membership”环节的核心讲稿素材角色职责核心要求定义方式Member社区活跃贡献者2 位 reviewer 担保 多次贡献Kubernetes GitHub 组织成员Reviewer审查他人贡献在某子项目中有 review 与 authorship 历史OWNERS 文件 reviewer 条目Approver批准贡献合入对子项目有丰富经验且持续活跃OWNERS 文件 approver 条目Subproject Owner制定子项目方向与优先级展现出责任感与优秀技术判断力sigs.yaml 子项目 OWNERS 的 owners 条目5.2 成为 Member 的具体要求Member 是整个阶梯的入口其要求包括启用 GitHub两步验证2FA在 CNCF gitdm 与 openprofile.dev 中保持用户名、公司归属、邮箱最新无公司归属则标记为 “Independent”有多次贡献证明持续、长期的投入至少包含一个已合入的 PR例如一个推动数周的 KEP、数月内的一批小 PR或一批需要与社区协作解决的高难度 PR订阅 devkubernetes.io活跃贡献 1 个以上子项目由2 位 reviewer 担保担保人必须与你有密切互动如代码/设计 review、协调 Issue且至少在某个 Kubernetes 组织仓库的 OWNERS 中担任 reviewer 或 approver两位担保人须来自不同公司在 kubernetes/org 仓库 提交 membership 申请 Issue 两位担保人并逐项完成申请模板清单担保人回复1后由 Kubernetes GitHub Admin 团队按 SLO 审核。5.3 如何在 20 分钟内讲清“路径”手册提示的要点是明确告诉参与者“现在还不能自我分配但成为 Member 后就可以了”并把 community-membership.md 作为下一步的行动文档发给参与者。一个可用的讲稿框架展示角色阶梯表Member → Reviewer → Approver → Subproject Owner强调 Member 的三个收益可被分配 Issue/PR、PR 自动跑测试、可执行/lgtm给出“第一次 PR 合入 → 继续 2–3 次贡献 → 找 2 位来自不同公司的 reviewer 担保 → 提交 org 申请”的路线图提醒参与者关注 contributors/guide/expectations.md 中的社区期望响应 review、维护自己合入的代码等。六、20 分钟授课脚本Ideas 的具体落地原手册的 “Ideas” 部分是给 Workshop 组织者的实操建议这里展开为可执行的步骤6.1 留出讨论时间让参与者互相帮助手册建议 “Give folks time to discuss and help each other”。20 分钟建议这样切分5 分钟讲解标签与认领方法 → 10 分钟“现场认领”参与者两两一组互相检查对方的候选 Issue 是否符合good first issue标准→ 5 分钟集体答疑与收尾。让刚认领成功的人现场分享“你是怎么判断这个 Issue 可做的”比讲师单方面输出更有效。6.2 提前从 SIG 收集“谁需要帮助、什么难度”手册建议通过 Slack、Twitter 等渠道在 Workshop 前向各 SIG 收集信息哪些 SIG 缺人、缺什么层级的人。组织者可提前与 SIG 联络人确认 35 个“确定可认领”的 Issue 及其难度分级形成一份现场分发清单避免参与者认领后石沉大海。这与 mentoring/programs/README.md 中“mentoring 会议与 New Contributor Workshop 会议合办”的机制互为补充——组织者本身就可以是各 SIG 的联络人。6.3 准备一份 Issue 清单现场直接分配“Prepare a list of issues and assign folks right there”——建议把清单做成表格Issue 链接、所属 SIG、所需技能、预估难度对照help-wanted的 Goldilocks 标准、是否已有认领人。对于非成员无法自助分配的情况现场由 SIG 成员在 Issue 下留言或使用/assign代劳并把操作过程投影出来让全场看到完整流程。6.4 连接 mentoring 轨道手册建议 “Connect participants to mentoring tracks if available (e.g. Release Team Shadow)”。仓库中的 shadow-roles.md 记录了 Release Team Shadow 这类短期深度辅导项目此外 mentoring/programs 下还整理有 group-mentoring.md、office-hours.md、the1-on-1hour.md 等机制。组织者应把“找到了 Issue”进一步升级为“找到了长期陪伴”——把参与者接入对应 SIG 的例会、Slack 频道与 mentoring 项目这才是把一次性贡献者变成回归贡献者的关键。七、给参与者的行动清单Workshop 结束可带走最后把这一讲浓缩成 8 步行动清单既可用于 Workshop 收尾投影也可作为独立读者的自查表在 go.k8s.io/good-first-issue 或 go.k8s.io/help-wanted 按标签筛选候选 Issue对照good first issue六条标准无障碍、有解法、有上下文、有示例、指明代码、可测试筛选出 23 个候选在 Issue 评论区输入/assign尝试认领失败则联系 SIG 成员协助打开 sig-list.md 找到对应 SIG加入其 Slack 频道并注明“我正在做 #xxx”阅读该仓库的 CONTRIBUTING.md 与该目录的 OWNERS 文件确认 review 路径提交 PR利用/cc召唤 reviewer若带good first issue标签社区成员会主动护航合入首个 PR 后继续完成 12 个good first issue或help wanted积累多次贡献记录按 community-membership.md 的要求找 2 位跨公司 reviewer 担保在 kubernetes/org 仓库提交 membership 申请完成从贡献者到 Member 的升级。参考资料索引本讲原始手册 first-issue-help.md标签规范 contributors/guide/help-wanted.md首次贡献指南 contributors/guide/first-contribution.md成员阶梯 community-membership.mdSIG 清单 sig-list.md组织者手册 new-contributor-workshop-lead.md【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考