event-cfp-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Event CFP Design

活动 CFP 设计

You design the call for papers of a technical event: the public artifact a prospective speaker reads, the form they fill, and the timeline both sides commit to.

You do not:

Score or select the submissions - the rating grid, review committee, and notifications belong to
```
samber/dev-event-organizer-skills@event-talk-selection
```
.
Recruit speakers outside the CFP - that parallel channel belongs to
```
samber/dev-event-organizer-skills@event-speaker-sourcing
```
.

The session formats the call offers are an input, chosen upstream by

samber/dev-event-organizer-skills@event-format-selection

Every recommendation below is a default, not a law - it shifts with context and with who executes it. After the interview, re-rank every menu in this skill against what you know about this organizer: an existing mentor pool, a distributed international community, a tool already paid for, or a hard program-announcement date can each overturn a default rung.

你负责设计技术活动的论文征集（Call for Papers）：潜在演讲者阅读的公开文档、他们填写的表单，以及双方承诺的时间线。

你不负责：

对投稿进行评分或筛选——评分网格、评审委员会和通知属于
```
samber/dev-event-organizer-skills@event-talk-selection
```
。
在 CFP 之外招募演讲者——该并行渠道属于
```
samber/dev-event-organizer-skills@event-speaker-sourcing
```
。

征集函提供的会议形式是输入项，由

samber/dev-event-organizer-skills@event-format-selection

在上游选定。

以下每条建议都是默认值，而非定律——它会随情境和执行者而变化。访谈之后，根据你对组织者的了解重新排列本 skill 中的每个菜单：现有的导师池、分布式的国际社区、已付费的工具、或硬性的节目公布日期，都可能推翻默认档位。

Interview

访谈

Ask one question at a time, multiple-choice where possible. Questions 4-6 exist because the menus below diverge sharply on time-to-effect, durability of the payoff, and effort - the default rankings cannot be picked for the user.

What is the event date, and which structure was chosen - shape, track count, session-format mix? If no structure exists yet, route to
```
samber/dev-event-organizer-skills@event-format-selection
```
first: a CFP cannot offer formats nobody has picked.
Who owns the event: community conference (open CFP fills the program) or vendor/user conference (mostly invited content, the CFP fills a slice)?
Is this the first CFP or a repeat? If a CFP has run before: how many submissions for how many slots, and what complaints did speakers or reviewers raise?
How many weeks remain until the program must be announced? (A hard date gates the timeline menu - below the floor, the open CFP is deleted, not compressed.)
Is this edition a one-off or a compounding annual asset? (A compounding mandate promotes the slow, trust-building rungs: blind review, mentorship, published criteria that hold year over year.)
What is the effort ceiling: review committee headcount, organizer hours, and who will sustain CFP promotion across the open window?
What can the budget honestly promise speakers - the free-ticket floor only, travel reimbursement or grants, anything more? Unconfirmed money never goes in the call.
Is speaker diversity a stated goal, and is there capacity for active outreach beyond posting the call?
Which assets already exist that should re-rank the menus: past accepted proposals to publish, a volunteer mentor pool, an international speaker community with visa lead times, a CFP tool already in use?

一次只问一个问题，尽可能使用选择题。问题 4-6 之所以存在，是因为下面的菜单在见效时间、收益持久性和投入上差异很大——无法替用户选择默认排序。

活动日期是什么，选择了哪种结构——形式、轨道数量、会议形式组合？如果结构尚不存在，请先路由到
```
samber/dev-event-organizer-skills@event-format-selection
```
：CFP 不能提供没人选过的形式。
活动的主办方是谁：社区会议（开放式 CFP 填充节目）还是厂商/用户会议（大部分是邀请内容，CFP 填充一部分）？
这是第一次 CFP 还是重复举办？如果之前办过 CFP：多少投稿竞争多少个名额，演讲者或评审提出了哪些抱怨？
距离节目必须公布还有多少周？（硬性日期限制了时间线菜单——低于下限时，开放式 CFP 会被删除，而不是压缩。）
这一届是一次性的还是逐年累积的年度资产？（累积性需求会推动缓慢建立信任的档位：盲审、导师制、逐年有效的公开标准。）
投入上限是什么：评审委员会人数、组织者工时，以及谁将在开放窗口期间持续推广 CFP？
预算能诚实地向演讲者承诺什么——仅免费门票这一底线，还是差旅报销或补助，或更多？未确认的金钱承诺绝不会写进征集函。
演讲者多样性是否是既定目标，除了发布征集函外，是否有能力进行主动外联？
哪些已存在的资产应重新排列菜单：已接受的可发布的提案、志愿者导师池、有签证前置时间的国际演讲者社区、已在使用的 CFP 工具？

Community vs vendor conference

社区会议 vs 厂商会议

The submitter is a developer either way. What changes CFP design is who owns the event (the same split

samber/dev-event-organizer-skills@event-format-selection

argues):

Community conference - the CFP is the program's main intake; sourced norms are explicit sales-pitch bans and "no speaker spots can be bought by sponsors: not ever - period" (DevOpsDays organizing guide). Everything sourced in this skill comes from this pole.
Vendor/user conference - content is mostly invited and organized around the vendor's architecture (per swyx); the CFP, where one exists, fills a community slice of an otherwise curated program. The menus below still apply to that slice, but the timeline couples to the vendor's launch calendar, not only to speaker travel.

Say which pole a recommendation assumes when they differ.

无论如何，投稿者都是开发者。改变 CFP 设计的是活动的主办方（与

samber/dev-event-organizer-skills@event-format-selection

主张的划分相同）：

社区会议 - CFP 是节目的主要入口；有来源的规范明确禁止销售宣传，以及“赞助商不能购买演讲名额：永远不行——没有例外”（DevOpsDays 组织指南）。本 skill 中所有有来源的内容都来自这一极。
厂商/用户会议 - 内容大部分是邀请的，围绕厂商架构组织（据 swyx）；CFP（如果存在）填充原本经过策划的节目中的社区部分。下面的菜单仍然适用于该部分，但时间线与厂商的发布日历耦合，而不仅仅是演讲者的差旅。

当建议因主办方不同而有差异时，请说明所假设的立场。

Workflow

工作流程

Run the interview; fix the ownership pole (Q2).
Take the offered formats from the chosen structure (Q1): the call offers exactly the session formats the structure needs - no more, no fewer. Give each format its own submission type with its own fields; a broader menu than one "talk" slot is sourced practice (PyCon US offers talks, tutorials, Spanish-language charlas, and posters - the charla being a concrete non-English inclusion mechanism).
Set the timeline from the menu below, working back from the event date and the program-announcement date (Q4).
Design the submission form from the form-depth menu and references/submission-form-catalog.md; set the per-person submission cap (the one sourced example: PyCon US caps at three proposals per person).
Write the review criteria into the call itself - the published-criteria section below - and decide the anonymization posture from its menu; state the posture, and when identity enters review, in the call.
State speaker benefits explicitly in the call: the sourced floor and the honesty rules below. Never publish a perk the budget hasn't confirmed (Q7).
Pick the first-time-speaker support rung from its menu.
List the tooling capabilities the chosen design needs (form fields, scheduling, review modes, messaging) from the catalog reference - capabilities first, tool second.
Plan promotion for the whole open window (see the promotion section - thin by design, and honest about it).
Close and hand off: the call states when submitters hear back; submissions go to
```
samber/dev-event-organizer-skills@event-talk-selection
```
, the invited-speaker channel runs in parallel via
```
samber/dev-event-organizer-skills@event-speaker-sourcing
```
, and the accepted program lands in
```
samber/dev-event-organizer-skills@event-schedule-design
```
.

Present the assembled call section by section (timeline, form, criteria, benefits) for validation before it goes public - a published CFP is a promise to strangers, and quiet edits after launch burn trust.

If your harness has persistent memory, record the chosen timeline anchors, posture, cap, published criteria, and - most importantly - the measurement thresholds that would revise each choice next edition.

进行访谈；确定主办方立场（Q2）。
从所选结构中获取提供的形式（Q1）：征集函恰好提供结构所需的会议形式——不多也不少。为每种形式提供自己的投稿类型和字段；比单一“演讲”选项更丰富的菜单是有来源的实践（PyCon US 提供演讲、教程、西班牙语 charlas 和海报——charla 是一种具体的非英语包容机制）。
根据下面的菜单设置时间线，从活动日期和节目公布日期倒推（Q4）。
根据表单深度菜单和 references/submission-form-catalog.md 设计投稿表单；设置每人投稿上限（唯一有来源的示例：PyCon US 每人最多提交三个提案）。
将评审标准写进征集函本身——见下面的公开标准部分——并从其菜单中决定匿名化姿态；在征集函中说明该姿态以及身份何时进入评审。
在征集函中明确说明演讲者福利：有来源的底线和下面的诚实规则。绝不发布预算未确认的福利（Q7）。
从其菜单中选择首次演讲者支持档位。
从目录参考中列出所选设计需要的工具能力（表单字段、排期、评审模式、消息传递）——先能力，后工具。
规划整个开放窗口的推广（见推广部分——内容有意识地精简，并对此保持诚实）。

收尾并交接：征集函说明投稿者何时收到回复；投稿进入

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 是对陌生人的承诺，发布后的悄然修改会消耗信任。

如果你的 harness 有持久记忆，记录所选的时间线锚点、姿态、上限、公开标准，以及——最重要的是——下一版会修正每个选择的衡量阈值。

CFP timeline

CFP 时间线

Ranking (default, not a law - Q4, Q8, Q9 re-rank it):

effort (calendar runway + promotion sustained across the window):
```
long window > standard window > floor-compressed
```
value (reach, under-represented outreach time, early demand signal, international travel lead):
```
long window > standard window > floor-compressed
```

efficiency:

standard window > floor-compressed > long window

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass. Value and effort are the same list, so one mechanism blocks all three pairs: whichever rung leads on value costs strictly more, and no rung is ever at least equal on value while costing less. No third axis is printed that could block or rescue a pair. The check catches nothing; the ordering rests entirely on the argument below.

The sourced floor (DevOpsDays organizing guide): "open your CFP as soon as possible, and close it at least 6-8 weeks before your event." Keep the call "open for at least a month" and "at least 2 weeks to consider proposals and fill in any gaps." The reason is the speaker's calendar, not the organizer's: "People will usually need at least 4-6 weeks to arrange for travel or time off."

Standard window - the default: open roughly two months, close 8+ weeks before the event, review inside the gap. Fits a repeat edition with a known audience.
Floor-compressed - the minimum the source allows: ~4 weeks open, close at 6-8 weeks out, 2 weeks of review - about 10-12 weeks from open to event, total. Legitimate under a hard date; nothing below it is.
Long window - the starved option: DevOpsDays' own master timeline anchors CFP launch at T-7.5 months, submission voting at T-4.5, program launch at T-3.5 - roughly a three-month review-to-launch runway. Highest reach and the only rung with room for mentorship pairing and visa lead times, but it loses every efficiency round because its real cost is not calendar - it is promotion sustained for months (see failure modes). Promotion conditions: a first edition using CFP volume as a pre-sales demand read (hand that read to
```
samber/dev-event-organizer-skills@event-market-fit
```
), international speakers, or a mentorship program that needs room before close.

Below the floor - an event closer than ~10 weeks, or a close date inside 6 weeks of the event - the open CFP is deleted, not demoted: speakers cannot arrange travel inside the sourced 4-6 weeks, so the program goes invited via

samber/dev-event-organizer-skills@event-speaker-sourcing

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

投入（日历余量 + 整个窗口期的持续推广）：
```
长窗口 > 标准窗口 > 压缩底线
```
价值（覆盖范围、弱势群体外联时间、早期需求信号、国际差旅前置时间）：
```
长窗口 > 标准窗口 > 压缩底线
```
效率：
```
标准窗口 > 压缩底线 > 长窗口
```

支配性检查：3 对，零严格支配关系——仅通过构造而干净，而构造性干净永远不是通过。 价值和投入是同一个列表，所以一种机制阻断了所有三对：无论在价值上领先的档位都严格成本更高，没有任何档位在价值上至少相等的同时成本更低。没有第三个轴可以阻断或挽救一对。检查没有发现任何问题；排序完全基于下面的论证。

有来源的底线（DevOpsDays 组织指南）：“尽早开放你的 CFP，并在活动前至少 6-8 周关闭。”保持征集函“开放至少一个月”，并“至少留出 2 周时间审议提案和填补任何空缺。”原因是演讲者的日程，而不是组织者的：“人们通常至少需要 4-6 周来安排差旅或请假。”

标准窗口 - 默认：开放约两个月，活动前 8 周以上关闭，在间隔期内评审。适合有已知受众的重复举办的届次。
压缩底线 - 来源允许的最小值：开放约 4 周，在 6-8 周前关闭，2 周评审——从开放到活动总共约 10-12 周。在硬性日期下是合法的；低于此则不行。
长窗口 - 稀缺选项：DevOpsDays 自己的主时间线将 CFP 启动锚定在 T-7.5 个月，投稿投票在 T-4.5，节目启动在 T-3.5——大约是三个月的评审到启动余量。覆盖范围最大，也是唯一有空间进行导师配对和签证前置时间的档位，但它在每一轮效率上都会输，因为其真正的成本不是日历——而是持续数月的推广（见失败模式）。推广条件：首次举办时使用 CFP 数量作为售前需求判断（将该判断交给
```
samber/dev-event-organizer-skills@event-market-fit
```
）、国际演讲者、或需要在关闭前留出空间的导师计划。

低于底线——活动在约 10 周以内，或关闭日期在活动前 6 周以内——开放式 CFP 会被删除，而不是降级：演讲者无法在有来源的 4-6 周内安排差旅，因此节目改为邀请制，通过

samber/dev-event-organizer-skills@event-speaker-sourcing

进行。

Submission form depth

投稿表单深度

Ranking (default, not a law):

effort (speaker friction + form build + per-submission review time):
```
extended > standard > minimal
```
value (review discriminating power + program-balance and logistics data):
```
extended > standard > minimal
```
efficiency:
```
standard > minimal > extended
```

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass. Value and effort run in one order, so all three pairs fail identically: the rung ahead on value is the rung that costs more. Nothing else is printed to block or rescue a pair. The efficiency line rests on the arguments below, not on a passed check.

Standard - the default: title, an abstract capped near 100 words, a separate "why me" context field, the format pick, intended audience level, bio, optional prior-talk links. The abstract/context split is the load-bearing choice: it lets reviewers score topic quality and speaker fit separately instead of untangling one text box (per swyx's CFP advice - title weighted "twice as important as your abstract", short abstract, a distinct context field worth using). Field-by-field detail, sourced examples, and a negative example live in references/submission-form-catalog.md.
Minimal - title, abstract, bio. Near-zero effort keeps it second on efficiency, but its cheapness is partly false economy: every dropped field is paid back in review-time guesswork and follow-up email. Acceptable for a meetup-scale call or a small invited-plus-CFP hybrid.
Extended - the starved option: adds per-format conditional fields, recording/consent checkboxes, a travel-grant request folded into the form (per PyCon US), and a structured outline. Promotion conditions: a grant program exists (an in-form checkbox beats a separate application process), the structure offers formats with genuinely different requirements, or the committee is large enough to use the extra structure.

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

投入（演讲者摩擦 + 表单构建 + 单篇投稿评审时间）：
```
扩展 > 标准 > 极简
```
价值（评审区分力 + 节目平衡和后勤数据）：
```
扩展 > 标准 > 极简
```
效率：
```
标准 > 极简 > 扩展
```

支配性检查：3 对，零严格支配关系——仅通过构造而干净，而构造性干净永远不是通过。 价值和投入按同一顺序排列，所以三对都以相同方式失败：在价值上领先的档位就是成本更高的档位。没有其他内容可以阻断或挽救一对。效率线基于下面的论证，而不是基于通过的检查。

标准 - 默认：标题、约 100 字上限的摘要、独立的“为什么是我”背景字段、形式选择、目标受众水平、个人简介、可选的过往演讲链接。摘要/背景的拆分是关键选择：它让评审分别评分主题质量和演讲者匹配度，而不是从单个文本框中理清（据 swyx 的 CFP 建议——标题权重“是摘要的两倍重要”、简短摘要、值得使用的独立背景字段）。逐字段细节、有来源的示例和反面示例见 references/submission-form-catalog.md。
极简 - 标题、摘要、个人简介。近乎零投入使其在效率上排名第二，但它的廉价部分是虚假经济：每个删除的字段都会在评审时的猜测和后续邮件中偿还。适用于 meetup 规模的活动或小型邀请加 CFP 混合制。
扩展 - 稀缺选项：增加每种形式的条件字段、录制/同意复选框、并入表单的差旅补助申请（据 PyCon US）和结构化大纲。推广条件：存在补助计划（表单内复选框优于单独的申请流程）、结构提供了要求真正不同的形式、或委员会足够大以利用额外的结构。

Anonymization posture

匿名化姿态

Ranking (default, not a law):

effort (review-process discipline + speaker instructions + two-phase mechanics):
```
mandatory blind > opt-in anonymous > named review
```

value, submission-side equity and trust:

mandatory blind > opt-in anonymous > named review

value, program-shaping data during review (name recognition, local/out-of-town balance, speaker-fit reads):
```
named review > opt-in anonymous > mandatory blind
```

efficiency:

named review > opt-in anonymous > mandatory blind

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass. One mechanism blocks all three pairs, and it is not the usual one: the two value axes are exact reverses of each other, so whichever rung leads on equity trails on program-shaping data, and no rung can be at least equal on both. Effort is never reached in any pair. The check finds nothing here - the efficiency line rests on the argument below.

The two value axes genuinely disagree - that disagreement is the decision, and the evidence sits on both sides. Per swyx: "blind CFP review is important for some level of equity... In my experience, most CFP's are NOT blind." PyCon US is the at-scale counter-example that actually runs it: "During initial review, proposal author information is not displayed to reviewers".

Named review - the de facto field default per swyx's observation, and the default here for a small first CFP where a 2-3 person committee hand-tunes program balance. Only honest with published criteria doing the fairness work the anonymity isn't.
Opt-in anonymous - the tooling default (two of the three example platforms in the catalog reference ship anonymization as an optional mode). Treat it as a platform capability, not a fairness posture: a pool mixing named and anonymous submissions is not reviewed on one footing.
Mandatory blind - the starved option: top of equity value and top of effort, so efficiency never picks it. Its real costs, from the PyCon implementation: review runs two-phase (identity must enter before the program is final - balance, travel, the name-recognition read), and speakers must be instructed to self-police identifying details out of titles and free text, because the platform hides the author field, not what the author wrote. Promotion conditions: equity as a stated goal (Q8) plus committee capacity for a two-phase process. If promoted, publish the mechanics in the call including exactly when identity enters, or you've built blind-review theater (see failure modes).

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

投入（评审过程纪律 + 演讲者说明 + 两阶段机制）：
```
强制盲审 > 可选匿名 > 实名评审
```

价值，投稿方公平性和信任：

强制盲审 > 可选匿名 > 实名评审

价值，评审期间的节目塑造数据（知名度识别、本地/外地平衡、演讲者匹配度判断）：
```
实名评审 > 可选匿名 > 强制盲审
```

效率：

实名评审 > 可选匿名 > 强制盲审

支配性检查：3 对，零严格支配关系——仅通过构造而干净，而构造性干净永远不是通过。 一种机制阻断了所有三对，且不是通常的那种：两个价值轴完全互为反向，所以无论在公平性上领先的档位，在节目塑造数据上就会落后，没有任何档位能在两者上至少相等。任何一对都不会触及投入。检查在这里没有发现任何问题——效率线基于下面的论证。

两个价值轴确实存在分歧——这个分歧就是决策本身，而证据双方都有。据 swyx：“盲审 CFP 对某种程度的公平性很重要……以我的经验，大多数 CFP 不是盲审的。”PyCon US 是真正实施盲审的大规模反例：“在初审期间，提案作者信息不会展示给评审。”

实名评审 - 据 swyx 的观察，这是事实上的领域默认，也是小型首次 CFP 的默认选择，由 2-3 人委员会手动调整节目平衡。只有公开标准承担了匿名性未承担的公平工作时，这才诚实。
可选匿名 - 工具默认（目录参考中的三个示例平台中有两个将匿名化作为可选模式提供）。将其视为平台能力，而非公平姿态：混合实名和匿名投稿的池子不是在统一基础上评审的。
强制盲审 - 稀缺选项：公平性价值最高、投入也最高，所以效率永远不会选择它。其真实成本，从 PyCon 的实施来看：评审分为两个阶段（在节目最终确定之前身份必须进入——平衡、差旅、知名度识别判断），并且必须指示演讲者自我审查标题和自由文本中的身份识别细节，因为平台隐藏的是作者字段，而不是作者写的内容。推广条件：公平性作为既定目标（Q8）加上委员会有能力进行两阶段流程。如果推广，请在征集函中公布机制，包括身份进入的确切时间，否则你就构建了盲审剧场（见失败模式）。

Published review criteria

公开评审标准

Write the criteria into the call itself. The sourced template is DevOpsDays' six content-policy points, stated openly to speakers (verbatim in references/published-call-evidence.md):

No sponsor-bought speaker spots, ever.
New content favored over already-published material.
Local/out-of-town speaker balance.
New speakers actively favored.
Bold subjects encouraged.
Tool/product-specific talks routed to open space rather than rejected.

The call redirects vendor pitches to the format that fits them, which only works if the structure chose an open-space block upstream.

Honesty check before publishing: per swyx, organizers optimize a program to "sell tickets, have a great content mix, and sell next year's tickets, in roughly that order." If name recognition and topic mix will in fact shape selection - they will - the criteria must not pretend otherwise. Publish criteria you will actually apply, and let the community-pole hard line ("not ever - period") carry the one non-negotiable.

将标准写进征集函本身。有来源的模板是 DevOpsDays 的六条内容政策要点，向演讲者公开说明（原文见 references/published-call-evidence.md）：

赞助商购买的演讲名额，永远不允许。
新内容优先于已发表的材料。
本地/外地演讲者平衡。
积极支持新演讲者。
鼓励大胆的主题。
工具/产品特定演讲引导到开放空间而不是拒绝。

征集函将厂商宣传重定向到适合它们的形式，这只有在结构上游选择了开放空间块时才有效。

发布前的诚实性检查：据 swyx，组织者优化节目是为了“卖门票、有好的内容组合、卖明年的门票，大致按此顺序。”如果知名度识别和主题组合实际上会影响筛选——它们会的——标准就不能假装不是这样。发布你实际上会应用的标准，让社区立场的硬线（“永远不行——没有例外”）承担唯一的不可协商项。

Speaker benefits stated in the call

征集函中声明的演讲者福利

The published floor: "at minimum, all speakers should receive a free event ticket" (DevOpsDays organizing guide). State it explicitly; a call silent on perks reads as a call with none.
Travel: reimbursement is "a good use of funds if available" with a documented caveat worth repeating to organizers - direct payment "can bring with it complex issues around taxes, visas, and conflict of interest/employment agreements." If running grants, reuse PyCon US's policy shape: grants framed as enabling attendance rather than rewarding quality, capped at one per accepted proposal, with an explicit ask that speakers who can afford to attend self-select out of the limited pool.
Honorarium: no industry norm exists, but two named community events now publish a fixed figure in their own call: !!Con states a flat "$256 (USD)" honorarium for every speaker, unchanged across its 2018-2024 editions; ffconf (UK) states "£500 honorarium" alongside full travel, hotel, and meals. The two amounts don't converge on a rate - treat them as calibration points, not a market rate or "industry standard". If the user wants an honorarium policy, show these two figures, then gate the actual number on their own budget and legal/tax review.
The rule that binds all three: the call states exactly what speakers get, and nothing the budget hasn't confirmed.

已公布的底线：“至少，所有演讲者都应获得免费活动门票”（DevOpsDays 组织指南）。明确说明；对福利保持沉默的征集函会被读作没有福利。
差旅：报销“如果可用，是资金的良好用途”，但有一个值得向组织者重复的有记录的警告——直接支付“可能带来税务、签证和利益冲突/雇佣协议方面的复杂问题。”如果提供补助，复用 PyCon US 的政策框架：补助被定位为支持出席而非奖励质量，每个被接受的提案最多一份，并明确要求有能力自费出席的演讲者自行退出有限的名额池。
酬金：不存在行业规范，但两个具名的社区活动现在在自己的征集函中公布了固定数字：!!Con 为每位演讲者提供统一的“$256（美元）”酬金，在其 2018-2024 各届中保持不变；ffconf（英国）在全额差旅、酒店和餐饮之外，还提供“£500 酬金”。这两个金额并未趋同于一个费率——将它们视为校准点，而非市场价或“行业标准”。如果用户想要酬金政策，展示这两个数字，然后将实际数字限制在用户自己的预算和法律/税务审查范围内。
约束这三者的规则：征集函准确说明演讲者获得什么，且不包含预算未确认的任何内容。

First-time-speaker support

首次演讲者支持

Ranking (default, not a law):

effort (setup + per-speaker time):

proposal mentorship > worked examples > encouragement copy

value (submissions from new voices that survive review):

proposal mentorship > worked examples > encouragement copy

efficiency:

worked examples > encouragement copy > proposal mentorship

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and that is never a pass. Value and effort share one ordering, so the same mechanism blocks every pair: the higher-value rung is strictly the costlier one. No further axis exists to change that in any pair. The check verifies nothing; argue with the ratios below.

Worked examples - the default: publish past accepted proposals as calibration; PyCon US points first-timers at prior years' proposals. A first edition has no archive - fall back one rung and let the published criteria plus a well-split form do the calibrating.
Encouragement copy - near-zero effort, always included, never sufficient alone: a stated "favor new speakers" line is itself one of the sourced published criteria.
Proposal mentorship - the starved option: a structured pre-submission pairing program, separately timed alongside the CFP. PyCon US's Proposal Mentorship is a documented example of the mechanism. Promotion conditions: a volunteer mentor pool exists (Q9) and the window is long enough to pair mentors before close - which couples this rung to the long-window timeline.

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

投入（设置 + 每位演讲者时间）：

提案导师制 > 示例参考 > 鼓励文案

价值（通过评审的新声音投稿）：

提案导师制 > 示例参考 > 鼓励文案

效率：

示例参考 > 鼓励文案 > 提案导师制

支配性检查：3 对，零严格支配关系——仅通过构造而干净，而这永远不是通过。 价值和投入共享一个排序，所以同样的机制阻断了每一对：价值更高的档位严格来说成本也更高。任何一对中都不存在其他轴来改变这一点。检查没有验证任何东西；用下面的比率来论证。

示例参考 - 默认：发布过去被接受的提案作为校准；PyCon US 将首次投稿者指向往年的提案。首次举办没有存档——回退一档，让公开标准加上拆分良好的表单来完成校准。
鼓励文案 - 近乎零投入，始终包含，但单独永远不够：“支持新演讲者”的表述本身就是有来源的公开标准之一。
提案导师制 - 稀缺选项：结构化的提交前配对计划，与 CFP 并行安排时间。PyCon US 的提案导师制是该机制的有记录示例。推广条件：存在志愿者导师池（Q9），且窗口足够长以在关闭前配对导师——这将该档位与长窗口时间线耦合。

Promotion

推广

No conference organizer or CFP platform has published a channel-by-channel breakdown of where submissions actually came from - say that plainly rather than inventing a ranked channel menu. Three things are sourced and load-bearing (verbatim in references/published-call-evidence.md):

Sustain promotion across the whole open window, not just at open - the long-window rung's cost lives here.
A concrete sequencing pattern (Write the Docs): write the announcement, post it to the blog, tweet a link to the post, then wait one to two hours before the mass email - the delay lets the community catch errors before the wider list sees them.
The equity warning (DevOpsDays): "under-represented people in tech are much less likely to respond to your CFP." If diversity is a goal (Q8), reach actively into those communities; the open call alone will not do it. Two sourced mechanisms for that active reach: a maintained list of named community groups with a template outreach email (
```
jlengstorf/awesome-speaker-diversity
```
), and PyCon 2010's own categorized CFP-distribution target list as a concrete precedent for the same move at conference scale.

没有会议组织者或 CFP 平台发布过按渠道分解的投稿实际来源数据——直接说明这一点，而不是编造一个排序的渠道菜单。有三件事有来源且至关重要（原文见 references/published-call-evidence.md）：

在整个开放窗口期间持续推广，而不仅仅在开放时——长窗口档位的成本就在这里。
一个具体的排序模式（Write the Docs）：写公告，发布到博客，在 X/Twitter 上发布帖子链接，然后等一两个小时再群发邮件——这个延迟让社区在更广泛的列表看到之前发现错误。
公平性警告（DevOpsDays）：“科技领域的弱势群体回应你的 CFP 的可能性要低得多。”如果多样性是目标（Q8），主动深入这些社区；仅靠开放征集函做不到。有两个有来源的主动外联机制：一个维护良好的具名社区组列表，配有模板外联邮件（
```
jlengstorf/awesome-speaker-diversity
```
），以及 PyCon 2010 自己的分类 CFP 分发目标列表，作为在会议规模上采取同样行动的具体先例。

Failure modes

失败模式

Unstated criteria. A rubric exists but the call doesn't publish it - rejections read as arbitrary, and next year's submission pipeline pays for it. The sourced practice is six criteria in the call itself.
Perk promises without policy. Travel or honorarium language published before budget confirmation, walking into the sourced taxes/visas/conflict-of-interest trap. The call states the confirmed floor and stops.
Blind-review theater. Mandatory blind announced, but identity leaks unmanaged in free text, or quietly re-enters for program shaping with no published phase boundary. Publish the mechanics or pick named review.
The stale long window. A CFP opened at T-7.5 months with one announcement and no sustained promotion sits silent through the middle of its window. A long window is a promotion commitment, not just an early open date.
A CFP below the floor. Closing inside 6 weeks of the event, or open under a month, asks speakers to defy the sourced 4-6 week travel reality. Delete the open call; go invited.
One text box for everything. An abstract that must carry topic, outline, and "why me" at once can't be scored on any of them - the split form exists so review can separate topic quality from speaker fit.
A call offering the wrong formats. Formats in the call that the chosen structure doesn't have (or missing ones it does) create submissions nobody can schedule. The format menu is an input from upstream, not a CFP-time decision.
Reading oversubscription as failure. Turning away most submissions is the normal state of a healthy CFP (see measurement) - the fix for volume is review capacity, not a narrower call.

未说明的标准。 评分标准存在但征集函未公布——拒绝被视为武断，明年的投稿管道会为此付出代价。有来源的做法是在征集函中写明六条标准。
无政策的福利承诺。 在预算确认之前发布差旅或酬金措辞，走入有来源的税务/签证/利益冲突陷阱。征集函说明已确认的底线并就此打住。
盲审剧场。 宣布强制盲审，但身份在自由文本中泄漏且未加管理，或在没有公布的阶段边界的情况下悄然重新进入节目塑造。公布机制或选择实名评审。
僵化的长窗口。 在 T-7.5 个月开放但只有一次公告且没有持续推广的 CFP，在窗口中期会陷入沉默。长窗口是推广承诺，而不仅仅是提前开放日期。
低于底线的 CFP。 在活动前 6 周内关闭，或开放不到一个月，是要求演讲者违背有来源的 4-6 周差旅现实。删除开放式征集；改为邀请制。
一个文本框装所有东西。 摘要必须同时承载主题、大纲和“为什么是我”，导致无法对任何一项评分——拆分表单的存在就是为了让评审区分主题质量和演讲者匹配度。
提供错误形式的征集函。 征集函中包含所选结构没有的形式（或缺少结构有的形式）会产生无人能排期的投稿。形式菜单是上游输入，不是 CFP 时的决策。
将超额订阅视为失败。 拒绝大多数投稿是健康 CFP 的正常状态（见衡量）——解决数量问题的办法是评审能力，而不是更窄的征集。

Measurement

衡量

Documented benchmarks are stated; everything else is a threshold you set before the CFP opens.

Submissions-to-slot ratio: PyCon US 2025 accepted 15% of 938 proposals - roughly 6.5:1. Swyx's benchmark puts an established conference's pool at 200 to 800-1,200 applicants, making 8-30x oversubscription normal at a popular single-track event. As a pre-launch demand read, even 2-3:1 on a first CFP is a strong signal - that go/no-go reading belongs to
```
samber/dev-event-organizer-skills@event-market-fit
```
.
First-time-submitter share: DjangoCon Europe 2024 drew 174 proposals from 138 submitters, 51 of them first-time speakers - submitter diversity as a vibrancy signal, not just volume.
Off-policy share: the fraction of submissions the published criteria already exclude (vendor pitches in the curated pool) - a high share means the criteria aren't landing in the call.
Submission timing: where in the window submissions arrive; a dead middle argues the promotion plan, not the window length, failed.

Pick 2-3, write down the revision each would trigger next edition, and record both before the event.

有记录的基准已说明；其他一切都是你在 CFP 开放前设定的阈值。

投稿与名额比：PyCon US 2025 接受了 938 份提案中的 15%——大约 6.5:1。Swyx 的基准将成熟会议的申请池定为 200 到 800-1,200 名申请者，使 8-30 倍的超额订阅成为热门单轨活动的常态。作为发布前的需求判断，首次 CFP 即使 2-3:1 也是强信号——该“可行/不可行”判断属于
```
samber/dev-event-organizer-skills@event-market-fit
```
。
首次投稿者占比：DjangoCon Europe 2024 从 138 名投稿者收到了 174 份提案，其中 51 名是首次演讲者——投稿者多样性作为活力信号，而不仅仅是数量。
政策外占比：公开标准已经排除的投稿比例（策划池中的厂商宣传）——高占比意味着标准没有在征集函中传达到位。
投稿时间分布：投稿在窗口的哪个阶段到达；中间阶段的寂静说明是推广计划失败了，而不是窗口长度。

选择 2-3 个，写下每个会在下一届触发的修正，并在活动前记录两者。

Invocation examples

调用示例

"Our first DevOps conference is in nine months - set up the CFP end to end."
"Write the CFP page for our two-day community conference: timeline, form, criteria, perks."
"Should our CFP be anonymous? We got flak last year about the same names being picked."
"The event is in ten weeks and we have no talks yet - can we still run a CFP?"

Expected output: a CFP design brief with:

The timeline worked back from the event date, with open/close/notify anchors.
The form field list per offered format, plus the submission cap.
The published criteria text.
The anonymization posture, with its mechanics as the call will state them.
The speaker-benefits statement.
The promotion and outreach notes, with the sourced equity warning.
The handoff plan to selection, sourcing, and scheduling.

Presented section by section for validation before the call goes public.

“我们的第一届 DevOps 会议还有九个月——端到端搭建 CFP。”
“为我们的两天社区会议编写 CFP 页面：时间线、表单、标准、福利。”
“我们的 CFP 应该匿名吗？去年我们因为总是选同样的人而受到批评。”
“活动还有十周，我们还没有任何演讲——我们还能办 CFP 吗？”

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

从活动日期倒推的时间线，包含开放/关闭/通知锚点。
每种提供形式的表单字段列表，加上投稿上限。
公开标准文本。
匿名化姿态，以及征集函将如何陈述其机制。
演讲者福利声明。
推广和外联说明，包含有来源的公平性警告。
向筛选、招募和排期的交接计划。

在征集公开前，逐节呈现以供验证。

References

参考资料

references/submission-form-catalog.md - field-by-field catalog with examples, the four-format PyCon menu, the submission cap, tooling capability checklist with named example platforms, and a positive/negative form example.
references/published-call-evidence.md - the DevOpsDays timeline and six criteria verbatim, speaker-benefit and travel-grant language, the anonymization evidence on both sides, first-time-speaker mechanisms, the under-represented-response warning and two sourced outreach mechanisms, a sourced promotion sequencing pattern, and the oversubscription benchmarks.