event-talk-selection

活动演讲遴选

你负责评审通过征稿通知征集到的提案：由谁评审、采用什么评分标准、分几轮评审，以及给每位投稿者怎样的回复。

此技能不负责：

• 设计征稿通知。征稿通知的时间安排、表单、公布的评审标准和匿名化 政策 由 samber/dev-event-organizer-skills@event-cfp-design 负责；你应遵循该政策，而不是重新决定。
• 在征稿范围之外招募演讲者。该并行渠道由 samber/dev-event-organizer-skills@event-speaker-sourcing 负责，而受邀提案需要有明确规则说明如何进入你的流程（参见工作流）。
• 将已录用的演讲安排进日程表。这由 samber/dev-event-organizer-skills@event-schedule-design 负责。
• 评判在黑客马拉松期间完成的项目。其时间安排在结构上有所不同，且仅持续一天：samber/dev-event-organizer-skills@hackathon-judging。

以下所有排序均为默认顺序，并非硬性规定：它会因具体情况和执行者而变化。访谈结束后，根据你已了解的主办方情况，重新排列这三组选项——以下任何因素都可能推翻默认顺序：

• 已有的评审委员会。
• 已付费使用的工具。
• 小到评审者能通过写作风格认出投稿者的社区。
• 严格的日程公布日期。

访谈

一次只问一个问题，尽可能采用多项选择题。设置问题 3-5，是因为下方的选项在见效速度、回报持久性和所需精力上差异很大——不能替用户做出这些选择。

1. 收到了多少份投稿，有多少个演讲名额？（这一比例决定整个流程：40 份提案和 2,500 份提案是两个不同的问题，而不是同一个问题的不同规模。）
2. 已公布的征稿通知对匿名化、评审标准和通知日期作出了哪些承诺？在设计任何内容之前，先阅读征稿通知——流程必须落实已公布的内容，而不是只图方便。
3. 日程公布日期是什么时候，还剩几周？（严格的日期会直接排除某些选项，而不是压缩它们的时间。）
4. 这是一次性活动，还是需要逐年积累的长期资产？（若需逐年积累，应优先考虑耗时较长的选项：逐份提案提供反馈、组建真正的评审委员会，以及编写能够年复一年沿用的书面评审标准。）
5. 精力投入上限是多少：实际会有多少人阅读提案、每人投入多少小时，以及由谁裁决僵局？
6. 谁在主办活动——社区会议还是厂商／用户会议？（见下方的区分。）
7. 同一日程中是否有受邀演讲或与赞助商有关联的演讲？征稿通知是否说明了这些演讲与公开征集的提案如何协调？
8. 已说明哪些多元化目标：首次演讲者、代表性不足的演讲者、本地与外地演讲者、主题和雇主的分布？哪些目标已公布，哪些仅供内部使用？
9. 有哪些现成资源会影响选项的排序：继续参与的评审委员会、上一届的评审标准及相关意见、带有评审模式的征稿工具、过往决定的存档？
10. 投稿表单是否也用于提交经济援助或差旅资助申请？
11. 活动是多会场并行，还是单会场？
12. 实际到场者有哪些：专家、转行进入该领域的开发者、非技术人员，还是混合人群？请根据上一届的参会情况回答，而不是依据活动标语。混合人群会改变议程匹配度评估，以及每场录用演讲所附的简介。
13. 主办方、其雇主或赞助商的员工是否会投稿？在阅读第一份提案之前，就决定相关规则（参见主办方及赞助商关联投稿）。

社区会议与厂商会议

活动由谁主办，会影响选择标准；本合集的格式与 CFP 技能也强调了同样的区别：

• 社区会议——开放征稿池就是会议议程。底线是：“赞助商绝不能购买演讲名额——绝对不行。”本技能中的所有资料都来自这一立场。
• 厂商／用户会议——内容大多通过邀请确定，并围绕厂商的架构组织；评审只针对整个策划议程中的社区内容部分。以下机制仍适用于这部分，但平衡审查既要回应厂商的叙事，也要回应受众的需求。

如果建议因所属立场不同而有所差异，请说明该建议基于哪种立场。

工作流

1. 进行访谈。先阅读已发布的征稿启事（Q2）——后续所有工作都必须遵守它。
2. 从下方的选项中选择委员会模式，并根据投稿池（Q1）和工作量上限（Q5）确定规模。
3. 采用与该模式相配套的评分标准（参见“评分标准”——它由委员会模式决定，不是自由选择）。在任何人开始评分之前，先将标准写下来。评审中途才制定的标准，会导致先前阅读过的投稿需要重新评分。
4. 从选项中确定匿名评审的执行深度，并确保符合征稿启事中公布的政策。指定一位具名负责人。如果征稿启事承诺了盲审，现在就要以书面形式确定在哪个步骤、向哪些人披露身份。
5. 在开始评分前，而不是出现利益冲突后，再向评审说明利益冲突处理方式（见下文）。为因回避而失去过多评审的提案指定备用评审。
6. 进行第一轮评审：按照评分标准为每份提案打分，并为每个分数附上书面评语。强制要求评语是既定做法，也让第二轮、第三轮评审以及任何真正有意义的拒稿反馈成为可能。
7. 根据分数筛选入围名单。在查看排名前，先将筛选规则明确写出——可以是分数门槛或百分比——避免围绕心仪的提案划定界线。
8. 只对入围名单进行议程适配审查，而不是对整个投稿池审查：主题分布、雇主分布、本地与外地讲者的比例、首次演讲者，以及 Q7 中确定受邀演讲的方式。再加入业内反馈的检查项：厂商演讲的经验迁移价值、主题的新颖性、混合受众的内容深度梯度，以及本届活动的品牌承诺。这一步会将按分数排名的列表转变为一份议程。这也是业内记录最少的环节（见失败模式）——请记录做出了哪些取舍以及原因，因为下一届委员会会问起。
9. 确定演讲名额后，在发送任何通知前先建立候补名单，并明确排列备用人选的顺序。
10. 按以下顺序发送通知：
    • 先发送录取通知，并注明确认截止时间。
    • 确认录取结果后再发送拒稿通知。
    • 告知候补投稿者其候补身份、何时会得到通知，并明确说明候补名额可能永远不会空出。
11. 将录取名单连同演讲形式和分会标签交给 samber/dev-event-organizer-skills@event-schedule-design。记录录取率和平衡审查结果，供下一届参考。

在评审开始前，按章节展示设计内容以供确认——委员会、评分标准、匿名评审、筛选规则、沟通计划。评分开始后再更改规则，会使已评审的内容失效。

如果你的运行环境支持持久记忆，请记录评分标准、筛选规则、录取率、平衡审查结果，以及下一届需要听到什么具体意见才会改变做法。

评审委员会模型

排名（默认排序，并非定论——Q1、Q3、Q5 和 Q9 会重新排序）：

• 工作量（评审人数、协调、轮次、日程）：多层级级联 > 小型共识委员会 > 单人策展
• 价值、可辩护性和偏差稀释：多层级级联 > 小型共识委员会 > 单人策展
• 价值、项目连贯性：单人策展 == 小型共识委员会 > 多层级级联——这个平局有充分论证，并非回避问题：两者都将每项决策留在同一个会议室里，让所有人始终能整体掌握整个项目；这也是此维度唯一衡量的内容。无论人数多少，级联方式都无法与之匹敌，因为后续层级只能看到前序层级递交上来的内容。
• 效率：小型共识委员会 > 单人策展 > 多层级级联

支配关系检查：3 组对比，零个严格支配关系。 这种结果只是按设计构造出来的，而按设计构造出来从来不算通过。两种机制阻止了这三组对比形成严格支配关系：

• 级联方式与另外两种方式相比，都受到相互对立的价值维度阻碍：它在可辩护性上领先，在连贯性上落后。
• 剩下的一组对比，即委员会与单人策展，仅因工作量而未形成支配关系：委员会在可辩护性上领先，在连贯性上持平，但成本仍然更高。

检查没有发现排序错误。效率这一项的依据见下文论述。

• 小型共识委员会——默认选项，也是小规模情况下文档记录最充分的做法：指定一名不参与投票的匿名化人员，再配上约四到六名评审；进行一轮同步讨论；使用字母等级制的倡议评分标准；另准备一份约包含五场演讲的候补名单。适用于单轨或双轨活动，且整个投稿池都能在一个会议室内完成审阅。

• 单人策展——由一名组织者或两人搭档亲自挑选演讲阵容：协调成本近乎为零；单轨活动的组织者认为这是编辑责任，而非走捷径。适用于以邀请为主或规模极小的项目。如果征稿启事公布了公开标准并承诺盲审，应删除此选项，而不是将其降级排列：单个评审无法对自己进行盲审，也无法回避，因此若将此选项留在列表底部，就会悄然重新引入征稿启事已明确排除的流程。

• 多层级级联，这是资源不足的选项：在可辩护性和工作量两方面都最高，因此效率维度从不会选它。常见结构如下：

  1. 分会场委员会评分。
  2. 得分最高的 30% 晋级至分会场主席。
  3. 分会场主席再推荐其中约 30%，并必须附上评语。
  4. 联合主席作出最终决定。

  启用条件：

  • 多轨项目（Q11）。
  • 投稿池大到没有一个会议室能够完整审阅。
  • 活动的决策必须经得起相互竞争的雇主公开审视。

规模说明：上述数字来自两个有文档记录的案例——小型单轨会议约有五名评审；大型多轨活动采用三层结构。第三种分布式投稿池模型（见下文“评分标准”部分）提供了本证据集中唯一可靠的“每份投稿对应评审人数”数据：每份投稿至少获得三次评审，才会停止被积极推荐给更多评审。目前没有可靠依据可在这三个案例之间推算曲线——请根据你们自己的审阅能力进行插值，并明确说明你们正在这样做。

评分标准

评分标准遵循委员会模式，而非单独排名；对于选择已由上游决定的选项进行排名，会造成虚假的精确感。目前有三种成熟的评分标准，各自适用于不同的评审场景：

• 字母等级倡议量表，适用于会开会讨论的委员会：

  • A：会积极倡议。
  • B：喜欢，但不会倡议。
  • C：中立。
  • D：会倡议反对。
  • X：弃权，评审者怀疑自己已认出发言者。

  每个提案的评分汇总为一组最高分与最低分（“AC”），绝不取平均；至少有一个 A，是进入认真考虑阶段的实际门槛。它衡量的是倡议意愿，而讨论环节恰恰会花时间在这上面。

• 多标准星级量表，适用于绝不会碰面的评审者：针对内容、原创性、相关性和演讲者契合度，以半星为步进评定一至五星，并要求每项评分都附上书面反馈。它衡量的是可比性，而汇总筛选正需要这一点。

• 数字 0-3 量表，适用于通过评审平台分配任务、而非固定委员会的分散式评审池：每个分数都对应明确含义（强烈反对、中立反对、中立赞成、强烈赞成），每份评审都必须附上评论；一项投稿一旦获得三份或更多评审，就不再主动重新展示。它能在平台规模下衡量明确的接受或拒绝倾向，同时不具备字母量表的倡议信号，也没有星级量表的四项标准细分。

对字母量表取平均、试图通过讨论绕过星级量表，或将数字量表的四种含义简化为单纯的“高/低”判断，都会丢掉各自设计时要保留的特性。完整的标准措辞、汇总机制和示例见 references/committee-models-and-rubrics.md。

匿名化执行

调用方已经选定了策略。此菜单只决定执行得有多深入。

排序（默认，并非定律）：

• 工作量（每份投稿的处理、角色分离、发言者指示）：专用匿名化工具 > 平台级隐藏 > 具名评审
• 价值、抗泄漏能力：专用匿名化工具 > 平台级隐藏 > 具名评审
• 价值、评分时可获得的信息：具名评审 > 平台级隐藏 > 专用匿名化工具——这里不存在平局：平台级隐藏会隐藏作者字段，但保留投稿者写在标题、摘要或提纲中的内容；匿名化工具则会连这些内容也改写。匿名化工具确实会让评审看到更少信息，这种损失正是该档位的代价，并非四舍五入造成的差异。
• 效率：平台级隐藏 > 具名评审 > 专用匿名化工具

支配关系检查：3 组比较，严格支配关系为零。 仅凭构造得出的结果干净，并不代表通过。一个机制阻断了全部 3 组比较：两个价值维度完全相反，因此抗泄漏能力更强的档位会让评审看到更少信息，没有任何档位能在两者上都至少持平。

任何一组比较都不会涉及工作量，也没有列出第三个维度。检查没有发现任何结果；以下排序是论证得出的，而非验证得出的。

• 平台级隐藏——征稿启事承诺盲审时的默认选项：工具会在初审期间隐藏作者信息（常见征稿平台都提供可选的匿名模式）。其已知限制必须在征稿结束前告知投稿者，而不是等到评审期间才发现：平台隐藏的是作者字段，而非作者写在标题、摘要或提纲中的内容。
• 具名评审——征稿启事未承诺匿名化时的默认选项，也是实际运作中的领域惯例。只有在公布的评审标准承担起匿名化未能承担的公平保障责任时，才算诚实。
• 专用匿名化工具，资源紧缺的选项：由一两个人查看原始投稿，且绝不为其中任何一份评分。他们会将可识别身份的信息改写为方括号占位符，刻意保留作为演讲主题本身的身份信息，并分配随机 ID，使投稿顺序无法重新识别投稿者。抗泄漏能力最高，工作量也最大，因此效率维度永远不会选它。适用条件：
  • 评审委员会规模足够小，无论工具隐藏了什么，都能认出常客。
  • 针对 Q10：财务援助申请与投稿使用同一份表格，匿名化是确保兑现承诺的执行机制，即申请资助不会损害投稿通过的机会。
  • 社群在上一届活动中出现过现实且持续的公平性投诉。

**删除，不要降级：**如果征稿启事公布的是具名评审，本届活动就不应将匿名化列为选项。在评审进行期间补做匿名化毫无作用——评审者已经看过姓名——而且这违背了征稿启事实际作出的承诺。

**在计划中以及向委员会明确说明这一限制。**没有证据衡量匿名评审是否会改变不同人口群体的录取结果。

现有的只有组织者明确表达的意图和机制设计，仅此而已。盲审作为流程承诺是站得住脚的；若将其说成已被证实的公平性成果，则缺乏证据支持。

利益冲突

既定规则由个人自行执行，涵盖两种不同的失当行为——两者都应写入评审须知：

• 对于与评审者密切合作的同事、评审者所属或与之竞争的组织所提交的内容，评审者应跳过该问题——放弃评分，而不是评分后再披露。评审时应「以活动组织者的身份」行事，而非代表雇主。
• 如果怀疑自己认出了匿名演讲者，应放弃评审。

这两条分别针对不同的失当行为。

坦诚地说：这两种回避都依赖诚信约束。没有任何公开的利益冲突登记表、升级处理渠道或审计机制，因此，请将你自行制定的任何升级处理程序视为你自己的设计，并明确说明这一点。提前决定以下两件事，不要等到争议发生时才决定：

• 评审者拒绝回避时，由谁仲裁。
• 如果某个提案因太多评审者回避，导致评分不再具有可比性，该如何处理。

组织者和赞助商关联的投稿

上文的评审须知针对的是评审者给他人的提案打分，并未涵盖同时也是投稿者的组织者。小型聚会团队每届都会遇到这种情况，因为组织者往往是最容易联系到的演讲者。可调整采用的默认做法：

• 披露。 开始评分前，向委员会其他成员标明组织者自己的提案。在盲审中，组织者仍然知道自己的文稿，因此无法对其保持盲态；标注不会损害流程原有的匿名性。
• 回避自己的演讲和雇主的投稿。 按照上文相同的跳过问题规则，组织者不得给自己的提案评分，也不得给来自其雇主的任何提案评分。
• 限制频次。 为组织者每届或每年安排的演讲设定自行规定的上限，并记录下来。没有上限，组织者团队就会悄然占据整个议程。
• 允许选择不参加。 有些组织者更愿意永远不在自己的活动上演讲。应将其视为合理的长期政策，而非需要劝说他们放下的谦逊。
• 限制赞助商关联演讲者的名额。 受雇于当前赞助商的演讲者也要经过同样的评审，活动议程中这类名额的数量也应设定自行规定的上限。社区优先原则仍然适用：名额不出售。通过 samber/dev-event-organizer-skills@event-sponsor-agreement 将编辑独立性条款写入赞助合同，这样上限就是赞助商签署的合同条款，而不是你在拒绝人情。

在提案旁记录每次披露和回避。日后若有人认为活动议程偏袒自己，应以这些记录为依据，而非依靠记忆。

实践者报告的项目契合度检查

这些是现场经验法则，并非测量结果：应将其表述为经验之谈。详情和示例形式见 references/program-fit-field-reports.md。

• 供应商和初创公司演讲的经验迁移测试。 提出一个问题：如果听众明天就忘了产品名称，他们还会记住这条经验吗？如果要点是一条可迁移到任何技术栈的经验或启发，初创公司或供应商就可以演讲。若要点是产品本身，则不合格；商业演示则完全不合格。将商业内容规则写入录用邮件（见参考资料）。
• 主题时效性。 在快速发展的领域，去年的热门主题几个月内就会过时。核实每一项“最先进”或“最新”的承诺时，应以活动实际日期为准，而非投稿日期。评审后留出自行设定数量的空位，并在临近新闻周期时通过邀请填补。说明项目契合度记录中哪些空位暂留未定及其原因。
• 混合听众的深度梯度（对应 Q12）。一个分会场就能服务技术和非技术听众混杂的群体，无须拆分。向每位获选演讲者说明：开场要让几乎所有人都能听懂，结尾则进入大多数听众难以跟上的内容。实践者的经验法则：如果演讲结束时没有让大多数听众跟不上，那就不够深入。评估提案是否能兼顾这两个层次，并将晚间议程顺序交给 samber/dev-event-organizer-skills@event-schedule-design。
• 根据听众的实际水平，而非期望水平安排。 实践者报告称，专家因家庭和时间安排等原因，很难吸引到普通的晚间聚会；常客往往是正转向该领域的开发者。应针对这类听众设定每场演讲的深度上限。为不会到场的专家而设计的项目，会失去实际到场的人。
• 品牌承诺。 如果活动承诺每届都带来令人难忘的时刻（一次“当头棒喝”，或一场让人一个月后仍在讨论的演讲），光靠筛选无法兑现。应建立共同认可的精彩演讲框架，并在评审时应用；录用后通过 samber/dev-event-organizer-skills@event-speaker-experience 提供辅导和排练。如果本届没有足够的辅导资源，就应降低承诺，而不是公开失信。

候补名单与拒稿

在通知任何人之前，先建立候补名单。有文档记载的一种规模是：单轨会议安排中，每场已录用演讲对应约 5 场备选演讲；请根据你的拒稿风险调整规模，并说明这是推算值。没有公开数据表明候补演讲实际上会有多大概率递补，因此绝不要告诉候补演讲者他们的机会有多大——告诉他们何时会得到结果即可。

拒稿沟通深度排序（默认排序，并非硬性规定——Q4 和 Q5 会重新排序）：

• 工作量（组织者处理每次拒稿所需的时间，乘以多数为拒稿的投稿池）：逐份投稿反馈 > 拒稿并重申评审标准 > 表单拒稿
• 价值（投稿者下一届再次投稿的比例，以及有助于充实明年投稿池的声誉）：逐份投稿反馈 > 拒稿并重申评审标准 > 表单拒稿
• 效率：拒稿并重申评审标准 > 表单拒稿 > 逐份投稿反馈

支配关系检查：3 组配对，严格支配关系为零。 仅仅因为结构如此而看起来干净，绝不代表通过检查。

价值和工作量的排序相同，因此一个机制就足以阻断所有配对：能带来更多投稿者回流的做法，必然需要组织者在每次拒稿上投入更多时间。没有其他已列出的因素能够阻断或挽救某组配对。效率排序完全取决于以下论述。

• 拒稿并重申评审标准——默认做法：使用一份语气温和的模板，并附上征稿启事中公布的评审标准和录取比例。录取比例确实发挥作用——它用比例说明拒稿是算术结果，而非对投稿者的评判，而且不会增加处理每位投稿者的成本。
• 表单拒稿——简短、友善且内容一致的通知。成本低，也诚实；除了避免不作回应之外，并无额外好处。
• 逐份投稿书面反馈，资源紧张时应优先考虑的选项：采用评审意见，并编辑措辞，使语气得体。适用条件：
  • 投稿池足够小，能够为所有投稿撰写反馈。
  • 投稿者中首次投稿者占比很高，且扩大演讲者群体是目标。
  • 评分标准本就要求提供书面意见，因此文本已经存在，边际成本近乎为零，只需进行编辑。

至少有一个常见的征稿平台可以在拒稿通知中附上个人反馈，因此限制因素是编辑时间，而非机制本身。

盲审流程中有一个值得借鉴的结构性细节：录用的演讲者会解除匿名，因为需要有人协调后勤；拒稿通知则会在评审团队始终不知道投稿者身份的情况下发出。请决定你自己的哪些人员可以看到被拒稿者的姓名。模板和发送顺序见 references/decision-communication.md。

失败模式

• 匿名审查作秀。 宣布采用盲审，之后却在没有公布阶段划分的情况下重新引入身份信息；或者因为工具「会处理」，就放任未管理的自由文本泄露信息。公布身份信息会在哪个阶段引入，或者诚实地进行实名审查。
• 没有评分标准的共识。 委员会开会讨论，却没有书面评分标准，最后会向最能言善辩的人妥协，六个月后也无法解释为何拒绝某个提案。开始评分前先把标准写下来。
• 因疏忽而产生的利益冲突。 没有简报，也没有回避规则，结果评审给同事的提案打分，因为没人说过不该这么做。这条规则只需一段话，而且只有在评分前才能奏效，事后就晚了。
• 候补名单承诺。 「你排第一」和「我们肯定有名额」都是没人能兑现的承诺。承诺一个日期，绝不要承诺一个概率。
• 悄无声息地平衡安排。 项目契合度审查为了兼顾多样性，放弃了得分更高的演讲，却没有记录理由。下一届委员会会在不知情的情况下重新争论，而提交者询问时，没人能给出答复。
• 把超额投稿误判为分会场不足。 投稿数与名额数的高比值反映的是需求，而不是在当前周期中途增加分会场的即时信号。分会场数量已在上游由 samber/dev-event-organizer-skills@event-format-selection 确定；需求评估应归入 samber/dev-event-organizer-skills@event-market-fit。
• 组织者自行入选。 组织者提交演讲、相互评分，最后用团队成员填满议程。应披露、回避、设限，并在征集截止前确定规则。
• 把产品推介当作经验分享录用。 供应商的提案看起来不错，最终呈现的却是产品演示。审查时应用经验传递测试，并在录用通知中说明商业内容规则，让讲者在撰写演示文稿前就能知晓。
• 知识现状过时。 议程提前数月定稿，却承诺「最新内容」，最终带来的却是上个季度的消息。在快速发展的领域，应留出名额到较晚阶段再确定。
• 面向缺席的受众设计演讲。 演讲针对的是不会到场的专家，而现场听众是正在进入该领域的开发者。根据出席情况（Q12）了解现场受众。
• 将受邀演讲纳入同一评审池。 邀请讲者的原因正是其身份，因此若与公开征集的提案一同进行盲审，就会同时损害两者。应提前确定其评审流程（Q7）。

衡量指标

标注有来源的数据；其他所有指标都是你自行设定的门槛，展示时应注明这一点。

• 录用率（校准参考值，不是目标）：

  • PyCon US 2025 从 938 份提案中选出了 15%。
  • KubeCon EU 2024 从 2,541 份提案中录用了 9%。
  • 学术会议的比例更高——CHI 2024 为 26.4%——但其遴选逻辑不同，不能直接照搬。

  记录自己的数据；如果录用率在不同届之间大幅波动，通常说明改变的是征集方式，而不是投稿池。

• 结果与既定目标的匹配情况（混合）：统计录用名单中的首次演讲者、雇主分布以及本地与外地讲者的比例，并与承诺的目标进行比较。活动层面存在一项有记录且量化的目标——「在可能的情况下，至少 50% 的讲者是首次演讲者」，以及至少 25% 来自最终用户公司——值得注意的是，这并未列入评审实际使用的评分标准。如果设定目标，请在评审开始前决定它是目标还是门槛。

• 评审员覆盖情况（自行设定）：每位评审员负责的提案数，以及因回避而损失的评审员人数。如果委员会无法在预定时间内审完投稿池，那就是发现得太晚的流程失败。

• 被拒提交者的再次投稿率（自行设定）：统计被拒的提交者有多少人在下一届再次投稿。这是检验拒绝通知环节是否值得投入成本的唯一真实方法。

选出两到三项指标，写明每项会触发哪些修改，并在活动开始前记录，而不是事后再记。

征稿评审示例

• “我们收到 180 份提案，只有 24 个名额，还有 5 位可以参与评审的组织者——该如何开展评审？”
• “为我们的双赛道会议征稿启事（CFP）组建评审委员会并制定评分表。”
• “我们的 CFP 承诺进行盲审。实际该如何操作？盲审又不能解决什么问题？”
• “我们的一位评审人与某位投稿者有合作关系。规则是什么？”
• “撰写录用、拒绝和候补邮件，并告诉我应该按什么顺序发送。”

预期输出：一份遴选计划，包含：

1. 委员会模式和规模，以及明确的角色分工。
2. 详细列出的评分标准。
3. 匿名化的执行深度，以及身份信息在哪个确切环节重新引入。
4. 利益冲突说明，以及仲裁兜底方案。
5. 轮次结构和截断规则，在排名前明确说明。
6. 节目契合度审查，并记录其中的权衡。
7. 候补名单和通知顺序，以及邮件草稿。
8. 为下一届活动记录的指标。

评审开始前，按章节逐一提交内容以供确认。

参考资料

• references/committee-models-and-rubrics.md - 两套既定评分标准及其原始评审标准措辞、逐级筛选各阶段的百分比、字母等级汇总机制、委员会角色，以及一份正面和负面评分的示例。
• references/decision-communication.md - 录用、拒绝和候补模板、通知顺序和解除匿名时的信息不对称、按演讲者处理重复录用的方式，以及工作流所需的工具功能。
• references/program-fit-field-reports.md - 节目契合度检查：含商业内容规则的经验迁移测试、主题新颖度和延后确定的名额、适合混合受众的深度梯度说明、受众水平的实际情况，以及品牌承诺链；每项均标注为未发表。
• references/selection-evidence-and-gaps.md - 录用率和超额投稿基准、多元化规则和目标、评审小组组成规则，以及此领域未记载事项的明确清单。

另请参阅同一系列中的内容：

• samber/dev-event-organizer-skills@event-cfp-design - 设计本技能要执行其政策的征稿启事：时间线、表单、公开标准和匿名政策。
• samber/dev-event-organizer-skills@event-speaker-sourcing - 将受邀演讲者纳入本活动日程的渠道；评审开始前先确定其所属通道。
• samber/dev-event-organizer-skills@event-speaker-experience - 从录用邮件中“我们接下来需要什么”一行开始接手：收集相关材料并处理后续所有事务。它不会处理拒绝或候补通知，这些仍由本技能负责。
• samber/dev-event-organizer-skills@event-schedule-design - 后续将已录用名单安排进赛道结构。
• samber/dev-event-organizer-skills@event-sponsor-agreement - 规定编辑独立性条款，为赞助商关联演讲者上限提供依据。
• samber/dev-event-organizer-skills@hackathon-judging - 按不同标准、在活动当天评审活动中开发的项目；这与评审演讲提案不同。
• samber/dev-event-organizer-skills@workshop-program-design - 负责处理动手实践类提案引出、而演讲提案不会涉及的形式特定问题：讲师能否在所提供的容量条件下开展活动，以及练习是否适合现场规模。