event-cfp-design

活动征稿设计

你负责设计技术活动的征稿启事：潜在演讲者阅读的公开材料、他们填写的表单，以及双方承诺遵守的时间安排。

你不负责：

• 为投稿评分或遴选投稿——评分表、评审委员会和通知属于 samber/dev-event-organizer-skills@event-talk-selection。
• 在征稿之外招募演讲者——这条并行渠道属于 samber/dev-event-organizer-skills@event-speaker-sourcing。

征稿提供的演讲形式由 samber/dev-event-organizer-skills@event-format-selection 在上游选定，是设计征稿时的输入。

以下每项建议都是默认做法，而非铁律——它会随情境和执行者而变化。访谈结束后，请根据你对主办方的了解，重新排列本技能中的每组选项：现有的导师池、分布在各地的国际社区、已付费使用的工具，或严格的议程公布日期，都可能颠覆默认顺序。

访谈

每次只问一个问题，尽可能采用选择题。设置问题 4–6，是因为下面的选项在见效时间、回报的持久性和所需投入方面差异很大——不能替用户选定默认排名。

1. 活动日期是什么时候？已选定哪种结构——活动形式、分论坛数量、演讲形式组合？如果尚未确定结构，请先转到 samber/dev-event-organizer-skills@event-format-selection：征稿不能提供尚未选定的演讲形式。
2. 谁主办活动：社区大会（通过公开征稿填满议程），还是厂商／用户大会（大部分内容受邀，征稿只填补其中一部分）？
3. 这是首次征稿还是再次举办？如果之前举办过征稿：收到了多少份投稿、需要填补多少个名额？演讲者或评审提出过哪些意见？
4. 距离必须公布议程还剩几周？（严格的日期会限制时间安排选项——若剩余时间低于最低要求，应取消公开征稿，而不是压缩流程。）
5. 本届活动是一次性举办，还是要积累成年度资产？（若目标是持续积累，应提升那些见效较慢、能建立信任的选项优先级：匿名评审、辅导，以及逐年沿用的已公布评审标准。）
6. 投入上限是多少：评审委员会人数、主办方工时，以及谁会在开放征稿期间持续推广？
7. 预算实际能向演讲者承诺什么——至少提供免费门票，还是能报销差旅或提供补助，或提供更多？未经确认的资金不得写进征稿启事。
8. 演讲者多样性是否是明确目标？是否有能力在发布征稿启事之外主动开展招募？
9. 已有哪些资产可用于重新排列选项的优先级：可发布的往届入选提案、志愿导师池、有签证准备周期要求的国际演讲者社区，或已经在使用的征稿工具？

社区大会与厂商大会

无论哪种活动，投稿者都是开发者。改变征稿设计的是活动的主办方（与 samber/dev-event-organizer-skills@event-format-selection 讨论的分类一致）：

• 社区大会——征稿是议程的主要投稿渠道；资料中明确指出，业内规范禁止推销产品，并规定“赞助商绝不能购买演讲者名额——绝对不行”（DevOpsDays 筹办指南）。本技能中的所有资料都来自这一类活动。
• 厂商／用户大会——内容大多受邀而来，并围绕厂商架构组织（据 swyx）；如果设有征稿，则用于填补精心策划的整体议程中的社区内容部分。下面的选项仍适用于这部分，但时间安排还要配合厂商的发布日程，而不仅仅是演讲者的出行安排。

若建议因活动类型而异，请说明该建议针对哪一类活动。

工作流

1. 进行访谈；确定职责归属（Q2）。
2. 根据选定的结构（Q1）提供相应的提交形式：征集内容所提供的形式应恰好满足该结构的需求，不多不少。为每种形式设置独立的提交类型，并配置各自的字段；比单一“演讲”选项更丰富的菜单有实践依据（PyCon US 提供演讲、教程、西班牙语 charlas 和海报——charla 是具体的非英语包容机制）。
3. 从下方的菜单中设定时间线，并根据活动日期和日程公布日期倒推（Q4）。
4. 根据表单深度菜单和 references/submission-form-catalog.md 设计提交表单；设定每人提交上限（唯一有来源的示例：PyCon US 将每人提案上限设为 3 个）。
5. 将评审标准写入征集内容本身——见下方的已发布标准部分；并从匿名化菜单中决定匿名处理方式。在征集内容中说明该方式，以及评审何时会看到身份信息。
6. 在征集内容中明确说明演讲者福利：列出有来源支持的最低保障和下方的诚信规则。预算尚未确认的福利，绝不对外承诺（Q7）。
7. 从菜单中选择针对首次演讲者的支持等级。
8. 根据目录参考，列出所选设计需要的工具功能（表单字段、日程安排、评审模式、消息通知）——先列功能，再列工具。
9. 规划整个征集开放期的宣传（见宣传部分——刻意保持精简，并如实说明）。
10. 关闭征集并交接：征集内容应说明投稿者何时会收到回复；投稿交给 samber/dev-event-organizer-skills@event-talk-selection，受邀演讲者渠道通过 samber/dev-event-organizer-skills@event-speaker-sourcing 并行开展，最终录用的日程交给 samber/dev-event-organizer-skills@event-schedule-design。

在公开发布前，按部分逐项展示整理好的征集内容（时间线、表单、标准、福利）以供确认——已发布的 CFP 是对陌生人的承诺，发布后的悄然修改会损害信任。

如果你的运行环境支持持久记忆，请记录所选时间线锚点、匿名处理方式、上限、已发布标准，以及最重要的内容：哪些衡量阈值会促使你在下一届调整每项选择。

CFP 时间线

排序（默认排序，并非定律——Q4、Q8、Q9 可重新排序）：

• 投入（准备时间 + 整个开放期持续宣传）：长开放期 > 标准开放期 > 压缩至最低期限
• 价值（覆盖范围、面向代表性不足群体的宣传时间、早期需求信号、国际旅行准备时间）：长开放期 > 标准开放期 > 压缩至最低期限
• 效率：标准开放期 > 压缩至最低期限 > 长开放期

支配关系检查：3 对比较，没有严格支配关系——这只是按构造得出的干净结果，按构造得到绝不等于通过。 价值和投入的排序相同，因此一个机制就能阻断所有三对比较：价值排序领先的档位，成本也严格更高；不存在任何档位在价值上至少相当、成本却更低。没有列出第三个可以阻断或挽救比较的维度。该检查一无所获；排序完全依赖下方的论证。

有来源支持的最低期限（DevOpsDays 组织指南）：“尽早开放 CFP，并至少在活动开始前 6-8 周截止。”征集期应“至少开放一个月”，并留出“至少 2 周来考虑提案并填补任何空缺”。原因在于演讲者的日程，而非组织者的安排：“人们通常至少需要 4-6 周来安排旅行或请假。”

• 标准窗口 - 默认方案：开放约两个月，在活动开始前 8 周以上截止，并在间隔期内评审。适合受众已知的复办活动。
• 压缩至下限 - 按来源允许的最短时间安排：开放约 4 周，在活动开始前 6-8 周截止，评审 2 周 - 从开放到活动总计约 10-12 周。若日期已确定，这是可行的安排；再短就不行。
• 长窗口 - 资源不足时的选项：DevOpsDays 自己的主时间线将 CFP 发布定在活动前 7.5 个月，将投稿投票定在活动前 4.5 个月，将议程发布定在活动前 3.5 个月 - 从评审到发布约有 3 个月。这种安排覆盖面最大，也是唯一有充裕时间安排导师配对和满足签证办理时限的选项；但在每轮效率评估中它都会落败，因为真正的成本不是日历时间，而是要持续数月的宣传（见失败模式）。适用条件：首届活动，需借助 CFP 投稿量衡量售前需求（将这一判断交给 samber/dev-event-organizer-skills@event-market-fit）；邀请国际演讲者；或导师计划需要在截止日期前留出时间。

快速变化领域中的临近活动保留名额（菜单之外的说明，适用于所有档位）：快速变化领域的组织者反映，去年的热门话题几个月内就会过时。窗口越长，投稿与登台之间的间隔就越大。在公开征集之外自行预留一定数量的名额，在活动临近时通过邀请填补，并在征集说明中明确告知 - 投稿者有权知道自己竞争的名额数量。征集说明中任何标榜「前沿」的主题，在评审时都需要同样检查其时效性。

先邀请头部讲者，再发布征集（菜单之外的说明，适用于所有档位）：在公开征集填满议程之前，先手动邀请知名讲者，再通过征集填补其余名额。

• 哪些人算头部讲者。 能吸引受众的知名人士和知名公司。通过 samber/dev-event-organizer-skills@event-speaker-sourcing 寻找并评估他们；赞助关系绝不能替代资格证明。
• 为何手动邀请。 参会者看到的是议程，而不是投稿渠道。他们不会知道哪些演讲是通过征集选出的，因此手动邀请的头部讲者与录用投稿在台上看起来并无二致。征集则用于填补剩余名额，带来封闭名单可能遗漏的声音。
• 后备顺序。 先寻找头部讲者。如果候选名单填不满议程所需的名额，就由征集补足。绝不要为尚未确认的讲者空留名额。
• 尽早联系。 最受追捧的公司和讲者会提前很久排满日程，也会收到许多活动的邀请。在征集开放前就联系他们，最迟应在长窗口的起始节点或更早。等到临近活动再邀请，日程早已排满。
• 保持征集透明。 在征集说明中写明在征集之外预留了多少名额（由组织者自行决定），如上面的临近活动保留名额说明所述。公开议程无需标明每场演讲通过哪种渠道入选。
• 着眼长远。 对方拒绝邀请或无法参加，意味着这段关系尚未建立，而不是线索已失效。保留名单，在两届活动之间保持联系，并在下一届活动时附上最新的名额说明再次邀请。
• 若差旅是障碍，主动牵线。 如果讲者不愿前往你的城市，就将他们介绍给另一座城市的组织者。讲者仍保持联系，另一场活动也能获得演讲内容，你则能为下次邀请积累善意。分享联系方式前，务必先征得讲者同意。

低于下限 - 活动距今不足约 10 周，或截止日期距活动不足 6 周 - 就应取消公开 CFP，而不是降低标准：讲者无法在来源所述的 4-6 周内安排差旅，因此议程应通过 samber/dev-event-organizer-skills@event-speaker-sourcing 定向邀请来安排。

提交表单深度

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

• 工作量（演讲者填写阻力 + 表单构建 + 每份投稿的审核时间）：extended > standard > minimal
• 价值（审核区分能力 + 节目平衡与后勤数据）：extended > standard > minimal
• 效率：standard > minimal > extended

支配关系检查：3 对，严格支配关系为零——这只是结构设计上的结果，结构设计上的结果绝不算通过。 价值和工作量的排序方向相同，因此三对都以同样的方式不通过：价值更高的档位成本也更高。没有其他内容能阻止或挽救任何一对。效率这一项依据下文论述，而非通过检查得出。

• Standard - 默认选项：标题、上限约为 100 词的摘要、单独的「为什么是我」背景说明字段、形式选择、目标受众水平、简介、可选的过往演讲链接。摘要与背景说明分开是关键设计：这样评审者可以分别评估主题质量和演讲者契合度，而不必从一个文本框里费力拆分信息（依据 swyx 的 CFP 建议——标题的重要性「是摘要的两倍」，摘要应简短，并设置一个值得使用的独立背景说明字段）。字段详情、带来源的示例和反面示例见 references/submission-form-catalog.md。
• Minimal - 标题、摘要、简介。几乎零工作量使它在效率上排第二，但这种省事部分只是虚假的节省：每删去一个字段，都会以审核时的猜测和后续邮件的形式付出代价。适用于聚会规模的征集，或小型邀请制与 CFP 混合的征集。
• Extended - 资源最稀缺的选项：增加按形式设置的条件字段、录制/同意复选框、纳入表单的差旅补助申请（依据 PyCon US），以及结构化大纲。启用条件：设有补助计划（在表单中勾选优于单独申请流程）、结构提供的形式确实有不同要求，或委员会规模足以利用额外的结构。

匿名化立场

排序（默认原则，并非硬性规定）：

• 工作量（评审流程规范 + 演讲者须知 + 两阶段机制）：强制匿名 > 自愿匿名 > 实名评审
• 价值、投稿者公平性与信任：强制匿名 > 自愿匿名 > 实名评审
• 价值、评审期间用于塑造议程的数据（姓名认知度、本地与外地的比例、演讲者契合度判断）：实名评审 > 自愿匿名 > 强制匿名
• 效率：实名评审 > 自愿匿名 > 强制匿名

支配关系检查：3 组比较，没有严格支配关系——只有按构造设计才能做到这一点，而按构造设计绝不算通过。 一种机制阻断了全部 3 组比较，而且并非常见机制：两个价值轴恰好完全相反，因此在公平性上领先的选项，在议程塑造数据方面就会落后，没有任何选项能在两者上都至少持平。任何一组比较都不会涉及工作量。此处检查未发现问题——效率这一项的依据如下。

两个价值轴确实相互冲突——这正是需要做出决策的原因，证据也各有支持。Per swyx：“盲审 CFP 对公平性有一定程度的重要性……据我所知，大多数 CFP 并非匿名。” PyCon US 是一个真正实施盲审的大规模反例：“在初步评审期间，评审者看不到提案作者的信息”。

• 实名评审——据 swyx 的观察，这是业界事实上的默认做法；对于首次举办、规模较小且由 2-3 人组成的委员会手动调整议程平衡的 CFP，这里也将其作为默认选项。只有发布明确的评审标准，让标准承担匿名评审未能实现的公平性保障，实名评审才算诚实。
• 自愿匿名——工具方面的默认选项（目录中引用的 3 个示例平台里，有 2 个将匿名化作为可选模式提供）。应将其视为平台功能，而非公平性立场：同时包含实名和匿名投稿的投稿池，评审条件并不一致。
• 强制匿名——处于劣势的选项：在公平性价值和工作量方面都排在首位，因此效率永远不会选择它。PyCon 的实施方式揭示了它的实际成本：评审分两阶段进行（议程最终确定前必须公开身份信息，以便考虑平衡、差旅和姓名认知度）；还必须告知演讲者自行避免在标题和自由文本中透露身份，因为平台隐藏的是作者字段，而不是作者写下的内容。启用条件：明确将公平性列为目标（Q8），且委员会有能力采用两阶段流程。若启用，应在征集说明中公布具体机制，包括身份信息何时公开；否则就会沦为盲审作秀（见失败模式）。

公开发布的评审标准

将标准直接写进征稿启事。引用的模板是 DevOpsDays 的六项内容政策，在面向演讲者时公开说明（references/published-call-evidence.md 中有原文）：

• 绝不提供由赞助商出资购买的演讲名额。
• 优先选择新内容，而非已发布的材料。
• 平衡本地与外地演讲者。
• 积极优先考虑新演讲者。
• 鼓励大胆的主题。
• 将特定于工具或产品的演讲引导至开放空间，而不是直接拒绝。

征稿启事会将厂商推介引导至更适合的形式；而这只有在活动策划阶段预先安排了开放空间环节时才行得通。

如果没有开放空间环节，请换一种表述：初创公司或厂商可以演讲，但观众带走的应是经验教训或灵感，而不是产品；并且不得在台上进行商业演示。如果采用这条标准，请将其作为第七项标准发布——经验传递测试——并明确措辞，让创始人在投稿前可以自行判断：“如果观众明天就忘了你的产品名称，他们还会记住这条经验吗？”samber/dev-event-organizer-skills@event-talk-selection 会在评审时应用这项测试，录取邮件也会用一句话重申商业内容规则。

发布前的诚实性检查：按照 swyx 的说法，组织者会优化议程，以“售出票、打造丰富多元的内容组合，并为明年的活动售票，大致按此顺序”。如果知名度和主题组合事实上会影响遴选——它们确实会——标准就不能假装不会。发布你真正会执行的标准，并让社区主导的硬性规定（“绝不——没有例外”）作为唯一不可妥协的要求。

征稿启事中说明的演讲者福利

• 最低保障：“至少，所有演讲者都应获得一张免费活动门票”（DevOpsDays 组织指南）。请明确写出；征稿启事对福利只字不提，会让人觉得什么都没有。
• 差旅：如果资金允许，报销差旅“是合理的资金用途”。还应向组织者重申一个有记录的注意事项：直接付款“可能会带来复杂的税务、签证以及利益冲突／雇佣协议问题”。如果设立差旅补助，可沿用 PyCon US 的政策框架：将补助定位为帮助演讲者参会，而非奖励演讲质量；每个录取提案最多补助一人；并明确请有能力自行承担参会费用的演讲者主动退出有限的补助名额竞争。
• 酬金：业界没有统一标准，但如今有两个具名的社区活动会在各自的征稿启事中公布固定金额：!!Con 为每位演讲者提供固定的“$256 (USD)”酬金，该金额在 2018-2024 年各届活动中保持不变；ffconf（英国）则注明“£500 honorarium”，并提供全额差旅费、酒店和餐食。这两个金额并未趋向同一标准——应将其视为参考点，而非市场价格或“行业标准”。如果用户希望制定酬金政策，请先列出这两个金额，再根据自身预算以及法律／税务审核结果确定实际金额。
• 适用于上述三项的规则：征稿启事要准确说明演讲者会获得什么，不得承诺预算尚未确认的任何福利。

首次演讲者支持

排序（默认原则，并非铁律）：

• 投入（设置 + 每位演讲者所需时间）：提案辅导 > 实例示范 > 鼓励文案
• 价值（通过审核的新声音投稿）：提案辅导 > 实例示范 > 鼓励文案
• 效率：实例示范 > 鼓励文案 > 提案辅导

支配关系检查：3 组配对，没有严格支配关系——这只是人为构造出的结果，绝不代表通过。 价值和投入的排序相同，因此同一种机制会阻止所有配对：价值更高的档位，成本也严格更高。没有其他维度能改变任何一组配对的结果。此项检查毫无验证作用；请根据以下比例进行论证。

• 实例示范——默认选项：发布过去获选的提案作为参考；PyCon US 会引导首次演讲者查看往届提案。首届活动没有存档——退回一个档位，依靠已发布的标准和划分合理的表单来提供参考。
• 鼓励文案——投入几乎为零，应始终包含，但单独使用远远不够：明确写出“优先考虑新演讲者”本身，就是一项有来源依据的已发布标准。
• 提案辅导——资源最匮乏的选项：在 CFP 期间单独安排时间，组织结构化的投稿前结对辅导。PyCon US 的提案辅导计划是有文档记录的机制示例。推广条件：存在志愿导师池（Q9），且开放期足够长，能在截止前安排导师结对——因此此档位与长期开放的时间安排相绑定。

推广

没有会议组织者或 CFP 平台发布过按渠道拆分的投稿来源数据——应明确说明这一点，而不是凭空编造渠道排名。以下三点有来源依据且至关重要（原文见 references/published-call-evidence.md）：

• 在整个开放期持续推广，而不只是在开放时推广——长期开放档位的投入就在于此。
• 一个具体的发布顺序（Write the Docs）：撰写公告，将其发布到博客，再发推文链接至博客文章，然后等待一到两小时再群发邮件——这段延迟能让社区在更广泛的邮件列表看到内容之前发现错误。
• 公平性警示（DevOpsDays）：“科技行业中代表性不足的人群回应 CFP 的可能性要低得多。” 如果多样性是目标（Q8），就要主动触达这些社群；仅发布公开征集无法实现这一目标。有两种有来源依据的主动触达机制：维护一份列出具体社群组织名称的清单，并附上模板推广邮件（jlengstorf/awesome-speaker-diversity）；以及 PyCon 2010 自行分类整理的 CFP 分发目标清单，为在会议规模上采取同类做法提供了具体先例。

失败模式

• 标准未公开。 评审标准已经存在，但征稿通知中没有公布——拒稿显得随意，下一年的投稿流程也会因此受影响。已有实践是在征稿通知中列出六项标准。
• 福利承诺缺少政策依据。 预算尚未确认，就发布差旅或酬金相关说明，结果陷入已有案例提到的税务、签证和利益冲突陷阱。征稿通知只说明已确认的最低保障。
• 盲审流于形式。 宣布必须盲审，却不处理自由文本中的身份泄露；或者在没有公布阶段划分的情况下，悄悄恢复身份信息来调整议程。公布具体机制，或者选择实名评审。
• 过时的长征稿期。 在活动前 7.5 个月开放征稿，却只发布一次公告，也没有持续宣传，整个征稿期中段都毫无动静。长征稿期意味着要承诺持续宣传，而不只是提前开放。
• 征稿期低于最低要求。 在活动前不到 6 周截止，或开放时间不到一个月，等于要求讲者无视已有案例所反映的 4-6 周差旅现实。取消公开征稿，改为邀请制。
• 所有内容都塞进一个文本框。 要求摘要同时涵盖主题、大纲和“为什么是我”，就无法对其中任何一项进行评分——拆分表单的目的，就是让评审能区分主题质量和讲者匹配度。
• 征稿通知提供了错误的形式选项。 通知列出的形式不属于所选结构（或漏掉结构中已有的形式），会导致收到无法安排的投稿。形式菜单应由上游决定，而不是在发布征稿通知时决定。
• 没有检验标准的供应商条款。 发布“禁止销售宣传”，却没有提供投稿者可据以判断的标准。创业者会自我审查，不再分享有用经验，而宣传内容仍会漏网。应公布“经验能否迁移给他人”这一问题。
• 在快速变化的领域提前数月敲定所有时段。 征稿截止时，议程已经排满，活动当天最热门的话题却缺席。预留征稿范围之外的时段，并明确说明。
• 把投稿过多视为失败。 拒绝大多数投稿是健康征稿流程的常态（见衡量指标）——应对投稿量的办法是提升评审能力，而不是缩小征稿范围。

衡量指标

已有文档记录的基准会明确标出；其余都是你在开放征稿前设定的阈值。

• 投稿数与名额之比：PyCon US 2025 接受了 938 份提案中的 15%，约为 6.5:1。Swyx 的基准指出，成熟会议的投稿池通常为 200 到 800-1,200 位申请者，因此热门的单轨活动出现 8-30 倍的超额投稿很正常。作为发布前的需求判断，即使首次征稿达到 2-3:1，也是很强的信号——这一是否继续的判断应由 samber/dev-event-organizer-skills@event-market-fit 负责。
• 首次投稿者占比：DjangoCon Europe 2024 收到 138 位投稿者提交的 174 份提案，其中 51 位是首次演讲者——投稿者多样性是活跃度的信号，不只是投稿量。
• 不符合政策的投稿占比：已被公布标准排除的投稿在总投稿中的比例（例如，精选投稿池中的供应商宣传）——占比较高，说明征稿通知中的标准没有传达清楚。
• 投稿时间分布：查看投稿在征稿期内的到达时间；中段投稿低迷，说明失败的是宣传计划，而不是征稿期长度。

选择 2-3 项，记录每项指标会促使下一届做出什么调整，并在活动前记录这些指标。

征集提案（CFP）调用示例

• “我们的首届 DevOps 大会将在 9 个月后举行——从头到尾帮我们搭建 CFP。”
• “为期两天的社区大会编写 CFP 页面：时间安排、表单、评审标准、福利。”
• “我们的 CFP 应该匿名吗？去年有人抱怨入选的总是同一批人。”
• “活动还有 10 周就要举行了，我们还没有任何演讲——现在还来得及发起 CFP 吗？”

预期输出：一份 CFP 设计简报，包括：

1. 根据活动日期倒推制定的时间安排，标明开放、截止和通知时间节点。
2. 按提供的形式列出的表单字段，以及投稿数量上限。
3. 发布的评审标准文本。
4. 匿名处理方案，以及征稿启事中会说明的具体做法。
5. 演讲者福利说明。
6. 推广和外联说明，以及有来源依据的公平性警示。
7. 移交给评审、邀约和排期环节的计划。

按章节逐一呈现，以便在征稿启事公开前进行确认。

参考资料

• references/submission-form-catalog.md - 逐字段目录及示例、PyCon 提供的四种形式、投稿数量上限、包含具体平台示例的工具功能检查清单，以及一份正反面表单示例。
• references/published-call-evidence.md - DevOpsDays 的时间安排和六项评审标准原文、演讲者福利和差旅补助说明、匿名处理正反两方面的证据、首次演讲者相关机制、针对代表性不足群体回应情况的警示和两种有来源依据的外联机制、有来源依据的推广顺序模式，以及超额投稿基准。

另请参阅同一集合中的：

• samber/dev-event-organizer-skills@event-format-selection - 选择本征稿启事所提供演讲形式对应的活动结构。
• samber/dev-event-organizer-skills@event-talk-selection - 评审并遴选本征稿启事征集的内容：评分表、委员会、偏见控制、通知。
• samber/dev-event-organizer-skills@event-speaker-sourcing - 并行开展的特邀演讲者邀约渠道；若时间安排导致无法开放 CFP，也可作为备选方案。
• samber/dev-event-organizer-skills@event-speaker-experience - 落实本征稿启事承诺的福利，包括按演讲形式说明录制政策；不会重新讨论此技能明确留空的酬金问题。
• samber/dev-event-organizer-skills@event-schedule-design - 将已接受的节目安排到后续的分会场结构中。
• samber/dev-event-organizer-skills@event-market-fit - 负责解读 CFP 超额投稿的需求情况；本技能将测量工作交由其处理。