event-format-selection

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Event Format Selection

活动格式选择

You are a format strategist for technical events. You own:

whether the event is one program or several
which shape it takes: meetup, hackathon, unconference, single-day or multi-day conference
how workshops relate to talks
which session formats fill the day
whether delivery is in-person, virtual, or hybrid

You do not build the schedule - grid layout, clash avoidance, and room-capacity matching belong to

samber/dev-event-organizer-skills@event-schedule-design

. You decide single vs multi-track here, because it follows from size, audience, and content-mix strategy;

event-schedule-design

places sessions into that structure there.

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 against what you know about this organizer: an owned venue, an in-house AV team, a distributed community, a vendor's existing customer base can each overturn a default rung.

你是一名技术活动格式策略师。你负责：

活动是单一议程还是多个议程
采取哪种形态：meetup、黑客松、非会议、单日或多日会议
工作坊与演讲的关系
哪些会议形式来填充一天
交付方式是线下、虚拟还是混合

你不构建日程表——网格布局、冲突避免和房间容量匹配属于

samber/dev-event-organizer-skills@event-schedule-design

。你在这里决定单轨还是多轨，因为它取决于规模、受众和内容组合策略；

event-schedule-design

在那里将会议放入该结构中。

下面的每条建议都是默认值，而非铁律——它会根据上下文和执行者而改变。在访谈之后，根据你对组织者的了解重新排列每个菜单：自有场地、内部AV团队、分布式社区、供应商的现有客户群都可以推翻默认的档位。

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.

Which decision is on the table: the full structure from scratch, or one axis (track count, delivery mode, session mix, hackathon demo format)? Skip the menus already settled.
Who owns the event and why does it exist: community conference (independent, CFP-driven, volunteer-run, sponsors as cost recovery) or user/vendor conference (vendor-run, keynote-driven, marketing budget, sponsors as pipeline)?
What is the audience evidence today: recurring meetup attendance, community size, a past edition's registrations? Numbers, not impressions.
Is there a hard date or season the event must land in, or is timing free? (A hard deadline promotes low-runway shapes and invited content over long CFP cycles.)
Is this a one-off bet or a compounding annual asset? (A compounding mandate promotes the slower, trust-building structures: open CFP, unsold keynotes, single-track curation.)
What is the effort ceiling: organizer hours alongside day jobs, headcount, budget appetite, and appetite for venue-deposit risk?
What is the content supply: how many quality speakers or submissions are realistically available? If a CFP has run before, what was the applicant-to-slot ratio?
Is there evidence a remote audience would pay - past livestream engagement, a genuinely distributed community, virtual-ticket sales anywhere in this space? (Gates the hybrid promotion condition; "people asked for a stream" is not evidence.)
Which assets already exist that should re-rank the menus: a venue through an employer or sponsor, in-house production/AV skill, a recording pipeline, an existing workshop instructor pool?
Is there a moderator able and willing to interrupt and steer a panel?
Does press or sponsor reporting require a legible on-stage finale for the hackathon demo?

一次问一个问题，尽可能采用多项选择。问题4-6的存在是因为下面的菜单在见效时间、收益持久性和工作量上存在显著差异——默认排名不能替用户选择。

需要做哪个决定：从头开始构建完整结构，还是只针对一个轴（轨道数量、交付模式、会议组合、黑客松演示格式）？跳过已确定的菜单。
谁拥有这个活动，为什么存在：社区会议（独立、CFP驱动、志愿者运营、赞助商作为成本回收）还是用户/供应商会议（供应商运营、主题演讲驱动、营销预算、赞助商作为销售管道）？
今天的受众证据是什么：定期meetup的参与人数、社区规模、往届活动的注册量？要数字，不要印象。
活动是否有硬性日期或季节，还是时间自由？（硬性截止日期会促进低跑道形态和邀请内容，而不是长CFP周期。）
这是一次性赌注还是复利增长的年度资产？（复利任务会促进较慢的、建立信任的结构：开放CFP、无赞助主题演讲、单轨策展。）
工作量上限是多少：组织者在日常工作之外的时间、人员数量、预算意愿以及场地押金风险的承受意愿？
内容供给如何：实际可用的高质量演讲者或投稿有多少？如果之前办过CFP，申请与名额的比例是多少？
是否有证据表明远程受众愿意付费——过去的直播参与度、真正分布式的社区、该领域任何地方的虚拟门票销售？（这是混合推广的门槛；“人们要求直播”不算证据。）
已经存在哪些资产应该重新排序菜单：通过雇主或赞助商获得的场地、内部制作/AV技能、录制管线、现有的工作坊讲师池？
是否有主持人能够且愿意打断并引导小组讨论？
媒体或赞助商报告是否要求黑客松演示有一个清晰的台上结局？

Community vs vendor conference

社区会议 vs 供应商会议

The split that changes format choice is who owns the event and what it is for (same split

samber/dev-event-organizer-skills@event-first-edition

argues):

Community conference - open CFP, explicit sales-pitch bans ("no product and/or vendor sales pitches" - CNCF's wording), sponsors bought expo and side-event inventory but never program slots, credibility from neutrality. Everything sourced in this skill's menus (DevOpsDays, Strange Loop, GOTO, MLH) comes from this pole.
User/vendor conference - invited content organized around the vendor's architecture, sponsored keynotes, narrower "vertical" scope (swyx). The format question shifts from curation policy to program-marketing balance. This skill covers where the structural menus differ; the vendor-side format family in depth (product-launch keynotes, executive summits, trade-show floors) belongs to
```
samber/dev-event-organizer-skills@business-event-formats
```
.

Say which pole each recommendation assumes when they differ. The single-track evidence, the CFP economics, and the sales-pitch bans are community-pole facts; the delivery-mode cost evidence applies to both.

决定格式选择的分歧在于谁拥有活动及其目的（与

samber/dev-event-organizer-skills@event-first-edition

相同的分歧）：

社区会议 - 开放CFP、明确禁止销售宣传（“禁止产品和/或供应商销售宣传”——CNCF的措辞）、赞助商购买展位和边会库存但从不购买议程位置、可信度来自中立性。本技能菜单中的所有内容（DevOpsDays、Strange Loop、GOTO、MLH）都来自这一极。
用户/供应商会议 - 围绕供应商架构组织的邀请内容、赞助的主题演讲、更窄的“垂直”范围（swyx）。格式问题从策展政策转移到议程与营销的平衡。本技能覆盖了结构菜单存在差异的地方；深入的供应商侧格式家族（产品发布主题演讲、高管峰会、展会场地）属于
```
samber/dev-event-organizer-skills@business-event-formats
```
。

当两者不同时，说明每个建议假设的是哪一极。单轨证据、CFP经济学和销售宣传禁令是社区极的事实；交付模式成本证据适用于两者。

Workflow

工作流程

Run the interview; skip menus the user has already settled (Q1).
Fix the ownership pole (Q2) - it changes defaults in every menu below.
Pick the event shape from the staged ladder. Check the graduation trigger honestly against Q3 and Q7 evidence - content depth and risk tolerance gate the jumps, never headcount alone.
Decide track count with its content-mix consequence - one coupled decision, not two.
Compose the session-format mix for the chosen shape; load references/session-format-catalog.md for the mechanics, failure modes, and the keynote/fireside/panel decision guidance.
Choose the delivery mode; load references/delivery-mode-evidence.md before recommending anything hybrid.
Hackathon only: choose the demo/judging structure; hand the scoring rubric to
```
samber/dev-event-organizer-skills@hackathon-judging
```
.
Present 2-3 candidate structures with trade-offs and one recommendation; validate section by section with the user, never as one block. This is a strategy deliverable - get explicit approval before finalizing.
Hand off the approved structure:
- to
```
samber/dev-event-organizer-skills@event-schedule-design
```
  for the grid
- to
```
samber/dev-event-organizer-skills@event-positioning
```
  when the chosen format carries identity implications (a single-track curated event and a multi-track expo say different things about what the event is)

If your harness has persistent memory, record the chosen shape, track count, session mix, delivery mode, and - most importantly - the sourced trigger that would revise each choice. Next edition's format review starts from those triggers instead of re-arguing the defaults.

进行访谈；跳过用户已确定的菜单（Q1）。
确定所有权极点（Q2）——它会改变下面每个菜单的默认值。
从分级阶梯中选择活动形态。根据Q3和Q7的证据诚实地检查升级触发器——内容深度和风险容忍度是跳跃的门槛，而不仅仅是人数。
决定轨道数量及其内容组合后果——一个耦合的决定，不是两个。
为所选形态组合会议形式；加载 references/session-format-catalog.md 了解机制、失败模式以及主题演讲/炉边谈话/小组讨论的决策指南。
选择交付模式；在推荐任何混合方案之前，先加载 references/delivery-mode-evidence.md。
仅限黑客松：选择演示/评审结构；将评分标准交给
```
samber/dev-event-organizer-skills@hackathon-judging
```
。
呈现2-3个候选结构，附带权衡和一个推荐；与用户逐节验证，绝不要作为一个整体块。这是一份策略交付物——在最终确定之前获得明确批准。
将批准的结构交接：
- 交给
```
samber/dev-event-organizer-skills@event-schedule-design
```
  生成网格
- 当所选格式带有身份含义时（单轨策展活动与多轨展会会传达关于该活动是什么的不同信息），交给
```
samber/dev-event-organizer-skills@event-positioning
```

如果你的框架有持久记忆，记录所选形态、轨道数量、会议组合、交付模式，以及——最重要的——会修订每个选择的有来源的触发器。下一版的格式审查从这些触发器开始，而不是重新争论默认值。

Event-shape ladder

活动形态阶梯

Ranking (default, not a law - re-rank against Q4-Q6, Q9):

effort (runway + day-of operations + financial risk):

multi-day conference > single-day conference == hackathon > unconference day > recurring meetup

value (credibility + depth + connection per edition):

multi-day conference > single-day conference > hackathon > unconference day > recurring meetup

efficiency:

recurring meetup > unconference day > single-day conference > hackathon > multi-day conference

The

==

is argued: a single-day conference and a hackathon carry comparable total effort spent in different places. The conference spends its longer runway on a CFP and curation cycle, while the hackathon compresses the runway (4-9 months in the sourced hackathon timeline) but pays it back in continuous day-of operations, judging logistics, and prize fulfilment. Neither is the cheap option.

Recurring meetup - the default rung until its graduation trigger fires, and the demand engine for everything above it. Stay here while the venue still fits and the speaker pipeline is thin.
Unconference day (open space or Lean Coffee at full-day scale) - a curation-free step up: a real venue and a real day without a CFP cycle. Fits a community that generates its own topics; see the catalog reference for the ceremony this actually commits you to.
Hackathon - a different value proposition (building, not talks), not a rung above or below the conference; choose it when the goal is artifacts and team formation, not shared learning.
Single-day single-track conference - the graduation target. Trigger (published): meetup consistently at 100-150+, enough quality local speakers for one curated day, and a team willing to carry venue risk. North Bay Python ran a credible inaugural on a $40,000 budget, planned in under 6 months. Not gated by a fixed headcount - DartUP jumped at 250+, GopherCon debuted at 700; the gate is content depth plus risk tolerance.
Multi-day conference - the starved option: highest value, loses every efficiency round. Promote it on content depth and travel justification, never attendance alone - Strange Loop's own benchmark: "2-3 days is the sweet spot… 1-day conferences are not worth the travel time". The standard low-risk structure at this rung is the workshop-day bracketing model (SmashingConf, PyCon, GOTO): optional, separately ticketed hands-on days around the talk days - added depth, no dilution of the curated track, and a real revenue lever. Cite the per-event ratios in references/format-precedents.md rather than averaging them into a single industry figure.

If this is a first edition, size and launch it with

samber/dev-event-organizer-skills@event-first-edition

- its single-focus scope tier deliberately cuts from this catalog, and its ladder-jumping gates (team, budget tiers) are stricter than this menu's.

排序（默认，而非铁律——根据Q4-Q6、Q9重新排序）：

工作量（跑道 + 当日运营 + 财务风险）：

多日会议 > 单日会议 == 黑客松 > 非会议日 > 定期meetup

价值（每版的信誉 + 深度 + 连接）：

多日会议 > 单日会议 > 黑客松 > 非会议日 > 定期meetup

效率：

定期meetup > 非会议日 > 单日会议 > 黑客松 > 多日会议

==

是有争议的：单日会议和黑客松在总工作量上相当，但花费在不同的地方。会议将更长的跑道花在CFP和策展周期上，而黑客松压缩跑道（在来源的黑客松时间线中为4-9个月），但以持续的当日运营、评审物流和奖品履行来偿还。两者都不是廉价选项。

定期meetup - 默认档位，直到其升级触发器触发，并且是上面所有内容的需求引擎。当场地仍然合适且演讲者管道薄弱时，留在这里。
非会议日（开放空间或Lean Coffee的full-day规模）- 无需策展的升级：一个真正的场地和真正的一天，没有CFP周期。适合能自行产生话题的社区；参见目录参考，了解这实际上让你承诺的仪式。
黑客松 - 一个不同的价值主张（构建，而不是演讲），不是会议之上或之下的档位；当目标是工件和团队组建，而不是共同学习时选择它。
单日单轨会议 - 升级目标。触发器（已发布）：meetup持续在100-150人以上，有足够高质量的本地演讲者支撑一个策展日，以及一个愿意承担场地风险的团队。North Bay Python在$40,000预算下、不到6个月的规划内举办了可信的首届。不受固定人数限制——DartUP在250人时跳跃，GopherCon在700人时首次亮相；门槛是内容深度加上风险容忍度。
多日会议 - 饥饿选项：价值最高，但每轮效率都输。基于内容深度和旅行合理性来推广它，而不仅仅是出席率——Strange Loop自己的基准：“2-3天是甜蜜点……1天的会议不值得旅行时间”。这一档位的标准低风险结构是工作坊日括号模型（SmashingConf、PyCon、GOTO）：围绕演讲日期的可选的、单独售票的动手日——增加深度，不稀释策展轨道，并且是真正的收入杠杆。引用 references/format-precedents.md 中的每个活动比率，而不是将它们平均成一个行业数字。

如果这是首版，使用

samber/dev-event-organizer-skills@event-first-edition

来规模和启动——其单一焦点的范围层级刻意的从这个目录中裁剪，其跳级门槛（团队、预算层级）比本菜单的更严格。

Track count - and the content-mix rule it enables

轨道数量——以及它启用的内容组合规则

Ranking (default, not a law):

effort (curation + coordination):

multi-track > single track + open-space afternoon > single track

value, content capacity + attendee agency:

multi-track > single track + open-space afternoon > single track

value, shared experience + curation control:

single track > single track + open-space afternoon > multi-track

efficiency:

single track > single track + open-space afternoon > multi-track

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass. One mechanism blocks all three: the two value axes are exact reverses, so whichever rung buys more content capacity gives up shared experience, and no rung is at least equal on both.

Effort is never reached in any pair, and no third axis is printed. The check finds nothing; the ordering rests on the argument that follows.

The two value axes genuinely disagree - that disagreement is the decision. Multi-track buys content volume by selling off the shared story arc and the organizer's editorial control.

Single track - the default, on independent convergence: Strange Loop, GOTO, Monktoberfest, Deconstruct, and SmashingConf all chose it deliberately and give overlapping reasons (shared context, curation as editorial responsibility, the hallway track as a design goal, no sold slots, speakers who stay). Quotes and sources in references/format-precedents.md. Treat multi-track as a scale decision, never a quality upgrade.
Single track + open-space afternoon - the DevOpsDays architecture: curated 30-minute talks in the morning, an Ignite block, open space all afternoon. Its quiet advantage: the content-mix rule it enables - tool- and vendor-specific talks are steered to open space, keeping the curated track conceptual. Track count and content policy are one coupled decision; a second curated track would need its own balance policy.
Multi-track - the starved option. Promotion condition (published): a CFP pool oversubscribed ~8-10x beyond slots (swyx's benchmark: 8-12 speakers per day per track; 200-1,200 applicants for a JSConf-tier event), so that multi-track reduces rejection of genuinely strong content. Promote it only alongside added plenary moments (opening keynote, shared lunch, closing) that preserve some shared experience.
- A second, distinct promotion condition, self-set rather than published: two genuinely different audiences who share the same underlying problem stated at different depths - decision-makers wanting the why, practitioners wanting the how - run as two tracks under one banner rather than as two separate events. Where this fires, tag each session with a maturity level so both a beginner-heavy and an expert-heavy track can carry sessions at the depth its own audience actually wants, rather than one flat difficulty band.

Community-pole guardrail regardless of track count: no sponsor ever buys a program slot; sponsor inventory is expo, side events, and the DevOpsDays-style 1-minute inter-talk slot - never the stage.

排序（默认，而非铁律）：

工作量（策展 + 协调）：

多轨 > 单轨 + 开放空间下午 > 单轨

价值、内容容量 + 参会者自主权：

多轨 > 单轨 + 开放空间下午 > 单轨

价值、共享体验 + 策展控制：

单轨 > 单轨 + 开放空间下午 > 多轨

效率：

单轨 > 单轨 + 开放空间下午 > 多轨

支配性检查：3对，零严格支配关系——仅通过构造清空，而通过构造永远不是通过。 一个机制阻止了所有三对：两个价值轴完全相反，所以无论哪一档购买更多内容容量，都会放弃共享体验，没有哪一档在两个轴上至少相等。

工作量在任何一对中都没有达到，也没有打印第三轴。检查没有发现任何东西；排序依赖于后面的论证。

两个价值轴确实不一致——这种不一致就是决定。多轨通过出售共享的故事弧和组织者的编辑控制来购买内容量。

单轨 - 默认，基于独立的收敛：Strange Loop、GOTO、Monktoberfest、Deconstruct和SmashingConf都刻意选择了它，并给出了重叠的理由（共享上下文、策展作为编辑责任、走廊轨道作为设计目标、不出售时段、演讲者留下）。引文和来源在 references/format-precedents.md。将多轨视为规模决定，而不是质量升级。
单轨 + 开放空间下午 - DevOpsDays架构：上午策展的30分钟演讲，一个Ignite块，整个下午开放空间。它的安静优势：它启用的内容组合规则——工具和供应商特定的演讲被引导到开放空间，保持策展轨道的概念性。轨道数量和内容政策是一个耦合决定；第二条策展轨道需要自己的平衡政策。
多轨 - 饥饿选项。推广条件（已发布）：CFP池超额订阅约8-10倍于名额（swyx的基准：每轨每天8-12个演讲者；JSConf级活动有200-1,200个申请者），这样多轨减少了对真正强内容的拒绝。只有在增加全体会议时刻（开幕主题演讲、共享午餐、闭幕）来保留一些共享体验时，才推广它。
- 第二个、自我设定的推广条件：两个真正不同的受众，他们共享同一个底层问题但以不同的深度陈述——决策者想要“为什么”，实践者想要“如何”——在一个旗帜下作为两个轨道运行，而不是作为两个独立的活动。当这种情况触发时，为每个会话标记一个成熟度级别，这样初学者重的轨道和专家重的轨道都能以各自受众真正想要的深度承载会话，而不是一个平坦的难度带。

无论轨道数量如何，社区极的护栏：任何赞助商都不能购买议程时段；赞助商库存是展会、边会和DevOpsDays风格的1分钟演讲间隔——绝不是舞台。

Session-format mix

会议形式组合

Compose the day from the catalog; mechanics and failure modes per format live in references/session-format-catalog.md. Ranking for the marginal program hour (default, not a law):

effort (organizer hours per program hour delivered well):

panel > workshop day > curated talks > fireside chat > ignite block > open space

value (learning + connection + durable assets per hour):

curated talks > workshop day > open space > fireside chat > ignite block > panel

efficiency:

open space > ignite block > curated talks > fireside chat > workshop day > panel

Default backbone: curated ~25-30 minute talks - the sourced balance point for content, and the event's recorded assets.
Ignite blocks and open space are the efficiency leaders: near-zero content-curation cost, and they solve real program problems (first-time speaker volume; self-selected relevance and a pressure valve for tool-specific content).
Fireside chat over keynote for a high-profile guest who is not a polished presenter - the sourced substitution.
The workshop day is what this order starves: second on value, second on effort, so it never wins a marginal program hour. Promotion condition: it stops competing for program hours once it moves out of the program - a separately ticketed bracketing day (see the shape ladder), where it also becomes a revenue lever.
Panels sit last on every axis, and for a first event they are deleted, not demoted (the sourced ladder cuts them entirely - hardest format to execute, most-criticized: Fred Wilson, Brad Feld, Scott Berkun, Duncan Green, by name in the catalog reference). Promotion condition for an established event, keyed to Q10: a strong, prepared, willing-to-interrupt moderator with pre-briefed provocative questions, and no long self-introductions. Absent that moderator, the option stays off the menu.
Protect the hallway track as a format choice, not leftover time: long breaks, good food, quiet rooms (Monktoberfest optimized its start time around it).

从目录中组合一天；每种形式的具体机制和失败模式见 references/session-format-catalog.md。边缘项目工时的排序（默认，而非铁律）：

工作量（每节目工时的组织者小时数，做得好）：

小组讨论 > 工作坊日 > 策展演讲 > 炉边对话 > Ignite块 > 开放空间

价值（每工时的学习 + 连接 + 持久资产）：

策展演讲 > 工作坊日 > 开放空间 > 炉边对话 > Ignite块 > 小组讨论

效率：

开放空间 > Ignite块 > 策展演讲 > 炉边对话 > 工作坊日 > 小组讨论

默认骨干：策展的约25-30分钟演讲——内容的有来源平衡点，也是活动的录制资产。
Ignite块和开放空间是效率领导者：内容策展成本接近零，它们解决了真正的节目问题（首次演讲者数量；自选相关性和工具特定内容的减压阀）。
对于不擅长演讲的高知名度嘉宾，用炉边对话取代主题演讲——有来源的替代。
工作坊日是这个排序所饿死的：价值第二，工作量第二，所以它永远赢不了边缘项目工时。推广条件：一旦它移出节目，就不再竞争节目工时——作为单独售票的括号日（见形态阶梯），在那里它也变成了收入杠杆。
小组讨论在每个轴上都排在最后，对于首次活动，它们被删除，而不是降级（有来源的阶梯完全砍掉了它们——最难执行的格式，最受批评的：Fred Wilson、Brad Feld、Scott Berkun、Duncan Green，在目录参考中指名道姓）。针对已建立活动的推广条件，与Q10相关：一个强大的、有准备的、愿意打断的主持人，有预先简报的挑衅性问题，并且没有冗长的自我介绍。缺少那个主持人，该选项保持关闭。
保护走廊轨道作为一种格式选择，而不是剩余时间：长休息、好食物、安静房间（Monktoberfest围绕它优化了开始时间）。

Delivery mode

交付模式

Ranking (default, not a law - Q8 evidence can promote the starved rung):

effort:

interactive hybrid > fully virtual == in-person with record-and-post

value (engagement depth + reach):

interactive hybrid > in-person with record-and-post > fully virtual

efficiency:

in-person with record-and-post > fully virtual > interactive hybrid

The

==

is argued: each single mode is one full production, and the cost centers substitute for each other. CHI's published figures price the hybrid platform "similar… to a physical convention centre rental," and MLH warns "a well run digital hackathon is more than just a Discord."

CHI's other figure - virtual logistics support at double the physical event's - prices the virtual layer of a hybrid run, not a standalone virtual production, so it does not break the tie. Hybrid is not a third production of the same size; it is both at once.

In-person with record-and-post - the default and the pattern that survived the post-2022 shake-out: full room, talks recorded and posted (or streamed one-feed, unmonitored) afterward. The remote audience gets the content asynchronously without a second live production.
Fully virtual - legitimate when the community itself has cost or access reasons to stay all-remote (MLH's digital format is global by design). A deliberate single-mode choice, not a downgrade.
Interactive hybrid - the starved option for conferences, argued on the published record: hybrid roughly doubled AV and logistics cost, virtual fees did not cover virtual costs, CHI 2022 lost $484,886, and free livestreams draw well under 10% of sign-ups (figures and caveats in references/delivery-mode-evidence.md). Promotion condition: remote registrations reliably above ~25-30% of paid attendance and covering their marginal cost, plus a dedicated production budget sized for roughly double AV/logistics. For hackathons, hybrid is deleted, not starved: MLH refuses hybrid outright ("worse for both organizers and hackers") with a named failure-mode list - pick in-person or digital and commit.

排序（默认，而非铁律——Q8证据可以提升饥饿档）：

工作量：

交互式混合 > 完全虚拟 == 线下录制后发布

价值（参与深度 + 覆盖范围）：

交互式混合 > 线下录制后发布 > 完全虚拟

效率：

线下录制后发布 > 完全虚拟 > 交互式混合

==

是有争议的：每种单一模式都是一个完整的制作，成本中心相互替代。CHI的已发布数字将混合平台定价为“类似于……物理会议中心租金”，而MLH警告“一个运行良好的数字黑客松不仅仅是一个Discord。”

CHI的另一个数字——虚拟物流支持是实体活动的两倍——定价的是混合运行中的虚拟层，而不是独立的虚拟制作，因此它没有打破平局。混合不是相同规模的第三个制作；它是同时做两者。

线下录制后发布 - 默认，也是2022年后洗牌中幸存下来的模式：满堂观众，演讲录制并在之后发布（或单feed流媒体，无人监控）。远程受众异步获得内容，无需第二次现场制作。
完全虚拟 - 当社区本身有成本或访问原因保持全远程时是合理的（MLH的数字格式天生就是全球性的）。这是一个深思熟虑的单模式选择，不是降级。
交互式混合 - 会议的饥饿选项，基于已发布的记录论证：混合大约使AV和物流成本翻倍，虚拟费用无法覆盖虚拟成本，CHI 2022亏损$484,886，免费直播的签到率远低于10%（数字和注意事项在 references/delivery-mode-evidence.md）。推广条件：远程注册可靠地高于付费出席率的约25-30%并且覆盖其边际成本，加上专门的生产预算，规模大约翻倍的AV/物流。对于黑客松，混合被删除，而不是饿死：MLH完全拒绝混合（“对组织者和黑客都更糟”），并有一份命名的失败模式清单——选择线下或数字并承诺。

Hackathon demo/judging structure

黑客松演示/评审结构

Structural choice only - rubric, weights, and jury mechanics belong to

samber/dev-event-organizer-skills@hackathon-judging

. Ranking (default, not a law; borrowed from adjacent practice - see the catalog reference):

effort (judge-hours + staging per team):

two-stage expo-then-finals > stage pitch > expo table > video only

value (judge interaction depth + winner-narrative legibility):

two-stage expo-then-finals > stage pitch > expo table > video only

efficiency at scale:

video only > expo table > two-stage expo-then-finals > stage pitch

Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations - clean only by construction, and that is not a pass. Value and effort are the same list, so one mechanism blocks every pair: the structure that buys deeper judge interaction costs strictly more judge-hours and staging.

Nothing else is printed that could block or rescue a pair. The check catches no misordering; what follows is argument, not verification.

Expo table - the default: real judge-demo interaction, parallel so it scales.
Two-stage - the starved option: top of both value axes, top of effort, so efficiency never picks it; promotion condition, keyed to Q11: press or sponsor reporting needs a legible on-stage finale.
Video only - the digital-format default and the only structure that scales past what judge-hours allow.

Match format to jury composition: technical judges need to touch the demo; business judges need the narrative slot.

仅结构性选择——评分标准、权重和评委机制属于

samber/dev-event-organizer-skills@hackathon-judging

。排序（默认，而非铁律；借自相邻实践——见目录参考）：

工作量（评委小时数 + 每队的分阶段）：

两阶段展位-决赛 > 舞台演示 > 展位台 > 仅视频

价值（评委互动深度 + 获胜者叙事的清晰度）：
```
两阶段展位-决赛 > 舞台演示 > 展位台 > 仅视频
```

规模效率：

仅视频 > 展位台 > 两阶段展位-决赛 > 舞台演示

支配性检查：4档，6对，零严格支配关系——仅通过构造清空，那不是通过。 价值和努力是同一张列表，所以一个机制阻止了每一对：购买更深评委互动的结构严格花费更多的评委小时数和分阶段。

没有打印其他可以阻止或拯救一对的东西。检查没有发现错误排序；接下来是论证，不是验证。

展位台 - 默认：真实的评委演示互动，并行所以可扩展。
两阶段 - 饥饿选项：两个价值轴的顶部，努力顶部，所以效率永远不会选择它；推广条件，与Q11相关：媒体或赞助商报告需要清晰的台上结局。
仅视频 - 数字格式的默认，也是唯一能扩展到超过评委小时数允许范围的结构。

将格式与评委构成相匹配：技术评委需要接触演示；商业评委需要叙事时段。

Failure modes

失败模式

Hybrid chosen as the safe compromise. It is the maximum-cost, maximum-risk option, not the middle: two simultaneous productions, doubled AV/logistics, and a remote audience that reports feeling second-class. Weigh the sourced cost list; don't split the difference.
Multi-track read as a quality upgrade. Five independent single-track manifestos say otherwise; multi-track is a scale and agency decision with a sourced promotion trigger. Reaching for it below ~8-10x CFP oversubscription buys empty rooms and a fragmented event.
Graduating the ladder on headcount alone. The sourced gates are content depth, venue-risk tolerance, and speaker supply. GopherCon debuting at 700 does not make 700 a threshold; DartUP jumped at 250.
Inventing an industry-average workshop percentage. Cite the named-event ratios and let the spread between them stand; collapsing them into one number invents a norm the events themselves do not share.
A panel scheduled to flatter sponsors or fill a slot. The sourced consensus is brutal; without the prepared-moderator promotion condition, replace it with a fireside chat or one more curated talk.
Track count and content policy decided separately. The single curated track is what makes a "conceptual talks on stage, tool talks in open space" rule enforceable - decide them together or the rule dies in track two.
Copying a named event's structure without its constraints. Monktoberfest's smallness and Strange Loop's curation are worked-backward-from-venue, turn-down-hundreds choices. Import the reasoning, not the surface shape.
Selling program slots to cover the format's cost. Every sourced community event refuses stage inventory to sponsors; funding structure belongs to
```
samber/dev-event-organizer-skills@event-budget
```
, not to the program.

混合作为安全妥协被选择。 它是最大成本、最大风险的选项，而不是中间项：两个同时进行的制作、翻倍的AV/物流、以及报告感觉像二等公民的远程受众。权衡有来源的成本清单；不要折中。
多轨被理解为质量升级。 五份独立的单轨宣言说不是；多轨是一个规模和自主权决定，有有来源的推广触发器。在约8-10倍CFP超额订阅之下，购买的是空房间和碎片化的活动。
仅凭人数升级阶梯。 有来源的门槛是内容深度、场地风险容忍度和演讲者供给。GopherCon在700人时首次亮相并不会使700成为阈值；DartUP在250人时跳跃。
发明行业平均工作坊百分比。 引用命名活动的比率，让它们之间的差异存在；将它们合并成一个数字发明了活动本身并不分享的规范。
为了讨好赞助商或填补时段而安排小组讨论。 有来源的共识是残酷的；没有准备好的主持人推广条件，用炉边对话或另一场策展演讲取代它。
轨道数量和内容政策分开决定。 单一策展轨道是使“概念演讲在台上，工具演讲在开放空间”规则可执行的原因——一起决定它们，否则规则在第二轨道中就死掉了。
复制命名活动的结构而不顾其约束。 Monktoberfest的小规模和Strange Loop的策展是从场地反向推导、拒绝数百人的选择。导入推理，而不是表面形态。
出售议程时段以覆盖格式成本。 每个有来源的社区活动都拒绝向赞助商出售舞台库存；资金结构属于
```
samber/dev-event-organizer-skills@event-budget
```
，而不是议程。

Measurement

测量

Format choices are testable edition over edition. Each measure below is marked published or self-set; adapt the self-set gates per event.

Delivery-mode check (published figures): if a stream or virtual tier ran, compare engaged remote attendance to the sub-10%-of-sign-ups livestream benchmark (indicative only - the figure comes from academic conferencing, not tech; see the reference) and the ~25-30% promotion threshold. Below them, the hybrid spend fails its own test next edition.
CFP pressure (published figures): applicant-to-slot ratio against the ~8-10x multi-track trigger - the only published trigger for adding a track. Read it as the floor where the conversation opens, not as evidence the CFP is broken: swyx's own figures make 8-30x oversubscription normal at a popular single-track event.
Workshop sell-through (self-set): separately ticketed workshop days that don't sell to a threshold you fix in advance (e.g. 60% of capacity) argue for fewer next edition; the bracketing model makes this reversible.
Session-mix signals (self-set): open-space marketplace filling its wall, ignite-slot application volume, room walkouts during panels. Pick 2-3, decide the revision they would trigger, and write both down before the event.
Sellout speed, attendee retention, and sponsor renewal read on the whole event, not the format - they belong to
```
samber/dev-event-organizer-skills@event-market-fit
```
.

格式选择是一版一版可测试的。下面的每个度量都标记为已发布或自我设定；根据活动调整自我设定的门槛。

交付模式检查（已发布数字）：如果运行了直播或虚拟层，将参与的远程出席率与低于10%签到率的直播基准（仅作参考——该数字来自学术会议，而非技术领域；见参考）以及约25-30%的推广阈值进行比较。低于它们，混合支出在下一次版本中无法通过自己的测试。
CFP压力（已发布数字）：申请与名额的比例与约8-10倍多轨触发器——唯一已发布的增加轨道的触发器。将其视为对话开启的底线，而不是CFP有问题的证据：swyx自己的数字使8-30倍的超额订阅在流行的单轨活动中是正常的。
工作坊售罄率（自我设定）：单独售票的工作坊日如果没有达到你预先设定的阈值（例如60%容量），则支持下一版减少；括号模型使这可以逆转。
会议组合信号（自我设定）：开放空间市场填满其墙、Ignite时段申请量、小组讨论期间房间走人。选择2-3个，决定它们会触发的修订，并在活动前把两者写下来。
售罄速度、参会者留存和赞助商续约读取的是整个活动，而不是格式——它们属于
```
samber/dev-event-organizer-skills@event-market-fit
```
。

Invocation examples

调用示例

"Our Rust meetup pulls 120 people every month. Should we run a conference, and what shape?"
"We're debating adding a second track next year - the CFP had 90 submissions for 24 slots."
"The CEO wants our user conference hybrid so remote customers can join live. Talk me through it."
"Design the day: one day, 200 attendees, community-run, more first-time speakers on stage."

Expected output: a format brief with (1) the chosen shape and the graduation evidence behind it, (2) track count with the content-mix rule it enables, (3) the session-format mix as a day architecture, (4) delivery mode with its promotion/deletion reasoning, (5) for each choice, the sourced trigger that would revise it next edition. Presented section by section for validation, with 2-3 candidate structures and one recommendation up front.

“我们的Rust meetup每月吸引120人。我们应该办会议吗，什么形态？”
“我们在争论明年增加第二条轨道——CFP有90份申请争夺24个名额。”
“CEO希望我们的用户会议采用混合模式，以便远程客户实时加入。给我讲讲。”
“设计这一天：一天，200名参会者，社区运营，更多首次演讲者上台。”

预期输出：一份格式简报，包含（1）所选形态及其背后的升级证据，（2）轨道数量及其启用的内容组合规则，（3）作为一天架构的会议形式组合，（4）交付模式及其推广/删除理由，（5）对于每个选择，会修订它的有来源的触发器。逐节呈现以供验证，前面有2-3个候选结构和一个推荐。

References

参考

references/format-precedents.md - graduation trajectories (DartUP, GopherCon, RailsConf/Rails World, North Bay Python), the five single-track manifestos with quotes, the DevOpsDays day architecture, per-event workshop ratios, community-vs-vendor session-selection evidence.
references/session-format-catalog.md - mechanics, costs, and failure modes per session format: curated talks, Ignite, open space, Lean Coffee, keynote/fireside/panel guidance with the named critics, workshop-day model, hackathon judging-format table.
references/delivery-mode-evidence.md - CHI's published hybrid finances, SIGMETRICS retreat, the sub-10% livestream figure, MLH's anti-hybrid failure-mode list, and the benchmarks that would revise the default.