Kubernetes Elections 选举子项目指南Elekto 平台、Steering 委员会选举与团队选举申请全流程【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文基于 Kubernetes Community 仓库中的elections目录及其下属文档系统讲解 Kubernetes 社区选举即服务elections-as-a-service的完整运作机制包括 Elections 子项目的定位与职责、每年一度的 Steering Committee指导委员会选举流程、基于 Elekto 的 GitOps 选举配置方式以及 SIG/WG/Subproject 等团队如何申请并运行自己的偏好选举。读完本文你将掌握election.yaml、voters.yaml、election_desc.md等核心配置文件的编写方法理解从提名、背书到计票、公示的完整时间线并能在自己的团队中复用这套开源自托管选举方案。Kubernetes Elections 子项目概览Kubernetes 社区的选举工作由一个名为Elections的子项目Subproject统一承载该子项目隶属于 SIG Contributor Experience。其核心产出有两类年度 Steering Committee 选举由选举官员Election Officers简称 EO直接主持的社区最高治理层选举选举即服务elections-as-a-service为社区内所有团队提供可复用的偏好选举preference election托管能力。子项目的全部元数据、历史选举资料与配置模板都维护在仓库的 elections 目录下目录结构划分为三大块elections/steering/历届 Steering Committee 选举2017 年至今的资料、配置与结果elections/teams/面向各 SIG/WG/Subproject 的团队选举说明elections/steering/documentation/Steering 选举的 HOWTO 指南、消息模板与配置文件模板。年度 Steering Committee 选举Steering Committee 选举是 Elections 子项目最重要的产品由选举官员EO直接管理。elections/steering/README.md是历届选举资料的入口页它记录了自 2017 年以来每一届选举的完整档案包括候选人简介、选票 CSV、结果与选票核对文件。截至当前仓库状态最新一届为 2026 年选举上一届为 2025 年选举。每一届选举目录中都包含以下关键文件以 elections/steering/2026/ 为例election.yaml定义该届选举的 Elekto 配置文件election_desc.md面向投票人的选举简介在 Elekto 中展示voters.yaml合格投票人名单nomination-template.md候选人个人简介模板results.md与ballots.csv计票结束后公布的结果与匿名选票数据用于事后核验。若想了解如何完整运行一届 Steering 选举可直接阅读 Steering 选举操作指南HOWTO下文 46 节将展开其核心内容。Elekto基于 GitOps 的自托管选举平台Kubernetes 社区的所有选举包括 Steering 选举与团队选举都运行在自托管的开源偏好选举软件Elekto上其实例由社区自托管Electes 子项目与 K8s-Infra 团队共同负责其升级、迁移、安全报告处理与故障排查。Elekto 的核心设计理念是GitOps选举的状态不存放在数据库中而是以 YAML/Markdown 文件的形式维护在 kubernetes/community 仓库里一旦这些文件被合并进仓库对应选举就会自动出现在选举应用中通常半小时内生效。election.yaml定义一届选举的核心配置Elekto 通过election.yaml感知一届选举的存在。下面结合 2026 年 Steering 选举的真实配置 逐字段说明其含义name: 2026 Steering Committee Election # 选举名称会在应用界面展示 organization: Kubernetes # 组织名 start_datetime: 2026-08-14 00:00:01 # 投票开启时间UTC 当天开始时刻 end_datetime: 2026-10-02 11:59:59 # 投票关闭时间AoE 时区当日 23:59:59 no_winners: 3 # 本次要选出的席位数量 allow_no_opinion: True # 允许投票人对某候选人选择无意见 delete_after: True # 选举结束后删除相关数据隐私考虑 show_candidate_fields: # 候选人在应用页面上展示的字段 - employer - slack election_officers: # 本届选举官员的 GitHub ID - npolshakova - reylejano - sreeram-venkitesh eligibility: Kubernetes Org members can vote. # 投票资格说明文本 exception_description: If you should be eligible, but are not, then please request an exception to allow you to vote via the Elekto application. exception_due: 2026-09-30 11:59:59 # 投票例外申请截止时间AoE几个值得注意的细节对照 官方模板 elections/steering/documentation/template/election-template.yaml时间语义start_datetime采用投票开启日 UTC 00:00:01写法end_datetime采用投票关闭日 AoE 23:59:59写法即把截止日写成次日 11:59:59保证 Anywhere on Earth 上的投票人都能投满最后一天资格文本eligibility字段里可以写富文本链接向投票人说明资格判定规则例外机制exception_due通常设定在投票结束前 34 天给 EO 留出审核时间字段限制show_candidate_fields控制候选人在页面上公开哪些信息模板默认展示employer与slack。配套文件election_desc.md 与 voters.yamlelection_desc.md是一段人类可读的选举摘要会被 Elekto 直接展示给投票人。它通常包含本届开放席位数量、任期长度、投票资格判定标准Kubernetes Org 成员、Elekto 使用指引以及例外申请入口的说明。voters.yaml是合格投票人名单其结构非常简单——一个eligible_voters:键下按行列出 GitHub ID见 模板文件。需要特别注意的是Elekto 目前对大小写敏感voters.yaml中的 GitHub ID 必须与贡献者账号的官方大小写完全一致复制 ID 时务必保留原始大小写。为 SIG/WG/Subproject 请求团队选举除了年度 Steering 选举任何Kubernetes 团队都可以复用 Elekto 运行自己的内部选举相关说明完整记录在 elections/teams/README.md 中。谁可以请求选举Kubernetes 团队的定义非常宽泛包括SIG、Working Group、Release Engineering / Enhancements 等运营团队、Subproject乃至 Prow、Cluster API 这类完全附属的项目。基本原则是只要你的群体全部由 Kubernetes 贡献者构成就可以申请选举。唯一例外是那些不属于 Kubernetes 组件、不受 Kubernetes 治理约束的 CNCF 项目。工作原理团队选举同样运行在自托管的 Elekto 实例上。整个流程是团队的选举作为元数据三个配置文件添加到 kubernetes/community 仓库合并后选举自动出现在应用中团队指派自己的成员担任选举管理员Election Administrators负责实际运营团队提供合格投票人的 GitHub ID 名单、候选人简介提交截止日、投票开闭日期候选人通过向选举目录提交个人简介加入选举视情况由 Contributor Comms 团队协助宣传与截止日提醒投票结束后管理员计算并公布结果通过应用或直接发布到团队频道/邮件列表。注意两点放宽条件候选人不一定是人——团队完全可以就开发方案或设计稿选项进行选举不过这种场景用问卷可能更合适投票人与管理员不要求是 Kubernetes Org 成员只要有 GitHub ID 即可。方式一通过 Issue 请求推荐新手如果团队还不熟悉 Elekto应通过提交选举请求 Issue 的方式申请。Issue 模板中要求填写的信息全部必填提交后 Elections 子项目成员会主动联系并协助配置选举元数据。务必在选举开始前至少留出一周时间用于配置与审批。方式二通过 Pull Request 请求熟手加速如果团队已有 Elekto 使用经验可以直接自建元数据文件并以 PR 形式提交审批更快。每个团队选举占用仓库中的一个独立目录路径规则为elections/teams/team-name/election-name例如elections/teams/clusterapi/leads-2022。目录内必须包含以下三个文件内容需完整文件作用election.yaml定义选举本身的 Elekto 配置字段含义见上文election-desc.md选举的文字描述在应用中展示给投票人voters.yaml初始投票人名单最快的上手方式是从另一场选举中复制这三个文件然后修改为自己的内容前提是已确定管理员名单和选举日期。PR 提交后由 Elections 子项目成员审查、指出数据修正项并批准合并。Elections 子项目职责、成员与协作机制回到 elections/README.md该子项目承担以下四项核心职责维护与更新选举文档、消息模板与 K8s-Infra 团队协作维护选举软件与服务协助并审批 SIG/WG 运行小型选举为每届 Steering 选举推荐选举官员名单。成员与审批机制任何人都可以为选举子项目做贡献仓库中的 OWNERS 文件 列出了当前 approver 与 reviewer 名单。approver 与 reviewer 还负责选举路线图、维护与安全因此新增 approver 必须获得 SIG Contributor Experience 的 chairs 或 Steering Committee 的批准。文件同时带有area/elections与sig/contributor-experience标签便于 GitHub 上的归属检索。当前子项目成员负责遴选选举官员名单为Josh BerkusRed Hat、Xander GrzywinskiDefense Unicorns、Paris PittmanApple、Federico MuñozSAS。沟通渠道在 kubernetes/community 仓库的 Issue/PR 中打/area elections标签Kubernetes Slack 的#sig-contribex频道参加 SIG Contributor Experience 的例会。软件维护子项目与 K8s-Infra 团队共同负责 Elekto 的升级、迁移、用户支持与安全事件响应。若未来需要更换选举软件子项目负责向 Steering Committee 提交方案供其批准同时也维护必要脚本如拉取投票人名单的脚本。推荐选举官员的时间表子项目负责在每年选举前遴选并推荐下一届 Steering 选举的 EO标准时间表如下6 月初联系去年的 EO确认哪些人留任6 月中旬在 SIG-Contribex 内发出招募号召一对一接触可能人选7 月初向 Steering Committee 提交推荐名单尽量附上候补 Alternate7 月中旬SC 批准 EO 名单7 月下旬EO 制定本届选举日程。EO 应从 Kubernetes 项目中长期、可信赖的贡献者中选出并兼顾雇主、人口与地域多样性进一步要求见 Steering 选举文档。EO 一经确定即被视为 Elections 子项目成员。小型选举Minor Elections子项目会协助 Kubernetes 团队/SIG/WG 准备内部选举包括关注选举相关的 Issue/PR、帮助创建配置文件或为团队审核文件并与 Contributor Comms 团队协作进行适当宣传。由于 Elekto 支持并发运行多场选举运行额外选举的主要瓶颈在于 Contribex 志愿者投入的协助时间而非平台容量。深度实操如何完整运行一届 Steering 选举Steering 选举 HOWTO 是子项目最重要的操作文档它定义了全部角色、时间线与分阶段流程本节提炼其实战要点。角色体系Elections 子项目推荐 EO、在 EO 出现意外时介入、跟进选举复盘建议Election Officers三名必须是 Org 成员超过一年、具备本届投票资格、承诺对任何雇主/SIG/个人偏好保持中立、且能连续服务两届的受信任贡献者。三名 EO 必须来自不同雇主。其职责覆盖规划选举与起草时间线、生成投票人名单、在投票系统中配置选举、裁决例外申请、判定候选人资格、协助候选人撰写简介、宣传选举、定稿并公示结果、主持复盘并归档文档Alternate Election Officer一到两名在正式 EO 无法履职时被激活顶替平时加入 EO 的 Slack 与邮件列表但不参与投票同时作为下一届 EO 的储备人选K8s Infra Liaison由 K8s-Infra 团队指派负责 Elekto 部署层面的排障与变更需具备 k8s.io 服务的审批/修改权限若某位 EO 具备该权限也可兼任Contributor-Comms Liaison由 Contributor Comms 指派负责选举宣传与提醒消息的发布需具备推文审批权限EO 若属于 Comms 团队也可兼任。标准时间线以 Day 0 为起点HOWTO 文档给出了以第 0 天为基准的完整日程Day 0 通常在 6 月 1 日至 6 月 30 日之间核心节点如下Day活动负责角色0开始 EO 遴选子项目 Leads10提名 EO 名单子项目 Leads14SC 批准 EOSteering Committee20选定 liaisons、提出时间线EO24更新 Elekto 版本Infra Liaison26向 Devstats 请求投票人名单、创建复盘文档EO Admin / EO30创建选举配置合并到 k/communityEO Admin32开放提名EO32-78候选人核验 / 例外申请评估EO50提名截止EO51清理候选人简介EO Admin53宣布投票开始EO Comms78例外申请截止自动—81投票关闭自动—82向 SC 提交结果EO Admin84SC 批准结果Steering Committee86私下通知候选人须比公开早 24-48 小时EO87公开宣布结果EO Comms89结果同步进 ElektoEO Admin94上传 ballots.csv 与详细结果EO Admin95举行复盘2 周内均可EO、子项目制定实际日程时有几个硬性约束截止日不要落在 KubeCon 周或紧随其后提名期至少 2 周投票期至少 2 周、建议 3 周步骤之间预留 12 天缓冲以应对 Elekto 故障或 SC 响应迟缓。生成投票人名单投票人名单的产生分四步详见 HOWTO 文档从Devstats生成近一年贡献者名单过滤机器人按仓库组下载 CSV将该名单与 Org 成员名单取交集剔除非 Org 成员。Org 成员名单可用如下 yq 命令从 Org 仓库生成yq .admins .members config/kubernetes/org.yaml config/kubernetes-client/org.yaml config/kubernetes-csi/org.yaml config/kubernetes-sigs/org.yaml | sort -f | uniq | grep -v \-\-\-补入 Code of Conduct 委员会与 Security Response 委员会的全部成员不受贡献数限制按字母排序、去重并重新格式化为voters.yaml模板要求的格式注意保留 GitHub ID 官方大小写。提名与候选人管理候选人通过在 kubernetes/community 仓库提交 Issue宣布参选标题形如Steering Committee Nomination: Your Name (yourgithub)并在 k/dev 邮件列表附上 Issue 链接他人代提名须先征得本人同意候选人须获得3 名来自不同雇主的合格投票人的背书且背书只统计 GitHub Issue 上的 1 评论邮件中的 1 无效——EO 需要反复纠正社区在邮件列表上背书的行为达到背书门槛后EO 在 Issue 上公布候选人资格候选人以 PR 提交个人简介candidate-yourgithub.md简介文件要求文件名必须为candidate-ghid.md且ghid与文件内 YAML 头部的ID字段完全一致YAML 头部不能增删字段、不能使用符号、不能破坏-----分隔线与缩进正文篇幅建议控制在300 词以内超长会被要求精简后才能合并错过提名截止日、或投票开始后仍未完成修正的候选人将失去参选资格。投票例外Voter Exceptions由于 Devstats 无法覆盖 100% 的贡献整个投票周期 EO 都在审批例外申请。投票人可在 Elekto 应用内直接检查资格并提交例外表单EO 在管理页面评估。判定基准是宁可通过、不要误拒例外申请人几乎都会投票。文档给出了两组先例通常可批准贡献超 50 次但非 Org 成员同时劝其申请加入 OrgOrg 成员申请已提交但未获批为 Contributor Summit 提供 15 小时以上协助在 sigs.yaml 中担任当前有效角色非 Emeritus、非废弃子项目近一年 Release Team 成员通常不可批准第三方信息资源的作者/维护者私人/公司博客、个人视频频道、Meetup 组织者、会议演讲者、其他 CNCF 项目贡献者、Kubernetes 发行版贡献者——除非有额外贡献佐证。例外申请在投票结束前约 3 天截止投票开始后 EO 应加快响应。选举结束后EO 只向 SC 汇报申请数量与批准/拒绝数量不汇报任何个案细节个案信息保密。计票与结果发布Elekto 的计票采用纯Condorcet 排序方法投票人可对候选人排序并选择no opinion平票时由未参选的 SC 成员抛硬币决定EO 先按排序选出席位数量对应的胜者随后执行雇主多样性上限若新 SC 中同一雇主成员将超过 2 人则该雇主新当选者依次顺延出局若因过度竞选或 CoC 违规取消某人资格则三人必须达成共识后方可移除结果通知顺序固定为① 通知未参选的 Steering 成员并获批准 → ② 提前约 24 小时私下通知候选人要求保密→ ③ 向社区公开宣布k/dev、Slack视情况配合活动/博客→ ④ 合并results.md让结果在 Elekto 中可见 → ⑤ 发布博客文章。选举后收尾上传 ballots.csv投票结束后一周内由一名 EO 下载匿名选票并提交到当年选举目录确保未来任何时候都能核验结果或重建选举数据库复盘Retro选举结束后两周内举行复盘文档应在选举周期初就建立并持续记录问题与亮点结束后复制为 Markdown 存入当年目录特殊选举Special Election若 SC 因多人辞职、成员被投票免职或委员会解散而需年内补选由上一届 EO 负责主持可压缩提名期与投票期至各 2 周。EO 的中立性与退出机制EO 被明确要求避免任何疑似偏袒的行为不得公开背书或批评特定候选人含社交媒体、不得给候选人特殊协助、不得在工作场所或外部组织宣传候选人、不得发布不代表 EO 共识的个人观点、不得身兼多职导致无人复核其工作。若某位 EO 因病、利益冲突或失联数日而无法履职其余 EO 可晋升 Alternate 顶替并须立即通知子项目与 SC若 EO 少于三人则由子项目尽快补充多数情况下需顺延选举日程。模板与消息素材开箱即用的资源模板目录 elections/steering/documentation/template/ 提供了搭建一届选举所需的全部起点文件election-template.yamlElekto 配置模板需重命名为election.yaml并填充全部占位符election_desc.md投票人可见的选举简介模板voters.yaml投票人名单模板eligible_voters:列表nomination-template.md候选人简介模板YAML 头部含name、ID、info中的employer与slack正文含 SIGs / What I have done / What Ill do / Resources About Me 四节2026 届使用的版本 与之完全一致README.md面向投票人的完整选举指南模板含重要链接、日程表、资格说明、提名/背书/竞选/投票流程github-banner-template.md可在 Kubernetes GitHub 组织页投放的投票提醒横幅模板。此外消息模板目录 elections/steering/documentation/messaging/ 存放选举周期内各类公告与提醒的文案模板提名开启、投票开始、投票提醒、结果公布等EO Comms 可直接复用并更新年份后发出。总结Kubernetes Elections 子项目把治理选举这件对社区信任至关重要的工程做成了完全开放、可审计、可复用的 GitOps 流程配置文件即状态、合并即上线、结果可复核ballots.csv长期归档。无论是想参与投票的贡献者、想运行团队内部选举的 SIG/WG还是想深入了解社区治理运作机制的读者都可以从 elections 目录出发投票者看 Steering 选举入口团队负责人看 团队选举说明想要亲手运营一届选举的贡献者则应以 Steering 选举 HOWTO 为操作手册配合 模板目录 中的现成文件快速起步。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes Elections 选举子项目指南：Elekto 平台、Steering 委员会选举与团队选举申请全流程
Kubernetes Elections 选举子项目指南Elekto 平台、Steering 委员会选举与团队选举申请全流程【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文基于 Kubernetes Community 仓库中的elections目录及其下属文档系统讲解 Kubernetes 社区选举即服务elections-as-a-service的完整运作机制包括 Elections 子项目的定位与职责、每年一度的 Steering Committee指导委员会选举流程、基于 Elekto 的 GitOps 选举配置方式以及 SIG/WG/Subproject 等团队如何申请并运行自己的偏好选举。读完本文你将掌握election.yaml、voters.yaml、election_desc.md等核心配置文件的编写方法理解从提名、背书到计票、公示的完整时间线并能在自己的团队中复用这套开源自托管选举方案。Kubernetes Elections 子项目概览Kubernetes 社区的选举工作由一个名为Elections的子项目Subproject统一承载该子项目隶属于 SIG Contributor Experience。其核心产出有两类年度 Steering Committee 选举由选举官员Election Officers简称 EO直接主持的社区最高治理层选举选举即服务elections-as-a-service为社区内所有团队提供可复用的偏好选举preference election托管能力。子项目的全部元数据、历史选举资料与配置模板都维护在仓库的 elections 目录下目录结构划分为三大块elections/steering/历届 Steering Committee 选举2017 年至今的资料、配置与结果elections/teams/面向各 SIG/WG/Subproject 的团队选举说明elections/steering/documentation/Steering 选举的 HOWTO 指南、消息模板与配置文件模板。年度 Steering Committee 选举Steering Committee 选举是 Elections 子项目最重要的产品由选举官员EO直接管理。elections/steering/README.md是历届选举资料的入口页它记录了自 2017 年以来每一届选举的完整档案包括候选人简介、选票 CSV、结果与选票核对文件。截至当前仓库状态最新一届为 2026 年选举上一届为 2025 年选举。每一届选举目录中都包含以下关键文件以 elections/steering/2026/ 为例election.yaml定义该届选举的 Elekto 配置文件election_desc.md面向投票人的选举简介在 Elekto 中展示voters.yaml合格投票人名单nomination-template.md候选人个人简介模板results.md与ballots.csv计票结束后公布的结果与匿名选票数据用于事后核验。若想了解如何完整运行一届 Steering 选举可直接阅读 Steering 选举操作指南HOWTO下文 46 节将展开其核心内容。Elekto基于 GitOps 的自托管选举平台Kubernetes 社区的所有选举包括 Steering 选举与团队选举都运行在自托管的开源偏好选举软件Elekto上其实例由社区自托管Electes 子项目与 K8s-Infra 团队共同负责其升级、迁移、安全报告处理与故障排查。Elekto 的核心设计理念是GitOps选举的状态不存放在数据库中而是以 YAML/Markdown 文件的形式维护在 kubernetes/community 仓库里一旦这些文件被合并进仓库对应选举就会自动出现在选举应用中通常半小时内生效。election.yaml定义一届选举的核心配置Elekto 通过election.yaml感知一届选举的存在。下面结合 2026 年 Steering 选举的真实配置 逐字段说明其含义name: 2026 Steering Committee Election # 选举名称会在应用界面展示 organization: Kubernetes # 组织名 start_datetime: 2026-08-14 00:00:01 # 投票开启时间UTC 当天开始时刻 end_datetime: 2026-10-02 11:59:59 # 投票关闭时间AoE 时区当日 23:59:59 no_winners: 3 # 本次要选出的席位数量 allow_no_opinion: True # 允许投票人对某候选人选择无意见 delete_after: True # 选举结束后删除相关数据隐私考虑 show_candidate_fields: # 候选人在应用页面上展示的字段 - employer - slack election_officers: # 本届选举官员的 GitHub ID - npolshakova - reylejano - sreeram-venkitesh eligibility: Kubernetes Org members can vote. # 投票资格说明文本 exception_description: If you should be eligible, but are not, then please request an exception to allow you to vote via the Elekto application. exception_due: 2026-09-30 11:59:59 # 投票例外申请截止时间AoE几个值得注意的细节对照 官方模板 elections/steering/documentation/template/election-template.yaml时间语义start_datetime采用投票开启日 UTC 00:00:01写法end_datetime采用投票关闭日 AoE 23:59:59写法即把截止日写成次日 11:59:59保证 Anywhere on Earth 上的投票人都能投满最后一天资格文本eligibility字段里可以写富文本链接向投票人说明资格判定规则例外机制exception_due通常设定在投票结束前 34 天给 EO 留出审核时间字段限制show_candidate_fields控制候选人在页面上公开哪些信息模板默认展示employer与slack。配套文件election_desc.md 与 voters.yamlelection_desc.md是一段人类可读的选举摘要会被 Elekto 直接展示给投票人。它通常包含本届开放席位数量、任期长度、投票资格判定标准Kubernetes Org 成员、Elekto 使用指引以及例外申请入口的说明。voters.yaml是合格投票人名单其结构非常简单——一个eligible_voters:键下按行列出 GitHub ID见 模板文件。需要特别注意的是Elekto 目前对大小写敏感voters.yaml中的 GitHub ID 必须与贡献者账号的官方大小写完全一致复制 ID 时务必保留原始大小写。为 SIG/WG/Subproject 请求团队选举除了年度 Steering 选举任何Kubernetes 团队都可以复用 Elekto 运行自己的内部选举相关说明完整记录在 elections/teams/README.md 中。谁可以请求选举Kubernetes 团队的定义非常宽泛包括SIG、Working Group、Release Engineering / Enhancements 等运营团队、Subproject乃至 Prow、Cluster API 这类完全附属的项目。基本原则是只要你的群体全部由 Kubernetes 贡献者构成就可以申请选举。唯一例外是那些不属于 Kubernetes 组件、不受 Kubernetes 治理约束的 CNCF 项目。工作原理团队选举同样运行在自托管的 Elekto 实例上。整个流程是团队的选举作为元数据三个配置文件添加到 kubernetes/community 仓库合并后选举自动出现在应用中团队指派自己的成员担任选举管理员Election Administrators负责实际运营团队提供合格投票人的 GitHub ID 名单、候选人简介提交截止日、投票开闭日期候选人通过向选举目录提交个人简介加入选举视情况由 Contributor Comms 团队协助宣传与截止日提醒投票结束后管理员计算并公布结果通过应用或直接发布到团队频道/邮件列表。注意两点放宽条件候选人不一定是人——团队完全可以就开发方案或设计稿选项进行选举不过这种场景用问卷可能更合适投票人与管理员不要求是 Kubernetes Org 成员只要有 GitHub ID 即可。方式一通过 Issue 请求推荐新手如果团队还不熟悉 Elekto应通过提交选举请求 Issue 的方式申请。Issue 模板中要求填写的信息全部必填提交后 Elections 子项目成员会主动联系并协助配置选举元数据。务必在选举开始前至少留出一周时间用于配置与审批。方式二通过 Pull Request 请求熟手加速如果团队已有 Elekto 使用经验可以直接自建元数据文件并以 PR 形式提交审批更快。每个团队选举占用仓库中的一个独立目录路径规则为elections/teams/team-name/election-name例如elections/teams/clusterapi/leads-2022。目录内必须包含以下三个文件内容需完整文件作用election.yaml定义选举本身的 Elekto 配置字段含义见上文election-desc.md选举的文字描述在应用中展示给投票人voters.yaml初始投票人名单最快的上手方式是从另一场选举中复制这三个文件然后修改为自己的内容前提是已确定管理员名单和选举日期。PR 提交后由 Elections 子项目成员审查、指出数据修正项并批准合并。Elections 子项目职责、成员与协作机制回到 elections/README.md该子项目承担以下四项核心职责维护与更新选举文档、消息模板与 K8s-Infra 团队协作维护选举软件与服务协助并审批 SIG/WG 运行小型选举为每届 Steering 选举推荐选举官员名单。成员与审批机制任何人都可以为选举子项目做贡献仓库中的 OWNERS 文件 列出了当前 approver 与 reviewer 名单。approver 与 reviewer 还负责选举路线图、维护与安全因此新增 approver 必须获得 SIG Contributor Experience 的 chairs 或 Steering Committee 的批准。文件同时带有area/elections与sig/contributor-experience标签便于 GitHub 上的归属检索。当前子项目成员负责遴选选举官员名单为Josh BerkusRed Hat、Xander GrzywinskiDefense Unicorns、Paris PittmanApple、Federico MuñozSAS。沟通渠道在 kubernetes/community 仓库的 Issue/PR 中打/area elections标签Kubernetes Slack 的#sig-contribex频道参加 SIG Contributor Experience 的例会。软件维护子项目与 K8s-Infra 团队共同负责 Elekto 的升级、迁移、用户支持与安全事件响应。若未来需要更换选举软件子项目负责向 Steering Committee 提交方案供其批准同时也维护必要脚本如拉取投票人名单的脚本。推荐选举官员的时间表子项目负责在每年选举前遴选并推荐下一届 Steering 选举的 EO标准时间表如下6 月初联系去年的 EO确认哪些人留任6 月中旬在 SIG-Contribex 内发出招募号召一对一接触可能人选7 月初向 Steering Committee 提交推荐名单尽量附上候补 Alternate7 月中旬SC 批准 EO 名单7 月下旬EO 制定本届选举日程。EO 应从 Kubernetes 项目中长期、可信赖的贡献者中选出并兼顾雇主、人口与地域多样性进一步要求见 Steering 选举文档。EO 一经确定即被视为 Elections 子项目成员。小型选举Minor Elections子项目会协助 Kubernetes 团队/SIG/WG 准备内部选举包括关注选举相关的 Issue/PR、帮助创建配置文件或为团队审核文件并与 Contributor Comms 团队协作进行适当宣传。由于 Elekto 支持并发运行多场选举运行额外选举的主要瓶颈在于 Contribex 志愿者投入的协助时间而非平台容量。深度实操如何完整运行一届 Steering 选举Steering 选举 HOWTO 是子项目最重要的操作文档它定义了全部角色、时间线与分阶段流程本节提炼其实战要点。角色体系Elections 子项目推荐 EO、在 EO 出现意外时介入、跟进选举复盘建议Election Officers三名必须是 Org 成员超过一年、具备本届投票资格、承诺对任何雇主/SIG/个人偏好保持中立、且能连续服务两届的受信任贡献者。三名 EO 必须来自不同雇主。其职责覆盖规划选举与起草时间线、生成投票人名单、在投票系统中配置选举、裁决例外申请、判定候选人资格、协助候选人撰写简介、宣传选举、定稿并公示结果、主持复盘并归档文档Alternate Election Officer一到两名在正式 EO 无法履职时被激活顶替平时加入 EO 的 Slack 与邮件列表但不参与投票同时作为下一届 EO 的储备人选K8s Infra Liaison由 K8s-Infra 团队指派负责 Elekto 部署层面的排障与变更需具备 k8s.io 服务的审批/修改权限若某位 EO 具备该权限也可兼任Contributor-Comms Liaison由 Contributor Comms 指派负责选举宣传与提醒消息的发布需具备推文审批权限EO 若属于 Comms 团队也可兼任。标准时间线以 Day 0 为起点HOWTO 文档给出了以第 0 天为基准的完整日程Day 0 通常在 6 月 1 日至 6 月 30 日之间核心节点如下Day活动负责角色0开始 EO 遴选子项目 Leads10提名 EO 名单子项目 Leads14SC 批准 EOSteering Committee20选定 liaisons、提出时间线EO24更新 Elekto 版本Infra Liaison26向 Devstats 请求投票人名单、创建复盘文档EO Admin / EO30创建选举配置合并到 k/communityEO Admin32开放提名EO32-78候选人核验 / 例外申请评估EO50提名截止EO51清理候选人简介EO Admin53宣布投票开始EO Comms78例外申请截止自动—81投票关闭自动—82向 SC 提交结果EO Admin84SC 批准结果Steering Committee86私下通知候选人须比公开早 24-48 小时EO87公开宣布结果EO Comms89结果同步进 ElektoEO Admin94上传 ballots.csv 与详细结果EO Admin95举行复盘2 周内均可EO、子项目制定实际日程时有几个硬性约束截止日不要落在 KubeCon 周或紧随其后提名期至少 2 周投票期至少 2 周、建议 3 周步骤之间预留 12 天缓冲以应对 Elekto 故障或 SC 响应迟缓。生成投票人名单投票人名单的产生分四步详见 HOWTO 文档从Devstats生成近一年贡献者名单过滤机器人按仓库组下载 CSV将该名单与 Org 成员名单取交集剔除非 Org 成员。Org 成员名单可用如下 yq 命令从 Org 仓库生成yq .admins .members config/kubernetes/org.yaml config/kubernetes-client/org.yaml config/kubernetes-csi/org.yaml config/kubernetes-sigs/org.yaml | sort -f | uniq | grep -v \-\-\-补入 Code of Conduct 委员会与 Security Response 委员会的全部成员不受贡献数限制按字母排序、去重并重新格式化为voters.yaml模板要求的格式注意保留 GitHub ID 官方大小写。提名与候选人管理候选人通过在 kubernetes/community 仓库提交 Issue宣布参选标题形如Steering Committee Nomination: Your Name (yourgithub)并在 k/dev 邮件列表附上 Issue 链接他人代提名须先征得本人同意候选人须获得3 名来自不同雇主的合格投票人的背书且背书只统计 GitHub Issue 上的 1 评论邮件中的 1 无效——EO 需要反复纠正社区在邮件列表上背书的行为达到背书门槛后EO 在 Issue 上公布候选人资格候选人以 PR 提交个人简介candidate-yourgithub.md简介文件要求文件名必须为candidate-ghid.md且ghid与文件内 YAML 头部的ID字段完全一致YAML 头部不能增删字段、不能使用符号、不能破坏-----分隔线与缩进正文篇幅建议控制在300 词以内超长会被要求精简后才能合并错过提名截止日、或投票开始后仍未完成修正的候选人将失去参选资格。投票例外Voter Exceptions由于 Devstats 无法覆盖 100% 的贡献整个投票周期 EO 都在审批例外申请。投票人可在 Elekto 应用内直接检查资格并提交例外表单EO 在管理页面评估。判定基准是宁可通过、不要误拒例外申请人几乎都会投票。文档给出了两组先例通常可批准贡献超 50 次但非 Org 成员同时劝其申请加入 OrgOrg 成员申请已提交但未获批为 Contributor Summit 提供 15 小时以上协助在 sigs.yaml 中担任当前有效角色非 Emeritus、非废弃子项目近一年 Release Team 成员通常不可批准第三方信息资源的作者/维护者私人/公司博客、个人视频频道、Meetup 组织者、会议演讲者、其他 CNCF 项目贡献者、Kubernetes 发行版贡献者——除非有额外贡献佐证。例外申请在投票结束前约 3 天截止投票开始后 EO 应加快响应。选举结束后EO 只向 SC 汇报申请数量与批准/拒绝数量不汇报任何个案细节个案信息保密。计票与结果发布Elekto 的计票采用纯Condorcet 排序方法投票人可对候选人排序并选择no opinion平票时由未参选的 SC 成员抛硬币决定EO 先按排序选出席位数量对应的胜者随后执行雇主多样性上限若新 SC 中同一雇主成员将超过 2 人则该雇主新当选者依次顺延出局若因过度竞选或 CoC 违规取消某人资格则三人必须达成共识后方可移除结果通知顺序固定为① 通知未参选的 Steering 成员并获批准 → ② 提前约 24 小时私下通知候选人要求保密→ ③ 向社区公开宣布k/dev、Slack视情况配合活动/博客→ ④ 合并results.md让结果在 Elekto 中可见 → ⑤ 发布博客文章。选举后收尾上传 ballots.csv投票结束后一周内由一名 EO 下载匿名选票并提交到当年选举目录确保未来任何时候都能核验结果或重建选举数据库复盘Retro选举结束后两周内举行复盘文档应在选举周期初就建立并持续记录问题与亮点结束后复制为 Markdown 存入当年目录特殊选举Special Election若 SC 因多人辞职、成员被投票免职或委员会解散而需年内补选由上一届 EO 负责主持可压缩提名期与投票期至各 2 周。EO 的中立性与退出机制EO 被明确要求避免任何疑似偏袒的行为不得公开背书或批评特定候选人含社交媒体、不得给候选人特殊协助、不得在工作场所或外部组织宣传候选人、不得发布不代表 EO 共识的个人观点、不得身兼多职导致无人复核其工作。若某位 EO 因病、利益冲突或失联数日而无法履职其余 EO 可晋升 Alternate 顶替并须立即通知子项目与 SC若 EO 少于三人则由子项目尽快补充多数情况下需顺延选举日程。模板与消息素材开箱即用的资源模板目录 elections/steering/documentation/template/ 提供了搭建一届选举所需的全部起点文件election-template.yamlElekto 配置模板需重命名为election.yaml并填充全部占位符election_desc.md投票人可见的选举简介模板voters.yaml投票人名单模板eligible_voters:列表nomination-template.md候选人简介模板YAML 头部含name、ID、info中的employer与slack正文含 SIGs / What I have done / What Ill do / Resources About Me 四节2026 届使用的版本 与之完全一致README.md面向投票人的完整选举指南模板含重要链接、日程表、资格说明、提名/背书/竞选/投票流程github-banner-template.md可在 Kubernetes GitHub 组织页投放的投票提醒横幅模板。此外消息模板目录 elections/steering/documentation/messaging/ 存放选举周期内各类公告与提醒的文案模板提名开启、投票开始、投票提醒、结果公布等EO Comms 可直接复用并更新年份后发出。总结Kubernetes Elections 子项目把治理选举这件对社区信任至关重要的工程做成了完全开放、可审计、可复用的 GitOps 流程配置文件即状态、合并即上线、结果可复核ballots.csv长期归档。无论是想参与投票的贡献者、想运行团队内部选举的 SIG/WG还是想深入了解社区治理运作机制的读者都可以从 elections 目录出发投票者看 Steering 选举入口团队负责人看 团队选举说明想要亲手运营一届选举的贡献者则应以 Steering 选举 HOWTO 为操作手册配合 模板目录 中的现成文件快速起步。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考