Back to Details

virtual-event-production

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Virtual Event Production

虚拟活动制作

You run delivery for an event with no room. A software platform is the venue, each attendee's own connection is the uplink, and the crew is a moderator roster plus a remote-speaker pipeline rather than a stage crew. Treat the format as settled: 
samber/dev-event-organizer-skills@event-format-selection
already chose fully-virtual. Never re-argue that choice.
你负责执行一个没有实体房间的活动。软件平台就是场地，每位参会者自己的连接就是上行链路，工作人员是一个主持人名册加一条远程演讲者流程，而不是舞台工作人员。将形式视为已定：
samber/dev-event-organizer-skills@event-format-selection
已经选择了全虚拟。绝不要重新争论这个选择。

Where the room disappears

房间消失之处

This boundary is written from your side only. Confirm it rather than implying an agreed handoff.
samber/dev-event-organizer-skills@event-production
owns capture-through-published-master for any event with a physical room to instrument, including whatever stream that room also produces. It stops at the recorded or streamed output.
Its whole model has meaning only where a room exists: a mixing board, a camera on the board feed, a crew watching a monitor, a stage manager, the coverage tier named for a smartphone at the back of a room. You start where the room disappears entirely.
  • Capture. A camera pointing at a physical stage is 
    samber/dev-event-organizer-skills@event-production
    's signal path, not yours, even when the audience is remote. Own the case with no stage to point at.
  • The remote attendee's day. 
    samber/dev-event-organizer-skills@event-attendee-experience
    scopes itself to "the general-attendee on-site journey" and keys every mechanic (badge desk, wayfinding, quiet room) to a signed floor plan, so it says nothing about a remote attendee's journey. Cover that mirror here; that skill does not know this one exists.
  • The channel architecture. 
    samber/dev-event-organizer-skills@event-comms-channels
    owns which channels exist, who is on each, and which class of message routes where, for remote and physical attendees alike. Consume its roster. Add only the live in-session question surface and the staffing that watches it, and reuse its standing-moderation-cost argument rather than deriving a second one.
  • Speaker care. 
    samber/dev-event-organizer-skills@event-speaker-experience
    owns the speaker relationship end to end, including the recording consent record you may not publish past. Its tech check happens on "the actual stage equipment" and its green room is a physical space, so remote connectivity testing, home-setup guidance and local backup recording fall to you. Hand the results back.
  • The day. 
    samber/dev-event-organizer-skills@event-run-of-show
    builds a cue sheet keyed to rooms, room leads, and an organizer-only channel. One coordination channel reserved for the organizing team, separate from every attendee-facing one, carries over to a virtual event unchanged. Nothing else about a room-keyed cue sheet does.
  • Accessibility. 
    samber/dev-event-organizer-skills@event-accessibility-inclusion
    decides whether captions are required and to what standard. Deliver them on the platform and report what the platform can and cannot do. Never set the bar yourself.
Every ranking below is a default, not a law. After the interview, re-rank all four menus against what you already know. Each of these overturns a default rung:
  • a community that already lives in a chat space
  • an organizer who has streamed before
  • a platform an employer or sponsor has already paid for
  • a previous edition whose feed died
Each promotion condition below names its interview question inside the condition's own text, and each trigger in an "or" list is keyed separately rather than riding on the first. Never source a condition from the re-ranking list above: that is a standing instruction, not an answer the interview collected. The four delete items cite no question on purpose - each is deleted unconditionally, on an argument that holds whatever the user answers.
这个边界只从你这一侧书写。确认它，而不是暗示已达成一致交接。
samber/dev-event-organizer-skills@event-production
拥有任何有实体房间可布置设备的事件的“采集到已发布成片”环节，包括该房间同时产生的任何流。它止步于录制或流式输出。
它的整个模型只有在存在房间时才有意义：调音台、对着调音台信号的摄像机、盯着监视器的工作人员、舞台监督、以房间后排智能手机命名的覆盖级别。你从房间完全消失的地方开始。
  • 采集。 对着实体舞台的摄像机是 
    samber/dev-event-organizer-skills@event-production
    的信号路径，不是你的，即使观众是远程的。拥有“没有舞台可拍”的情况。
  • 远程参会者的一天。 
    samber/dev-event-organizer-skills@event-attendee-experience
    将自身限定为“普通参会者的现场旅程”，并将每个机制（胸牌台、导引、安静室）绑定到已签字的平面图上，因此它没有说明远程参会者的旅程。在此覆盖那个镜像；那个 skill 不知道这个 skill 存在。
  • 渠道架构。 
    samber/dev-event-organizer-skills@event-comms-channels
    拥有存在哪些渠道、每个渠道上有谁、以及哪类消息路由到何处，无论远程还是现场参会者。消费它的名册。只添加实时的会中问题界面和监视它的工作人员，并复用其常设主持成本论证，而不是派生出第二个。
  • 演讲者关怀。 
    samber/dev-event-organizer-skills@event-speaker-experience
    端到端拥有演讲者关系，包括你不能发布超出范围的录制同意记录。它的技术检查发生在“实际舞台设备”上，它的候场室是物理空间，因此远程连接测试、家庭设置指南和本地备份录制由你负责。将结果交回。
  • 活动当天。 
    samber/dev-event-organizer-skills@event-run-of-show
    构建一个以房间、房间负责人和仅组织者频道为键的提示表。一个保留给组织团队的协调频道，与所有面向观众的频道分开，在虚拟活动中不变地延续。房间键控提示表的其他一切都不延续。
  • 无障碍。 
    samber/dev-event-organizer-skills@event-accessibility-inclusion
    决定是否需要字幕以及需要什么标准。在平台上交付它们，并报告平台能与不能做什么。绝不要自己设定标准。
下面的每个排序都是默认值，不是法则。访谈之后，根据你已经知道的情况重新排序所有四个菜单。以下每一项都会推翻一个默认层级：
  • 一个已经生活在聊天空间中的社区
  • 一个以前直播过的组织者
  • 一个雇主或赞助商已经付费的平台
  • 上一届的流中断过
下面的每个晋升条件都在条件自身的文本中命名了其访谈问题，并且“或”列表中的每个触发条件都单独键控，而不是依附于第一个。绝不要从上面的重新排序列表中引用条件：那是一条常设指令，不是访谈收集到的答案。四个删除项故意不引用任何问题——每一个都被无条件删除，基于一个无论用户回答什么都成立的论证。

Interview

访谈

Ask one question at a time, multiple-choice where possible. Questions 7-9 exist because the menus diverge sharply on time-to-effect, durability and effort, and those orderings cannot be picked for the user.
  1. Is there an interaction surface at all, or is this a feed people watch? This reorders every menu below, and it decides whether Menu 3 exists at all.
  2. How many sessions run at the same time, and how long is the shortest gap between them?
  3. Where are the speakers and where is the audience - one time zone, or a spread wide enough that somebody presents in the middle of their night?
  4. What did the format decision promise, and to whom: a paid virtual ticket, a sponsor deliverable naming the stream, an access commitment to people who cannot travel?
  5. What is the recording and publication consent posture per session, and where is that record held? Do attendees appear on camera anywhere - a breakout, a networking room, a Q&A?
  6. Does anything constrain where attendee data may be held or which platform may be used - an employer's procurement, a sponsor's contract, an umbrella organization's rules?
  7. What is the last date a platform choice can still be reversed? That deadline, not the event date, is what these menus are ranked against.
  8. One-off edition or a recurring event? A recurring event promotes every rung whose payoff lands after this edition: a rehearsed crew, a warm fallback path, a home-setup note you send again next year.
  9. What is the effort ceiling - how many people can be doing only production during a session rather than also doing something else, and who is still available the week after?
  10. What already exists that should re-rank these defaults: a chat space your audience is already in, an organizer who has run a stream before, a platform somebody already pays for, last edition's failures?
  11. Which sessions cannot be re-run or rescheduled, which carry a live demo, and which speakers have an unknown connection or have never presented on this platform? Nothing else above reaches what a session contains or how badly it must not fail, and four rungs below promote on exactly that.
一次问一个问题，尽可能提供多选。问题 7-9 存在是因为菜单在生效时间、持久性和工作量上分歧很大，而这些排序不能替用户选择。
  1. 是否存在互动界面，还是这只是一条人们观看的流？ 这会重新排序下面的每个菜单，并决定菜单 3 是否根本存在。
  2. 同时运行多少场议程？它们之间最短间隔多长？
  3. 演讲者和观众在哪里——同一个时区，还是分布广到有人会在半夜演讲？
  4. 形式决策承诺了什么，向谁承诺：付费虚拟门票、点名流的赞助商交付物、对无法出行的人的可及性承诺？
  5. 每场议程的录制和发布同意立场是什么？该记录保存在哪里？参会者是否在任何地方出现在镜头中——分组讨论、社交室、问答？
  6. 是否有任何东西限制参会者数据的存储位置或可使用的平台——雇主的采购、赞助商的合同、伞式组织的规则？
  7. 平台选择仍可被撤销的最后日期是哪天？这些菜单正是以该截止日期（而非活动日期）为排序依据。
  8. 一次性活动还是周期性活动？周期性活动会提升每一个在本届之后才有回报的层级：一支排练过的团队、一条热备回退路径、一份明年还会再发的家庭设置说明。
  9. 工作量上限是多少——一场议程中能有多少人只做制作而不是同时做其他事？一周后谁仍然可用？
  10. 已经存在哪些东西应该重新排序这些默认值：你的观众已经在其中的聊天空间、以前运营过直播的组织者、某人已付费的平台、上一届的失败？
  11. 哪些议程无法重跑或改期，哪些包含现场演示，哪些演讲者的连接未知或从未在该平台上演讲过？ 上面没有任何其他问题触及议程包含什么或它绝对不能出多严重的错，而下面四个层级正是据此晋升。

What actually splits this work

真正划分这项工作的是什么

The community-run versus vendor-run pole decides less here than it looks. A packet takes the same milliseconds whoever funded the event. What it does decide is Q6: a vendor-run event arrives more often with a platform already forced on it by procurement, which deletes a rung rather than reordering one.
Two answers reshape every menu, in this order: whether an interaction surface exists, then how many sessions run at once.
  • A single feed with comments closed is a broadcast, and needs almost nothing.
  • Three simultaneous tracks with open chat is a staffing problem before it is a technical one.
Say which of the two a recommendation assumes whenever they differ.
社区运营与供应商运营的两极在这里决定得比看起来少。无论谁资助活动，一个数据包都花费相同的毫秒。它确实决定的是 Q6：供应商运营的活动更常带着一个已被采购强加的平台到来，这删除一个层级而不是重新排序一个。
两个答案按此顺序重塑每个菜单：是否存在互动界面，然后同时运行多少场议程。
  • 一条关闭评论的单一流就是广播，几乎不需要什么。
  • 三个同时开放聊天的并行分会场，在成为技术问题之前首先是一个人员配置问题。
当两者不同时，说明建议假设的是哪一种。

Workflow

工作流

  1. Fix the interaction posture in one line - a feed people watch, or an event people are inside. Write it down before anything else; every menu below is a consequence of it.
  2. Read the inputs rather than re-collecting them: the channel roster, the per-speaker consent record, the accessibility bar, and whatever the format decision promised.
  3. Choose the platform posture (Menu 1), then put the vendor questions in references/platform-selection-and-vendor-questions.md to whoever can answer them, in writing, before committing.
  4. Choose remote-speaker readiness depth (Menu 2) and send the home-setup note the same day acceptances go out. Details in references/remote-speaker-readiness.md.
  5. Staff moderation (Menu 3) per concurrent session, by name, not by function. Skip this step entirely if step 1 said "a feed people watch".
  6. Pick the failure-drill depth (Menu 4) and publish the fallback line where the audience will look for it, before the day. Runbook in references/moderation-and-failure-drills.md.
  7. Rehearse once, on the platform the event actually runs on. This is the step that gets cut, and a rehearsal on a different tool tests nothing.
  8. Hand the cost consequence to 
    samber/dev-event-organizer-skills@event-budget
    , split by what a lean tier drops: the feed itself survives every tier; the interaction surface and its staffing go first.
  9. After the event, hand captured sessions to 
    samber/dev-event-organizer-skills@event-content-repurposing
    and the recording consent check back to 
    samber/dev-event-organizer-skills@event-speaker-experience
    .
Present the plan section by section for validation - interaction posture, then platform, then speakers, then moderation staffing, then the drill - before any contract is signed. After signature, a platform change costs money rather than a conversation.
If your harness has persistent memory, record per edition:
  • which platform posture was chosen and what its vendor answers actually were
  • which speakers needed which readiness rung
  • how many moderators were genuinely busy versus idle
  • every failure and which drill caught it
  • what the audience did in the minutes after a feed dropped
A platform used twice is worth not re-learning.
  1. 用一句话确定互动姿态——人们观看的流，还是人们置身其中的活动。先把它写下来；下面每个菜单都是它的结果。
  2. 读取输入而不是重新收集： 渠道名册、每位演讲者的同意记录、无障碍标准，以及形式决策承诺的任何内容。
  3. 选择平台姿态（菜单 1），然后在承诺之前将供应商问题以书面形式交给能回答的人，详见 references/platform-selection-and-vendor-questions.md。
  4. 选择远程演讲者就绪深度（菜单 2），并在接受通知发出的当天发送家庭设置说明。详见 references/remote-speaker-readiness.md。
  5. 为每个并发议程配备主持人员（菜单 3），按名字而非按职能。如果第 1 步说的是“人们观看的流”，则完全跳过此步骤。
  6. 选择故障演练深度（菜单 4），并在活动日前将回退说明发布到观众会去看的地方。运行手册见 references/moderation-and-failure-drills.md。
  7. 在活动实际运行的平台上排练一次。 这是最常被砍掉的步骤，而在不同工具上的排练什么都测不出来。
  8. 将成本后果交给 
    samber/dev-event-organizer-skills@event-budget
    ，按精简层级会放弃什么来拆分：流本身在每个层级都保留；互动界面及其人员配置最先被砍掉。
  9. 活动结束后，将录制好的议程交给 
    samber/dev-event-organizer-skills@event-content-repurposing
    ，并将录制同意核查交回 
    samber/dev-event-organizer-skills@event-speaker-experience
    。
在签署任何合同之前，逐节呈现计划以供验证——互动姿态、平台、演讲者、主持人员配置、演练。签署后，更换平台要花钱，而不再是一场对话。
如果你的 harness 有持久记忆，请按届记录：
  • 选择了哪种平台姿态，供应商的答案实际上是什么
  • 哪些演讲者需要哪一级就绪层级
  • 多少主持人真正忙碌，多少闲置
  • 每一次失败，以及哪个演练抓住了它
  • 流中断后几分钟内观众做了什么
使用过两次的平台值得不再重新学习。

Menu 1 - Platform posture

菜单 1 - 平台姿态

The platform is your venue. Rank it like one: what it costs to acquire, what it costs to run, and what it actually buys the person watching.
Ranking (default, not a law - Q1, Q6, Q7 and Q10 re-rank it):
  • ops effort (setup hours, people on the day, skill required): 
    assembled stack > managed virtual-venue platform > broadcast tool with a built-in question queue > one-way feed plus the existing chat space > single one-way feed
  • procurement cost (lead time to acquire, commitment signed, how reversible up to the date): 
    managed virtual-venue platform > broadcast tool with a built-in question queue > assembled stack == one-way feed plus the existing chat space > single one-way feed
    - argued tie: both are assembled from things you can start and abandon in the same week, with nothing signed. The assembled stack's real price is paid in hours, and those already sit on the effort line above; the existing chat space was procured for another reason and this decision does not commit it further.
  • value, reach (a watchable, audible talk arrives at a person on their own home connection): 
    single one-way feed == one-way feed plus the existing chat space > broadcast tool with a built-in question queue > managed virtual-venue platform == assembled stack
    - argued tie at the top: the chat space sits beside the feed rather than inside it, so it adds nothing the video path has to carry. Argued tie at the bottom: both put the viewer behind a login and a bespoke player instead of a public video platform's delivery, and both add moving parts between the speaker and the viewer.
  • value, interaction (attendees reach the speaker and each other, live): 
    managed virtual-venue platform > assembled stack > one-way feed plus the existing chat space == broadcast tool with a built-in question queue > single one-way feed
    - argued tie: one buys attendee-to-attendee conversation with no question discipline, the other buys a disciplined question queue with no peer space. Neither buys both, and which one is worth more depends on Q1's answer, not on this ordering.
  • compliance cost (the review it triggers and what stops being reversible): 
    managed virtual-venue platform > assembled stack > broadcast tool with a built-in question queue == one-way feed plus the existing chat space > single one-way feed
    - argued tie: both hold attendee identity inside one vendor's chat or question record and nothing more; neither creates a directory a third party can export. The top rung is different in kind: an attendee directory and sponsor-facing lead capture trigger a data-handling review before signature, and a list a sponsor has already exported cannot be recalled. The assembled stack sits second because you chose each component's jurisdiction yourself, which is a review you own rather than one a vendor's terms performed for you.
  • efficiency: 
    single one-way feed > one-way feed plus the existing chat space > managed virtual-venue platform > assembled stack > broadcast tool with a built-in question queue
Dominance check: 5 rungs, 10 pairs, four cost-and-value axes plus compliance, one real strict-dominance relation.
  • The one-way feed plus the existing chat space strictly dominates the broadcast tool with a built-in question queue: cheaper on ops effort, cheaper on procurement, tied on compliance, better on reach, tied on interaction. Dominance asks for no-worse on every axis and strictly-better on at least one; the two ties count as part of the relation, not as gaps in it, since this pair is strictly better on three axes.
  • Eight of the remaining nine pairs are blocked by the interaction axis running opposite to effort: the rungs that buy conversation cost strictly more to acquire and to run. One of those eight, the broadcast tool against the assembled stack, is blocked twice over, since procurement also runs opposite to ops effort there.
  • The last pair, the managed platform against the assembled stack, is blocked by procurement and compliance running opposite to ops effort and interaction: the managed platform is the lighter one to run and the heavier one to commit to.
  • That accounts for all ten pairs (1 relation + 8 + 1).
One warning about the reach axis. Taken alone it is close to rank-identical to inverse effort, and would collapse this menu into cheapest-first, the ordering the ranking discipline exists to prevent. It earns its place only because the interaction axis runs the opposite direction, which is what gives this menu a real dominance relation rather than a vacuous check.
  • One-way feed plus the existing chat space - the default. The feed goes to a public video platform; the conversation happens in the space 
    samber/dev-event-organizer-skills@event-comms-channels
    already designed, with no second login and no second roster.
    Drop to the single one-way feed whenever Q9 says nobody can watch a chat during sessions: an open space in the event's name with nobody on duty is a code-of-conduct obligation with no responder. The published digital-harassment warning applies to it exactly as it does during a staffed session.
  • Single one-way feed - the minimum viable posture, and it wins outright more often than it looks. Comments closed, no accounts, nothing to moderate, the lowest compliance exposure on the page, and the most robust delivery to a person on a phone.
    It is the honest choice for an event whose remote audience wants the talks and not the company. It is not "not running a virtual event" - that decision belongs to 
    samber/dev-event-organizer-skills@event-format-selection
    .
  • Broadcast tool with a built-in question queue - strictly dominated above, and kept on the menu for one reason only: Q6 can arrive with it already chosen and paid for. When it is what you have, run it and spend the saved decision on Menu 3.
  • Assembled stack - separate streaming software, a separate chat platform, a separate schedule page, glued together by you. Cheap to start and reversible, and its whole cost is organizer hours and the seams between components.
    Major League Hacking's warning applies here in full: a well-run digital event is far more than a chat server. That is a hackathon organizer's warning about a hackathon's stack, so read it as a caution about under-estimating the work, not as a verdict on the components.
  • Managed virtual-venue platform - the starved option: tops interaction, tops ops effort, tops procurement and tops compliance, so efficiency never picks it. Promotion conditions, each keyed separately:
    • several sessions running at once with attendees moving between them, keyed to Q2 ("How many sessions run at the same time")
    • a sponsor deliverable that names a virtual booth, or an attendee directory sold as a ticket benefit, both keyed to Q4 ("a paid virtual ticket, a sponsor deliverable naming the stream")
    • a procurement constraint that leaves no alternative, keyed to Q6 ("which platform may be used - an employer's procurement, a sponsor's contract")
  • Delete, do not demote: a second live platform carrying the same sessions in parallel. Delete it from this menu and from the axis lines above. It halves the audience of every question a speaker answers and doubles the moderation, and the failure shows up only as the half of the audience that never got an answer.
平台就是你的场地。像评价场地一样排序它：获得它要花什么，运行它要花什么，以及它实际为观看者买到什么。
排序（默认值，不是法则——Q1、Q6、Q7 和 Q10 会重新排序它）：
  • 运维工作量（搭建小时数、当天人员、所需技能）：
    组装式技术栈 > 托管虚拟场地平台 > 带内置问题队列的广播工具 > 单向流加现有聊天空间 > 单一单向流
  • 采购成本（获取前置时间、签署的承诺、到该日期前可逆性）：
    托管虚拟场地平台 > 带内置问题队列的广播工具 > 组装式技术栈 == 单向流加现有聊天空间 > 单一单向流
    - 论证的并列：两者都是由你可以在同一周内开始并放弃的东西组装而成，无需签署任何东西。组装式技术栈的真正代价以小时支付，而那些小时已经列在上面的工作量线上；现有聊天空间是因另一个原因采购的，这个决定不会进一步承诺它。
  • 价值，触达（一场可看可听的演讲到达一个人自己的家庭连接）：
    单一单向流 == 单向流加现有聊天空间 > 带内置问题队列的广播工具 > 托管虚拟场地平台 == 组装式技术栈
    - 顶部论证的并列：聊天空间位于流旁边而非流内部，所以它没有增加视频路径必须承载的任何东西。底部论证的并列：两者都将观众置于登录和定制播放器之后，而不是公共视频平台的交付，并且两者都在演讲者和观众之间增加了活动部件。
  • 价值，互动（参会者实时触达演讲者和彼此）：
    托管虚拟场地平台 > 组装式技术栈 > 单向流加现有聊天空间 == 带内置问题队列的广播工具 > 单一单向流
    - 论证的并列：一个买到参会者之间的对话但没有提问纪律，另一个买到有纪律的提问队列但没有同伴空间。两者都不能两全，哪个更值取决于 Q1 的答案，而不是这个排序。
  • 合规成本（它触发的审查以及什么变得不可逆）：
    托管虚拟场地平台 > 组装式技术栈 > 带内置问题队列的广播工具 == 单向流加现有聊天空间 > 单一单向流
    - 论证的并列：两者都只在一个供应商的聊天或提问记录中持有参会者身份，仅此而已；两者都不会创建第三方可以导出的目录。最高层级性质不同：参会者目录和面向赞助商的线索捕获会在签署前触发数据处理审查，而赞助商已导出的列表无法召回。组装式技术栈排在第二，因为你自己选择每个组件的管辖范围，这是你拥有的审查，而不是供应商条款替你执行的审查。
  • 效率：
    单一单向流 > 单向流加现有聊天空间 > 托管虚拟场地平台 > 组装式技术栈 > 带内置问题队列的广播工具
支配关系检查：5 个层级，10 对，四个成本与价值轴加合规，一个真正的严格支配关系。
  • 单向流加现有聊天空间严格支配带内置问题队列的广播工具：运维工作量更便宜、采购更便宜、合规并列、触达更好、互动并列。支配关系要求在每一个轴上都不更差，并且至少在一個轴上严格更好；两个并列算作关系的一部分，而不是其中的缺口，因为这一对在三个轴上严格更好。
  • 剩余九对中有八对被互动轴与工作量轴方向相反所阻断：购买对话的层级在获取和运行上严格更贵。这八对中的一对，广播工具对组装式技术栈，被双重阻断，因为采购在那里也与运维工作量相反。
  • 最后一对，托管平台对组装式技术栈，被采购和合规与运维工作和互动方向相反所阻断：托管平台运行起来更轻，但承诺起来更重。
  • 这解释了全部十对（1 个关系 + 8 + 1）。
关于触达轴的一个警告。 单独看它几乎与反向工作量排序相同，会把此菜单塌缩成“最便宜优先”——排序纪律存在正是为了防止这种排序。它之所以占有一席之地，只是因为互动轴朝相反方向运行，这正是让此菜单拥有真正支配关系而非空洞检查的原因。
  • 单向流加现有聊天空间 - 默认项。流进入公共视频平台；对话发生在 
    samber/dev-event-organizer-skills@event-comms-channels
    已经设计好的空间里，无需第二次登录和第二个名册。
    只要 Q9 说议程期间没人能看聊天，就降级到单一单向流：以活动名义开放的无人值守空间是一项没有响应者的行为准则义务。已发布的数字骚扰警告对它适用的程度与对有人员值守的议程完全一样。
  • 单一单向流 - 最低可行姿态，而且它直接获胜的频率比看起来更高。评论关闭、没有账户、无需审核、页面上最低的合规暴露，以及对手机用户最稳健的交付。
    对于一个远程观众只想要演讲而不是社交的活动，它是诚实的选择。它不是“不办虚拟活动”——那个决定属于 
    samber/dev-event-organizer-skills@event-format-selection
    。
  • 带内置问题队列的广播工具 - 在上面被严格支配，保留在菜单上只有一个原因：Q6 可能带着它已被选好并付费的情况出现。当它是你拥有的东西时，就运行它，并把省下的决策花在菜单 3 上。
  • 组装式技术栈 - 独立的流媒体软件、独立的聊天平台、独立的日程页面，由你粘合在一起。启动便宜且可逆，它的全部成本是组织者的小时数和组件之间的接缝。
    Major League Hacking 的警告在这里完全适用：一个运营良好的数字活动远不止一个聊天服务器。那是黑客马拉松组织者关于黑客马拉松技术栈的警告，所以要将其理解为对低估工作的告诫，而不是对组件的判决。
  • 托管虚拟场地平台 - 最不划算的选项：互动最高、运维工作量最高、采购最高、合规最高，所以效率永远不会选择它。晋升条件，各自单独键控：
    • 同时运行多场议程且参会者在其中移动，键控到 Q2（“同时运行多少场议程”）。
    • 点名虚拟展位的赞助商交付物，或作为门票权益出售的参会者目录，两者都键控到 Q4（“付费虚拟门票、点名流的赞助商交付物”）。
    • 一个没有替代方案的采购约束，键控到 Q6（“可使用哪个平台——雇主的采购、赞助商的合同”）。
  • 删除，不降级：并排承载相同议程的第二个直播平台。 从本菜单和上面的轴线上删除它。它会让演讲者回答的每个问题的观众减半并让审核工作量翻倍，而失败只表现为从未得到答案的那一半观众。

Menu 2 - Remote-speaker readiness

菜单 2 - 远程演讲者就绪

A remote speaker's uplink is a domestic internet connection you do not control and cannot inspect. Every rung below either reduces the chance it fails or makes the failure survivable.
Ranking (default, not a law - Q3, Q4, Q8, Q10 and Q11 re-rank it):
  • effort (organizer hours, scheduling, coordination per speaker): 
    individual tech check plus an instructed local backup recording > a pre-recorded talk played to schedule > one shared group tech-check window > a written home-setup note > slides and a join link
  • value, insurance (a usable talk exists whatever the speaker's connection does): 
    a pre-recorded talk played to schedule > individual tech check plus an instructed local backup recording > one shared group tech-check window > a written home-setup note > slides and a join link
  • value, liveness (the session feels live - the speaker is present, reacting, taking a question mid-talk): 
    individual tech check plus an instructed local backup recording > one shared group tech-check window == a written home-setup note > slides and a join link > a pre-recorded talk played to schedule
    - argued tie: both leave the speaker rehearsed enough not to spend the opening minutes discovering the interface, and neither buys the confidence of having presented on it once with somebody watching.
  • compliance cost (the review it triggers and what stops being reversible): 
    a pre-recorded talk played to schedule > individual tech check plus an instructed local backup recording > one shared group tech-check window == a written home-setup note == slides and a join link
    - argued tie: none of the three creates a file, so none adds anything to the consent record beyond what the event's own capture posture already required. The two rungs above do create one, and a recording that exists is a recording somebody will later ask to publish; get that covered in 
    samber/dev-event-organizer-skills@event-speaker-experience
    's consent record before the file exists, not after.
  • efficiency: 
    a written home-setup note > one shared group tech-check window > individual tech check plus an instructed local backup recording > a pre-recorded talk played to schedule > slides and a join link
Dominance check: 5 rungs, 10 pairs, two cost axes and two value axes, zero strict-dominance relations.
  • Two mechanisms account for all ten pairs, and neither covers the other's pairs.
  • Six pairs are blocked because preparation costs strictly more coordination and buys more of both value axes at once: every comparison inside the live-delivery group, plus each of them against the do-nothing rung. Five of the six are strictly better on both value axes; the sixth, the group window against the home-setup note, is strictly more insurance while tying on liveness. That tie still blocks it, because the cheaper rung gains no value axis at all.
  • The other four pairs are blocked by the pre-recording trade specifically: it buys certainty by spending presence, so it wins insurance and loses liveness against every rung it meets, including the pair where it is also the cheaper option.
  • Zero relations means this check caught no misordering; what follows is argument, not verification.
  • A written home-setup note - the default: sent with the join link, asynchronous, reusable next edition, and costing the speaker minutes. It moves the most common failures - a shared connection, a background sync eating the uplink, a laptop camera pointed at a ceiling - before anyone schedules a call.
    Contents in references/remote-speaker-readiness.md. Move up one rung as soon as any speaker has never presented on this platform - keyed to Q11 ("which speakers have an unknown connection or have never presented on this platform").
  • One shared group tech-check window - everyone joins the real platform at the same time, far enough before the day that a failed check can still be fixed. It costs one organizer block rather than one per speaker, and it surfaces platform-wide problems once instead of repeatedly.
  • Individual tech check plus an instructed local backup recording - a scheduled slot per speaker, on the real platform, ending with the speaker set up to record locally on the day. The local recording is the point: a dropped feed then costs the live session and not the talk. Promotion conditions, all three keyed to Q11, which is the only question that reaches them:
    • an unrepeatable session ("Which sessions cannot be re-run or rescheduled")
    • a speaker whose connection is unknown or known-bad ("which speakers have an unknown connection")
    • a talk carrying a live demo ("which carry a live demo")
  • A pre-recorded talk played to schedule, with the speaker live in chat - the starved option: tops insurance, near-tops effort, bottoms liveness, so efficiency never picks it. Its precedent is ACM SIGCHI, which dropped remote attendance entirely and offered authors who cannot travel a pre-recorded video played to the in-person audience. What does not transfer is the setting: that is a physical event's accommodation for an absent author, not a virtual event's default. Promotion conditions, each keyed separately:
    • a session landing in the middle of the speaker's night, keyed to Q3 ("a spread wide enough that somebody presents in the middle of their night")
    • a demo that has already failed live once, keyed to Q11 ("which carry a live demo") together with Q10 ("last edition's failures")
    • a speaker who cannot hold a live slot at all, keyed to Q11 ("which speakers have an unknown connection")
    ACM's own governing-board minutes record no-shows for remote presentations at one of its conferences: a speaker who does not appear is the failure this rung exists to remove.
  • Delete, do not demote: a tech check run on a different tool than the one the event runs on. Delete it from this menu and from the axis lines above. It reads as a check and tests nothing that matters: not the platform's screen-share path, not its audio device handling, not what the speaker's browser does under it. 
    samber/dev-event-organizer-skills@event-speaker-experience
    makes the same demand from its own side for a physical stage - a check on the actual equipment - and the reasoning is identical here.
远程演讲者的上行链路是你无法控制也无法检查的家庭互联网连接。下面的每一个层级要么降低它失败的概率，要么让失败变得可存活。
排序（默认值，不是法则——Q3、Q4、Q8、Q10 和 Q11 会重新排序它）：
  • 工作量（组织者小时数、日程安排、每位演讲者的协调）：
    单独技术检查加带说明的本地备份录制 > 按日程播放的预录演讲 > 一个共享的小组技术检查时段 > 一份书面家庭设置说明 > 幻灯片和加入链接
  • 价值，保险（无论演讲者的连接怎样，都存在一个可用的演讲）：
    按日程播放的预录演讲 > 单独技术检查加带说明的本地备份录制 > 一个共享的小组技术检查时段 > 一份书面家庭设置说明 > 幻灯片和加入链接
  • 价值，实时感（议程感觉是直播的——演讲者在场、在回应、在演讲中接受提问）：
    单独技术检查加带说明的本地备份录制 > 一个共享的小组技术检查时段 == 一份书面家庭设置说明 > 幻灯片和加入链接 > 按日程播放的预录演讲
    - 论证的并列：两者都让演讲者有足够排练，不至于在开场几分钟才摸索界面，而且两者都不能买到“曾在该平台上在有人观看的情况下讲过一次”的信心。
  • 合规成本（它触发的审查以及什么变得不可逆）：
    按日程播放的预录演讲 > 单独技术检查加带说明的本地备份录制 > 一个共享的小组技术检查时段 == 一份书面家庭设置说明 == 幻灯片和加入链接
    - 论证的并列：三者都不会创建文件，所以除了活动自身采集姿态已经要求的之外，它们不会给同意记录增加任何东西。上面两个层级确实会创建一个文件，而存在的一份录制就是某人之后会请求发布的一份录制；在文件存在之前（而不是之后）把它覆盖进 
    samber/dev-event-organizer-skills@event-speaker-experience
    的同意记录。
  • 效率：
    一份书面家庭设置说明 > 一个共享的小组技术检查时段 > 单独技术检查加带说明的本地备份录制 > 按日程播放的预录演讲 > 幻灯片和加入链接
支配关系检查：5 个层级，10 对，两个成本轴和两个价值轴，零个严格支配关系。
  • 两个机制解释全部十对，而且没有一个覆盖另一个的对。
  • 六对因准备成本需要严格更多的协调并同时买到两个价值轴的更多而被阻断：直播交付组内的每一个比较，加上它们每一个对照不做任何事层级。六对中有五对在两个价值轴上严格更好；第六对，小组时段对照家庭设置说明，在保险上严格更多而在实时感上并列。那个并列仍然阻断它，因为更便宜的层级没有获得任何价值轴。
  • 另外四对被预录的权衡专门阻断：它通过花费在场感来购买确定性，所以它在遇到的每一个层级上都赢得保险并输掉实时感，包括在它也是更便宜选项的那一对。
  • 零个关系意味着这个检查没有发现错误排序；接下来的内容是论证，而不是验证。
  • 一份书面家庭设置说明 - 默认项：随加入链接发送、异步、下一届可复用，且只花费演讲者几分钟。它在任何人安排通话之前就消除了最常见的失败——共享连接、后台同步吃掉上行链路、笔记本电脑摄像头对着天花板。
    内容见 references/remote-speaker-readiness.md。只要有演讲者从未在该平台上演讲过，就上升一个层级——键控到 Q11（“哪些演讲者的连接未知或从未在该平台上演讲过”）。
  • 一个共享的小组技术检查时段 - 每个人在同一时间加入真实平台，距离活动日足够远，使失败的检查仍能被修复。它花费组织者一个时间段，而不是每位演讲者一个，并且一次性暴露平台级问题，而不是反复暴露。
  • 单独技术检查加带说明的本地备份录制 - 每位演讲者在真实平台上的一个预定时段，结束时演讲者已准备好当天在本地录制。本地录制是关键：这样一来，流中断只会损失直播议程，而不会损失演讲本身。晋升条件，全部三个键控到 Q11，这是唯一触及它们的问题：
    • 一场无法重演的议程（“哪些议程无法重跑或改期”）。
    • 连接未知或已知不佳的演讲者（“哪些演讲者的连接未知”）。
    • 一场带现场演示的演讲（“哪些包含现场演示”）。
  • 按日程播放的预录演讲，演讲者在聊天中在线 - 最不划算的选项：保险最高、工作量接近最高、实时感最低，所以效率永远不会选择它。它的先例是 ACM SIGCHI，它完全放弃了远程参会，并为无法出行的作者提供向现场观众播放的预录视频。不能迁移的是场景：那是实体活动为缺席作者提供的便利，而不是虚拟活动的默认。晋升条件，各自单独键控：
    • 一场落在演讲者半夜的议程，键控到 Q3（“分布广到有人会在半夜演讲”）。
    • 一个已经在直播中失败过一次的演示，键控到 Q11（“哪些包含现场演示”）和 Q10（“上一届的失败”）。
    • 一个完全无法承担直播时段的演讲者，键控到 Q11（“哪些演讲者的连接未知”）。
    ACM 自己的理事会会议记录记载了其一次会议上远程演讲的未出席情况：一位没有出现的演讲者正是这个层级存在的目的要消除的失败。
  • 删除，不降级：在与活动运行工具不同的工具上运行的技术检查。 从本菜单和上面的轴线上删除它。它看起来像检查，却测不出任何重要的东西：测不出平台的屏幕共享路径、测不出它的音频设备处理、测不出演讲者的浏览器在其下的行为。
    samber/dev-event-organizer-skills@event-speaker-experience
    从自己一侧对实体舞台提出同样的要求——在实际设备上检查——这里的推理完全相同。

Menu 3 - Live moderation staffing

菜单 3 - 实时主持人员配置

Skip this menu entirely if Menu 1 landed on the single one-way feed. With no interaction surface there is nothing to moderate, no rung above the floor exists, and the staffing question does not arise. Everything below assumes a surface is open.
The standing cost of an open space is already argued by 
samber/dev-event-organizer-skills@event-comms-channels
: setup is an hour, moderation is a standing job for the whole time the space is open, and the code-of-conduct duty inside it is identical to the one in a room. Do not re-derive it. This menu adds only the live, in-session layer that skill does not own: who relays a question to a speaker who cannot see chat, and who notices the feed died.
Ranking (default, not a law - Q1, Q2, Q9, Q10 and Q11 re-rank it):
  • effort (people on duty per session-hour): 
    moderator, technical watcher and a host on the feed > moderator plus a technical watcher > one moderator per concurrent session > one moderator across the whole event > no moderation staffing
  • value, the space is held (questions reach the speaker, and conduct is enforced where it happens): 
    moderator, technical watcher and a host on the feed > one moderator per concurrent session == moderator plus a technical watcher > one moderator across the whole event > no moderation staffing
    - argued tie: the technical watcher does not read chat. Moderation capacity is identical across those two rungs; the second person exists entirely for the other value axis.
  • value, silence gets broken (a failure is noticed and named to the audience in the minute it happens): 
    moderator, technical watcher and a host on the feed > moderator plus a technical watcher > one moderator per concurrent session > one moderator across the whole event == no moderation staffing
    - argued tie: one person cannot watch several streams' health at once, so at more than one concurrent session the event-wide moderator notices a dead feed no sooner than nobody does.
  • compliance cost (the review it triggers and what stops being reversible): 
    no moderation staffing > one moderator across the whole event > one moderator per concurrent session == moderator plus a technical watcher == moderator, technical watcher and a host on the feed
    - argued tie: all three put a named responder in every open space during every session, which is the whole of what the duty asks; people added beyond that change who notices a failure, not who is answerable for conduct. This axis runs backwards to every other menu here, and that is the finding: the cheapest rung carries the highest compliance cost, because an open space with nobody watching is an obligation with no responder, and harm inside it cannot be taken back. The Major League Hacking organizer guide is explicit that a digital space raises the risk rather than lowering it. Read the inversion as an argument about who is answerable, never as a legal reading: duty, platform terms and retention differ by country, and belong with the organizer's own counsel.
  • efficiency: 
    one moderator per concurrent session > one moderator across the whole event > moderator plus a technical watcher > moderator, technical watcher and a host on the feed > no moderation staffing
Dominance check: 5 rungs, 10 pairs, two cost axes and two value axes, zero strict-dominance relations.
  • Three mechanisms account for all ten pairs.
  • Eight pairs are blocked by the plain one: staffing costs strictly more people and buys strictly more of everything, including the discharge of the duty.
  • One pair, the do-nothing rung against the event-wide moderator, needs its own account, because the silence axis ties there and "buys more of everything" stops being true. What blocks it is effort against the space-held axis alone: the moderator costs a person and buys the one value axis that still moves. The compliance inversion is not the blocker here, and naming it as one would be wrong; it runs the other way, which is why the moderator is the right call rather than why neither rung dominates.
  • The last pair, one moderator per session against moderator-plus-watcher, is blocked because their moderation capacity is genuinely identical and only the failure-watching axis separates them.
  • Zero relations means the check caught no misordering here.
  • One moderator per concurrent session - the default: one named person per stream that is live at the same time, reading chat, selecting and relaying questions, and holding conduct. It scales with tracks rather than with attendance, which is why it needs no attendee ratio at all.
  • One moderator across the whole event - sufficient and correct for a single-track day, and it is the same rung as the default when Q2 says one session runs at a time. It fails the moment two things happen at once.
  • Moderator plus a technical watcher - a second person per session whose only job is whether the feed is up, audible and in sync. The pattern behind it is a physical event's livestream needing "at least one person to run it during the event" (DevOpsDays organizing guide). What does not carry across is the equipment: there is no board to run, so this person watches the output as an audience member sees it, from outside the production path. Promotion conditions, keyed separately:
    • anything live that cannot be re-run, keyed to Q11 ("Which sessions cannot be re-run or rescheduled")
    • a previous edition where a dead feed went unnoticed, keyed to Q10 ("last edition's failures")
  • Moderator, technical watcher and a host on the feed - the starved option: tops both value axes and tops effort, so efficiency never picks it. It is the only rung where somebody actually says something to the audience when a talk fails - an empty stream with a chat full of "is it just me?" is the failure mode the two rungs below leave open. Promotion conditions, each keyed separately:
    • a paid virtual ticket, or a sponsor deliverable naming the stream, both keyed to Q4 ("a paid virtual ticket, a sponsor deliverable naming the stream")
    • a multi-hour continuous programme with gaps to fill, keyed to Q2 ("how long is the shortest gap between them")
    • an audience that has no other way to find out what is happening, keyed to Q1 ("Is there an interaction surface at all, or is this a feed people watch")
  • Delete, do not demote: the speaker moderating their own chat while presenting. Delete it from this menu and from the axis lines above. It reads as the free version of moderation and it is not a rung: a presenting speaker is doing two jobs badly, and no speaker can enforce a code of conduct against a person in their own audience while talking to them. The floor rung above is honest about being unstaffed; this one is not.
如果菜单 1 落到单一单向流，则完全跳过此菜单。 没有互动界面就没有什么可主持，不存在高于最低层级的层级，人员配置问题也不会出现。下面的一切都假设有一个界面是开放的。
开放空间的常设成本已经由 
samber/dev-event-organizer-skills@event-comms-channels
论证：搭建是一小时，主持是空间开放整个期间的常设工作，其中的行为准则义务与房间里的完全相同。不要重新推导。此菜单只增加那个 skill 不拥有的_实时、会中_层：谁把问题转达给看不到聊天的演讲者，谁注意到流中断了。
排序（默认值，不是法则——Q1、Q2、Q9、Q10 和 Q11 会重新排序它）：
  • 工作量（每个议程小时在岗人数）：
    主持人、技术观察者和流上的主持 > 主持人加技术观察者 > 每个并发议程一名主持人 > 整个活动一名主持人 > 无主持人员配置
  • 价值，空间被守住（问题到达演讲者，行为在发生之处被执行）：
    主持人、技术观察者和流上的主持 > 每个并发议程一名主持人 == 主持人加技术观察者 > 整个活动一名主持人 > 无主持人员配置
    - 论证的并列：技术观察者不读聊天。这两个层级的审核能力完全相同；第二个人完全是为另一个价值轴而存在。
  • 价值，沉默被打破（失败在发生的那一刻被注意到并告知观众）：
    主持人、技术观察者和流上的主持 > 主持人加技术观察者 > 每个并发议程一名主持人 > 整个活动一名主持人 == 无主持人员配置
    - 论证的并列：一个人无法同时观察多条流的健康状态，所以在超过一个并发议程时，全活动主持人注意到死流不会比没人注意到更快。
  • 合规成本（它触发的审查以及什么变得不可逆）：
    无主持人员配置 > 整个活动一名主持人 > 每个并发议程一名主持人 == 主持人加技术观察者 == 主持人、技术观察者和流上的主持
    - 论证的并列：三者都在每场议程期间于每个开放空间安排了一名具名响应者，这正是义务要求的全部；超过这一点增加的人改变的是谁注意到失败，而不是谁对行为负责。这个轴与这里每个其他菜单的方向相反，而这就是发现：最便宜的层级携带最高的合规成本，因为一个没人看的开放空间是一项没有响应者的义务，其中的伤害无法收回。Major League Hacking 组织者指南明确指出，数字空间是提高而不是降低风险。请将这种反转理解为关于谁负责的论证，绝不要理解为法律解读：义务、平台条款和保留期因国家而异，应交给组织者自己的法律顾问。
  • 效率：
    每个并发议程一名主持人 > 整个活动一名主持人 > 主持人加技术观察者 > 主持人、技术观察者和流上的主持 > 无主持人员配置
支配关系检查：5 个层级，10 对，两个成本轴和两个价值轴，零个严格支配关系。
  • 三个机制解释全部十对。
  • 八对被简单的机制阻断：人员配置严格花费更多人，并严格买到更多的一切，包括履行职责。
  • 一对，什么都不做层级对照全活动主持人，需要单独解释，因为沉默轴在那里并列，“买到更多一切”不再成立。阻断它的是工作量轴对抗空间被守住轴：主持人花费一个人，买到那个仍在变动的价值轴。合规反转在这里不是阻断者，把它称为阻断者是错误的；它朝另一个方向运行，这正是为什么主持人是正确选择，而不是为什么两个层级都不支配。
  • 最后一对，每议程一名主持人对照主持人加观察者，被阻断是因为它们的审核能力确实完全相同，只有失败观察轴区分它们。
  • 零个关系意味着这个检查没有发现错误排序。
  • 每个并发议程一名主持人 - 默认项：每条同时直播的流一个具名的人，读聊天、选择并转达问题、维持行为。它随分会场数量扩展，而不是随参会人数扩展，这就是为什么它完全不需要参会者比例。
  • 整个活动一名主持人 - 对于单分会场的一天是充分且正确的，当 Q2 说一次只运行一场议程时，它与默认项是同一层级。一旦同时发生两件事，它就失败。
  • 主持人加技术观察者 - 每场议程的第二个人，唯一工作是看流是否在线、有声且同步。它背后的模式是实体活动的直播需要“活动期间至少一个人来运行它”（DevOpsDays 组织指南）。不能迁移的是设备：没有调音台要操作，所以这个人从制作路径之外，像观众看到的那样观察输出。晋升条件，各自单独键控：
    • 任何无法重跑的直播内容，键控到 Q11（“哪些议程无法重跑或改期”）。
    • 上一届死流未被注意到的，键控到 Q10（“上一届的失败”）。
  • 主持人、技术观察者和流上的主持 - 最不划算的选项：两个价值轴都最高，工作量也最高，所以效率永远不会选择它。它是唯一一个在演讲失败时有人真正对观众_说_点什么的层级——一条空流配一个满屏“只有我这样吗？”的聊天，是下面两个层级留下的失败模式。晋升条件，各自单独键控：
    • 付费虚拟门票，或点名流的赞助商交付物，两者都键控到 Q4（“付费虚拟门票、点名流的赞助商交付物”）。
    • 一个需要填补空档的连续数小时节目，键控到 Q2（“它们之间最短间隔多长”）。
    • 一个没有其他方式了解正在发生什么的观众，键控到 Q1（“是否存在互动界面，还是这只是一条人们观看的流”）。
  • 删除，不降级：演讲者在演讲的同时主持自己的聊天。 从本菜单和上面的轴线上删除它。它看起来像是免费版的主持，但它不是一个层级：一个正在演讲的演讲者在糟糕地做两份工作，而且没有演讲者能在对观众中某人说话的同时对其执行行为准则。上面的最低层级对自己无人值守是诚实的；这个不是。

Menu 4 - Failure-drill depth

菜单 4 - 故障演练深度

A physical room fails in front of people who can see each other. A virtual event fails as silence, and every attendee's first hypothesis is that the problem is on their end.
Ranking (default, not a law - Q4, Q8, Q10 and Q11 re-rank it):
  • effort (preparation hours, coordination, infrastructure kept warm): 
    a full outage drill on a second platform > a standing fallback destination kept warm > a rehearsed handoff for the single likeliest failure > a written fallback line published before the day > no drill
  • value, the audience is held (people know what happened and stay): 
    a full outage drill on a second platform == a rehearsed handoff for the single likeliest failure > a standing fallback destination kept warm > a written fallback line published before the day > no drill
    - argued tie: both rehearse the words somebody says the moment it breaks, and that is the whole of what holds an audience. The full drill adds infrastructure, not composure.
  • value, the content survives (the session itself resumes rather than being lost): 
    a full outage drill on a second platform > a standing fallback destination kept warm > a rehearsed handoff for the single likeliest failure > a written fallback line published before the day == no drill
    - argued tie: neither resumes anything. A published line tells people where to look; it does not put a talk back on air.
  • efficiency: 
    a written fallback line published before the day > a rehearsed handoff for the single likeliest failure > a standing fallback destination kept warm > a full outage drill on a second platform > no drill
Dominance check: 5 rungs, 10 pairs, one cost axis and two value axes, zero strict-dominance relations.
  • No compliance axis is printed, because nothing here varies on one: every rung's exposure is whatever the platform and consent decisions already fixed.
  • Three mechanisms account for all ten pairs.
  • Eight pairs are blocked by depth costing preparation and buying both value axes at once. Seven of them are strictly better on both; the eighth, the do-nothing rung against the published line, is strictly more audience held while tying on content, which blocks it just as firmly.
  • One pair, the rehearsed handoff against the warm fallback destination, is blocked by the two value axes genuinely crossing: rehearsing words is cheaper and holds the audience better, and only infrastructure resumes the content.
  • The last pair, the rehearsed handoff against the full drill, is blocked because the audience-held axis ties there and only the content-survives axis separates them.
  • Zero relations means the check caught no misordering.
  • A written fallback line published before the day - the default, and near-zero: one sentence, published where the audience will already be looking, naming exactly where to go when the feed dies. It costs a sentence and it removes the worst minute of a virtual outage, the one where nobody knows whether the problem is theirs. Move up one rung the moment a moderator exists at all, because then somebody is there to say it live.
  • A rehearsed handoff for the single likeliest failure - a dry run of one scenario, the speaker's connection dropping mid-talk, with the moderator's exact opening words agreed in advance. It is the highest-value hour on this menu and it buys composure rather than infrastructure.
  • A standing fallback destination kept warm - a second stream target already live and silent, with the published line pointing at it. This is the first rung that puts a session back on air rather than explaining its absence.
  • A full outage drill on a second platform - the starved option: tops the content axis, ties the top of the audience axis, and tops effort, so efficiency never picks it. Promotion conditions, each keyed separately:
    • a paid virtual ticket you could be asked to refund, or a sponsor contract naming the stream, both keyed to Q4 ("a paid virtual ticket, a sponsor deliverable naming the stream")
    • a session that genuinely cannot be rescheduled, keyed to Q11 ("Which sessions cannot be re-run or rescheduled")
    • a previous edition whose feed died, keyed to Q10 ("last edition's failures") and Q8 (a recurring edition, which is what makes last edition's failures predictive)
  • Delete, do not demote: a contingency document nobody has read aloud. Delete it from this menu and from the axis lines above. It reads as a drill and is not one - the moment it is needed, nobody can find it and nobody knows their line. The floor rung above is one published sentence the audience can see, which is a different artifact entirely.
实体房间在彼此能看见的人面前失败。虚拟活动以沉默的方式失败，而每位参会者的第一个假设是问题出在自己这边。
排序（默认值，不是法则——Q4、Q8、Q10 和 Q11 会重新排序它）：
  • 工作量（准备小时数、协调、保持热备的基础设施）：
    在第二个平台上进行全面中断演练 > 一个保持热备的常设回退目的地 > 为最可能发生的单一失败排练交接 > 在活动日前发布的书面回退说明 > 不演练
  • 价值，观众被留住（人们知道发生了什么并留下）：
    在第二个平台上进行全面中断演练 == 为最可能发生的单一失败排练交接 > 一个保持热备的常设回退目的地 > 在活动日前发布的书面回退说明 > 不演练
    - 论证的并列：两者都排练了在故障发生那一刻某人说的话，而这就是留住观众的全部。全面演练增加的是基础设施，而不是镇定。
  • 价值，内容存活（议程本身恢复而不是丢失）：
    在第二个平台上进行全面中断演练 > 一个保持热备的常设回退目的地 > 为最可能发生的单一失败排练交接 > 在活动日前发布的书面回退说明 == 不演练
    - 论证的并列：两者都不会恢复任何东西。已发布的说明告诉人们去哪里看；它不会让演讲重新上播。
  • 效率：
    在活动日前发布的书面回退说明 > 为最可能发生的单一失败排练交接 > 一个保持热备的常设回退目的地 > 在第二个平台上进行全面中断演练 > 不演练
支配关系检查：5 个层级，10 对，一个成本轴和两个价值轴，零个严格支配关系。
  • 没有打印合规轴，因为这里没有任何东西随它变化：每个层级的暴露面就是平台和同意决策已经确定的东西。
  • 三个机制解释全部十对。
  • 八对被深度花费准备成本并同时买到两个价值轴所阻断。其中七对两者都严格更好；第八对，什么都不做层级对照已发布说明，在观众被留住上严格更多而在内容上并列，这同样坚定地阻断它。
  • 一对，排练交接对照热备回退目的地，被两个价值轴真正交叉所阻断：排练话语更便宜_并且_更能留住观众，而只有基础设施能恢复内容。
  • 最后一对，排练交接对照全面演练，被阻断是因为观众被留住轴在那里并列，只有内容存活轴区分它们。
  • 零个关系意味着检查没有发现错误排序。
  • 在活动日前发布的书面回退说明 - 默认项，且接近零成本：一句话，发布在观众本来就会看的地方，明确指出当流中断时该去哪里。它花费一句话，并消除了虚拟中断中最糟糕的一分钟——那一分钟里没人知道问题是否出在自己这边。只要有一个主持人存在，就上升一个层级，因为那时有人在现场说出它。
  • 为最可能发生的单一失败排练交接 - 对一个场景的演练：演讲者的连接在演讲中途断开，主持人的确切开场词事先商定。这是本菜单上价值最高的一小时，它买到的是镇定而不是基础设施。
  • 一个保持热备的常设回退目的地 - 一个已经在线且静默的第二个流目标，已发布的说明指向它。这是第一个把议程重新送上播而不是解释它缺席的层级。
  • 在第二个平台上进行全面中断演练 - 最不划算的选项：内容轴最高，观众轴并列最高，工作量最高，所以效率永远不会选择它。晋升条件，各自单独键控：
    • 可能被要求退款的付费虚拟门票，或点名流的赞助商合同，两者都键控到 Q4（“付费虚拟门票、点名流的赞助商交付物”）。
    • 一场真正无法改期的议程，键控到 Q11（“哪些议程无法重跑或改期”）。
    • 上一届流中断过的，键控到 Q10（“上一届的失败”）和 Q8（周期性活动，这正是让上一届失败具有预测性的原因）。
  • 删除，不降级：一份没有人朗读过的应急文档。 从本菜单和上面的轴线上删除它。它看起来像演练，但并不是——当需要它的时候，没人能找到它，也没人知道自己的台词。上面的最低层级是一句观众能看到的已发布的话，这是完全不同的东西。

Failure modes

失败模式

  • Treating a chat space as free. Setup is an hour; watching it is a standing job for as long as it is open, and the conduct duty inside it is identical to a room's. The published warning is that a digital space raises the harassment risk rather than lowering it.
  • Failing as silence. The feed dies and nothing anywhere says so, so every attendee spends minutes debugging their own connection. Publish the fallback line before the day and say something on it the moment it happens.
  • Rehearsing on a different tool. A check that does not use the platform the event runs on tests nothing about the screen-share path, the audio devices, or what the speaker's browser does under it.
  • Background music in a demo. A named platform risk: incidental music in a stream can get it taken down by the platform itself, mid-session, with no appeal that lands in time. Warn speakers before the day.
  • Publishing past the consent record. A recording that exists is one somebody will ask to publish. 
    samber/dev-event-organizer-skills@event-speaker-experience
    holds the consent record; a locally recorded backup, a breakout where attendees appeared on camera, and a Q&A carrying attendee faces are each outside whatever a talk's consent covered unless it was collected that way.
  • Buying interaction nobody uses. Breakout rooms, booths and directories cost procurement, ops and a data-handling review whether or not anyone opens them. Published remote-turnout evidence points the same way, and it comes from outside technology - treat it as direction, not as a number.
  • Assuming the physical event's numbers. The published cost evidence prices a hybrid run's virtual layer, not a standalone virtual production. Never carry it across as if it sized your event.
  • Assuming attendance falls. Total headcount across a conference's own editions moves either way once it goes virtual: PyCon US counted about 22% fewer people in 2021 (virtual, ~2,650) than in 2019 (in-person, 3,393 checked in), while KubeCon+CloudNativeCon North America's registrations nearly doubled the same way (11,891 in 2019, in-person, to 22,816+ in 2020, virtual). Removing travel cost and geography can grow the number as easily as losing the room shrinks it. Plan capacity from this event's own signals, not from either direction as a default.
  • Scheduling for your own time zone. A programme built where the organizers live puts some speakers and some of the audience in the middle of their night. That is Q3, and it promotes the pre-recorded rung for exactly those slots.
  • 把聊天空间当作免费的。 搭建是一小时；只要它开放，看管它就是一份常设工作，其中的行为义务与房间完全相同。已发布的警告是：数字空间提高而不是降低骚扰风险。
  • 以沉默的方式失败。 流中断了，但任何地方都没有说明，所以每位参会者都花几分钟调试自己的连接。在活动日前发布回退说明，并在故障发生的那一刻在它上面说点什么。
  • 在不同工具上排练。 没有使用活动运行平台的检查，测不出屏幕共享路径、音频设备，或演讲者浏览器在其下的行为。
  • 演示中的背景音乐。 一个指名的平台风险：流中的附带音乐可能导致流在议程中途被平台自己下架，且没有及时生效的申诉。在活动日前警告演讲者。
  • 发布超出同意记录。 存在的一份录制就是某人会请求发布的一份。
    samber/dev-event-organizer-skills@event-speaker-experience
    持有同意记录；本地录制的备份、参会者出现在镜头中的分组讨论，以及带有参会者面孔的问答，除非是以那种方式收集的，否则都在演讲同意所覆盖的范围之外。
  • 购买没人使用的互动。 分组讨论室、展位和目录，无论是否有人打开，都要花费采购、运维和数据处理审查。已发布的远程出席证据指向同一方向，而且它来自技术之外——把它当作方向，而不是一个数字。
  • 套用实体活动的数字。 已发布的成本证据给_混合_运行的虚拟层定价，而不是独立的虚拟制作。绝不要把它搬过来，好像它为你的活动定了规模。
  • 假设参会人数会下降。 一场会议自己各届的总人数一旦转为虚拟，可能向任一方向变动：PyCon US 2021 年（虚拟，约 2,650 人）比 2019 年（现场，3,393 人签到）少了约 22%，而 KubeCon+CloudNativeCon North America 的注册人数以同样的方式几乎翻倍（2019 年现场 11,891 人，到 2020 年虚拟 22,816+ 人）。移除旅行成本和地理限制可以像失去实体房间会缩小人数一样容易地增长人数。根据本次活动自身的信号规划容量，而不要默认任一个方向。
  • 按你自己的时区排程。 在组织者居住地构建的节目会让一些演讲者和一些观众处于半夜。这就是 Q3，它正是为那些时段提升预录层级。

Measurement

衡量

Three completeness gates, checkable before the first session and free of any threshold to argue about:
  • Every concurrent session has a named moderator, or the interaction surface for it is closed. Not a function - a name.
  • Every speaker has joined the platform the event actually runs on, at least once, before the day.
  • The fallback line is published, and the person who will say it out loud knows the sentence.
Everything below is a metric you set rather than an industry standard; say so when you present it.
  • Sessions delivered without an audience-visible failure, over sessions scheduled (self-set). Count a session that ran with no audio as a failure, since that is the failure the drills exist for.
  • Time from a feed dropping to the audience being told something (self-set). This is the number the drill menu actually moves.
  • Questions relayed to a speaker, against questions asked (self-set). It measures whether the moderation staffing was real or nominal.
  • Speakers who joined a check before the day, over speakers scheduled (self-set). The one leading indicator available before anything goes wrong.
Pick two or three, write down what change each would trigger, and record them before the event rather than after.
三个完整性门禁，可在第一场议程之前检查，并且没有任何需要争论的阈值：
  • 每个并发议程都有一名具名主持人，或者其互动界面已关闭。不是一个职能——一个名字。
  • 每位演讲者都在活动日前至少一次加入过活动实际运行的平台。
  • 回退说明已发布，并且将要大声说出它的人知道那句话。
下面的一切都是你设定的指标，而不是行业标准；呈现时请说明这一点。
  • 无观众可见失败交付的议程，除以已排程的议程（自设）。将没有音频运行的议程计为失败，因为那正是演练存在的目的要应对的失败。
  • 从流中断到观众被告知某事的时间（自设）。这是演练菜单真正会改变的数字。
  • 转达给演讲者的问题，对比被提出的问题（自设）。它衡量主持人员配置是真实的还是名义上的。
  • 在活动日前加入检查的演讲者，除以已排程的演讲者（自设）。这是在出任何问题之前可用的唯一个领先指标。
选择两三个，写下每个会触发什么变更，并在活动前而不是活动后记录它们。

Invocation examples

调用示例

  • "We're running our conference fully online this year. What platform do we actually need?"
  • "How do I get remote speakers ready so a dropped connection doesn't kill a talk?"
  • "How many moderators do we need for three parallel virtual tracks?"
  • "What's our plan if the stream dies during the keynote?"
  • "Our speakers are spread across too many time zones. What do we do about the ones whose slot lands in the middle of their night?"
Expected output: a delivery plan with:
  1. the interaction posture in one line
  2. the platform posture chosen with its vendor questions still open in writing
  3. the speaker-readiness rung with the note or check schedule
  4. moderation staffing assigned by name per concurrent session
  5. the failure drill and the published fallback line
  6. the rehearsal date on the real platform
  7. the cost consequence split for the budget
Presented section by section for validation before anything is signed.
  • “我们今年要完全在线办会议。我们到底需要什么平台？”
  • “我如何让远程演讲者做好准备，使断连不会毁掉一场演讲？”
  • “三个并行虚拟分会场我们需要多少主持人？”
  • “如果主题演讲期间流中断了，我们的计划是什么？”
  • “我们的演讲者分布在太多时区。对于那些时段落在半夜的人，我们怎么办？”
预期输出：一份交付计划，包含：
  1. 用一句话说明互动姿态
  2. 所选平台姿态，其供应商问题仍以书面形式待定
  3. 演讲者就绪层级及说明或检查排程
  4. 按名字为每个并发议程分配的主持人员
  5. 故障演练和已发布的回退说明
  6. 在真实平台上的排练日期
  7. 给预算的成本后果拆分
在签署任何内容之前，逐节呈现以供验证。

References

参考

See also, same collection:
  • samber/dev-event-organizer-skills@hybrid-event-design
    - owns the event serving a room and a remote audience at once. The dividing line is the stage: a hybrid always has one, so every menu here stops applying to it.
另见，同一集合：
  • samber/dev-event-organizer-skills@hybrid-event-design
    - 拥有同时服务实体房间和远程观众的活动。分界线是舞台：混合活动总是有舞台，所以这里的每个菜单都不再适用于它。