摘要

  • RIPE-861建议志愿者不要先在公开邮件列表发出提名，而应直接联系任期没有结束的工作组主席；文件给出的理由之一，是鼓励不那么外向的人参与。
  • 目前十二个活跃工作组的遴选页面没有采用同一种交接方式：有的允许私下或公开表达意向，随后承诺公布全部候选人；有的要求公开自荐；还有一些页面写了征集和截止日期，却没有在所检查的页面中说明提交渠道。
  • 隐私与问责并不冲突。公开层可以记录人数、同意、资格、退出、回避、名单发布时间和决定，个人姓名与原始通信则在本人同意成为候选人之前保持私密。

第一封信可以不公开，最终产生的职务权力不能没有公共来路。

RIPE-861的最终版本发布于2026年6月12日。它在工作组主席遴选章节中，把“直接向任期不结束的主席提交志愿提名，而不是在邮件列表上公开提交”列为最佳实践。文件同时说明，这种安排可能吸引更多提名，尤其有利于不那么外向的候选人。

这个判断有现实基础。面对一个已经形成专业关系和讨论习惯的技术社群，公开宣布竞选并不是没有成本。潜在志愿者可能只想先问清楚工作强度、资格条件、差旅以及线上参与方式。一次探索性的私下询问，不应自动变成永久可检索的参选声明。

但私下入口也改变了证据出现的位置。公开自荐在发出时就留下档案；私下意向只有在接收者把它转为公开候选时才被社群看见。因此，问责的核心不是要求公布第一封邮件，而是证明所有符合资格且同意参选的人，都通过相同规则进入了公开候选名单。

现有资料没有显示任何人被漏报、偏袒或不当曝光。这里讨论的是一项有合理包容目标的制度，在争议发生之前应当生成什么证据。

它是共同建议，不是中央选举法

RIPE-861使用的是“最佳实践”语言。除了私下接收提名，它还建议每位主席任期不超过三年、考虑设置连任次数上限，并允许线上参与。它没有把所有工作组改造成同一张选票、同一种共识判断或同一条申诉路径。

前一版本RIPE-692要求每个工作组自行制定、维护并实施主席遴选与免职程序。官方版本对比说明，私下提名建议来自2026年的更新，而不是一条长期存在的统一规则。

这种分散性并非必须消除的缺陷。RIPE-723中的RIPE问责工作组报告认为，每个工作组维护自己的主席更替程序符合自下而上的治理方式；它的第八项建议同时指出，为了提高清晰度，应协调遴选程序中的不一致。统一证据字段与统一决定方式不是一回事。工作组可以保留不同的投票、共识和任期安排，同时使用相同的交接状态。

RIPE-861本身的形成过程提供了一个参照：2025年12月23日发布第一稿，2026年3月27日发布第二稿，5月29日宣布达成共识，随后发布最终文本。读者能够知道哪个版本在何时获得权威。主席遴选需要的是一条规模更小、但同样可重建的状态链。

十二个页面展示了多种交接方式

在本次研究截止时，RIPE的活跃工作组索引列出了十二个带有主席遴选页面的工作组。并列阅读这些页面，不应得出“十二项失败”的结论；它呈现的是不同的入口、公开时点和决定方式。

工作组 所检查页面写明的入口 页面写明的公开与决定方式
Address Policy 候选人在邮件列表自我介绍 线上和现场参与会场共识；共识失败时由现场人员进行STV秘密投票
Connect 邮件列表或直接联系主席 主席公布全部候选人，列表讨论，再宣布决定
Cooperation 邮件列表或直接联系 公布全部候选人，列表讨论，再作决定
Database 直接联系主席 公布全部候选人；被涉及的主席不参与判断；可向RIPE主席申诉
DNS 邀请申请；所检查页面未说明提交渠道 邮件列表形成共识；当事主席回避；RIPE主席处理最终申诉
Internet of Things 所检查页面未说明渠道 工作组形成共识，由留任主席判断；未涵盖事项交RIPE主席决定
IPv6 列表发布征集和截止日期；页面未说明提交渠道 RIPE会议会场遴选；现场人员参与；不明确时秘密投票；候选人可远程参加
MAT 在邮件列表表达意向 列表讨论，主席宣布共识
Open Source 直接、离开列表联系留任主席 同时公布全部候选人，收集支持，工作组最终批准，RIPE Chair Team确认程序
Routing 会前一天停止接收提名；页面未说明渠道 由出席工作组会议的人达成共识
Security 列表征集并设置截止日期；页面未说明提交渠道 会议现场遴选；结果不明确时秘密投票；候选人可不在现场
RIPE NCC Services 两周意向期；页面未说明渠道 两周公开讨论，留任主席判断共识，沿用正常申诉程序

Connect与Cooperation已经写出了一个明确接口：意向可以从两条渠道进入，之后主席必须确保所有候选人都在列表上公布。Database只写直接接收，但随后同样要求公布全部候选人，并明确当事主席不参加共识判断以及最终申诉路径。Open Source的链条最完整：志愿者直接联系留任主席，确认满足条件，全部候选人在同一时间公开，工作组提供反馈，主席识别支持最多者，工作组最后批准，RIPE Chair Team再确认程序已被正确执行。

Address Policy和MAT从公开动作开始。前者要求候选人在列表自我介绍，后者要求意向者通过列表表态。它们在入口处不需要相同的“私下转公开”证明，但仍应保存程序版本、决定方法和最终结果。

其余若干页面给出征集、期限或会场规则，却没有写明申请发送到哪里。准确表述只能止于此：所检查页面没有写。一次具体的征集通知完全可能提供邮箱和操作说明。页面缺少字段不等于实际没有渠道，更不等于已经发生违规。

意向、提名和候选资格不是同一个状态

意向可能只是试探。提名可以由本人或第三方提出。资格审查把公开条件应用于个人。本人同意决定姓名是否可以进入公共空间。公开候选资格让社群开始评估。支持意见进入共识或投票。决定产生任命；确认或申诉再检查程序是否正确结束。

最小状态链可以写成：

收到意向 → 确认同意 → 审查资格 → 成为公开候选人 → 讨论 → 决定 → 确认或申诉

如果把所有私下询问都公开为候选人，RIPE-861希望保护的低门槛入口就不存在了。如果完全不记录转换，社群又无法验证名单是否完整。正确做法是记录状态，而不是公开犹豫。

一个人在同意公开前退出，可以只体现在匿名计数中。资格不符可以使用有限理由类别，例如“未满足参会条件”，而不必公开个人细节。逾期提交需要时间戳和所适用的处理规则。公共层需要知道每个阶段有多少人以及转换是否完整，不需要知道每一封信的内容。

候选名单交接回执

最小回执首先标识工作组、程序网址、版本或哈希、征集开始时间、截止时间、允许的渠道、获授权的接收者，以及接收者是否同时可能成为候选人或决定者。

随后记录隐私安全的数量：收到多少意向，多少人同意，多少人在公开前退出，多少份逾期，多少人符合资格，各类未通过原因分别有多少。名单公开时，记录发布时间，并加入一项完整性声明：通过公布渠道收到的每一名合格且同意的人，都已列入公开名单。

决定一侧记录讨论场所、起止时间、线上或现场参与方式、判断支持的方法、回避、结果、确认、申诉、任期起止和后续更正。

公开回执可以这样写：收到五份意向，四人同意，一人在公开前退出，四人均符合条件，四个姓名在时间T同时发布，负责接收的主席没有参选，两名其他主席判断共识，没有申诉。限制访问的记录只保存纠错所需的最少通信，并按照期限删除。退出者的姓名无需公开。

这与“政策讨论转入私下后如何回到公共档案”不是同一证据对象。政策起草需要把修改文本、理由和被舍弃方案带回公开讨论；候选名单交接要在评价个人之前证明名单完整、本人同意且符合条件。两者都穿过公私边界，但要携带的证据完全不同。

每个状态由谁控制

候选人控制同意与退出。留任主席可能控制接收和名单发布。工作组提供讨论、支持或共识。现任主席在多套程序中负责判断共识，有些页面明确排除成为当事人的主席。RIPE NCC工作人员负责清点某些秘密投票。RIPE主席或RIPE Chair Team在不同程序中担任申诉者、最终决定者、监督者或确认者。

这些角色不能被压缩成“RIPE NCC选择所有工作组主席”。RIPE社群与RIPE NCC有制度边界。后者托管页面、邮件列表、会议和秘书支持；具体遴选权仍属于每个程序所描述的社群。

一个留任主席同时接收私信、发布名单并判断支持，也不自动构成不当行为。它意味着回避字段很重要。如果接收者本人参选，或者需要处理有争议的资格问题，替代决定者应当在回执中可见。

证据没有告诉我们的事

十二个页面不是已完成选举的数据集。它们没有说明有多少人考虑过参选、私下渠道是否实际提高参与、多样性是否变化，也没有证明每次具体征集只包含常设页面中的文字。

RIPE-861提到“不那么外向的候选人”是一项预期，而不是本次资料中的测量结果。检验这一效果需要多个周期的匿名总量变化，不能要求志愿者披露性格或动机。

不同决定方式也不等于不合规。Address Policy的后备STV投票、DNS的列表共识、Open Source的支持判断和Routing的会场共识，是本地治理选择。共同回执只需说明使用了哪一种，不必宣布其中一种普遍更好。

可核验的问题应保持狭窄：当第一次接触是私下进行时，是否能重建授权渠道、本人同意、资格判断、完整公开名单、回避、决定和复核？如果可以，包容性并没有取代问责，只是改变了问责需要保存的记录。

来源