hybrid-event-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Hybrid Event Design

混合式活动设计

You design the programme and the staffing for an event with two audiences at once: one in the room, one watching from elsewhere. The format decision arrives made. Never reopen it.
你为一场同时面向两组观众的活动设计方案和人员配置:一组在房间里,另一组在别处观看。格式决策已经做出。不要重新讨论它。

This skill is deliberately narrow, and the reason matters

这个 skill 刻意保持狭窄,原因很重要

Siblings already own most of what a hybrid event needs. The scope left over is small. Say so rather than expanding into their territory:
  • samber/dev-event-organizer-skills@event-format-selection
    decides whether hybrid happens at all and owns the entire cost case against it. Its verdict: "It is the maximum-cost, maximum-risk option, not the middle". Consume that verdict. Never re-derive the cost argument, never re-quote its figures. If the user is still deciding, route them there and stop.
  • samber/dev-event-organizer-skills@event-production
    owns the room's signal path, capture tier, crew and redundancy, and states its own limit as "Reports hybrid's cost consequence; never decides the format." Every camera, cable and encoder is its work. You name the sessions that need a feed. It builds the feed.
  • samber/dev-event-organizer-skills@virtual-event-production
    owns the event with no room. It starts "once the format decision has already chosen virtual", and scopes itself to the case where "You own the case with no stage to point at." A hybrid always has a stage, so its platform, remote-speaker and drill menus are not yours to repeat.
  • samber/dev-event-organizer-skills@event-run-of-show
    owns the day-of document, the roles and the escalation paths. You add one column to its artifact. Never write a second one.
  • samber/dev-event-organizer-skills@event-schedule-design
    owns the grid. You mark sessions on it. Never move them.
Four things are genuinely left, covered by three menus and one section:
  • Which sessions the remote audience gets.
  • How far a remote attendee's voice reaches the stage.
  • What cue track the stream needs beside the room's.
  • Who staffs the remote side.
That is the whole skill. Its shortness is the correct outcome, not a gap.
Every ranking below is a default, not a law. After the interview, re-rank all three menus against what you already know:
  • A room already wired for capture.
  • A community that has streamed before.
  • A remote audience that has already paid.
  • A previous edition where remote questions went unanswered.
Each of these overturns a default rung.
同系列的兄弟 skill 已经涵盖了混合式活动所需的大部分内容。剩余的范围很小。请明确说明这一点,而不是扩展到它们的领域:
  • samber/dev-event-organizer-skills@event-format-selection
    决定是否采用混合式,并负责针对它的全部成本论证。它的结论是:"这是成本最高、风险最高的选项,而不是中间选项"。接受这个结论。不要重新推导成本论证,不要重新引用它的数据。如果用户仍在决策中,引导他们去那里并停止。
  • samber/dev-event-organizer-skills@event-production
    负责房间的信号链路、采集层、人员和冗余,并声明自己的限制为"报告混合式的成本后果;绝不决定格式"。每一台摄像机、每一条线缆和每一个编码器都是它的工作。你指定需要直播的环节。它构建直播流。
  • samber/dev-event-organizer-skills@virtual-event-production
    负责没有现场的活动。它从"一旦格式决策已经选择了虚拟"开始,并将自己限定在"你负责没有舞台可指向的情况"。混合式活动总有舞台,所以它的平台、远程演讲者和演练菜单不是你要重复的。
  • samber/dev-event-organizer-skills@event-run-of-show
    负责当日文档、角色和升级路径。你向它的产物添加一列。绝不写第二份文档。
  • samber/dev-event-organizer-skills@event-schedule-design
    负责时间表。你在上面标记环节。绝不移动它们。
真正剩下来的是四件事,由三个菜单和一个章节覆盖:
  • 远程观众能看到哪些环节。
  • 远程参与者的声音能多大程度传上舞台。
  • 除了现场所需的提示轨之外,流媒体还需要什么提示轨。
  • 谁来为远程侧配备人员。
这就是整个 skill。它的简短是正确的结果,而不是缺口。
下面的每个排序都是默认值,不是法则。在访谈之后,根据你已经知道的信息重新排序所有三个菜单:
  • 一个已经为采集布好线的房间。
  • 一个以前直播过的社区。
  • 一个已经付费的远程观众。
  • 上一届中远程问题无人回答的情况。
每一条都可能推翻一个默认层级。

Why parity matters, and why it fails

为什么对等很重要,以及为什么它会失败

Remote audiences at hybrid events report feeling like second-class attendees when they watch but cannot participate. The failure is not equipment; it is attention.
Two documented cases:
  • A workshop running late in the room while remote participants are not told.
  • Remote check-in lagging because the team is busy in person.
In both, the staff were looking at the room and the remote audience got what was left. A scaled-back hybrid conference confirms the pattern: online participants reported it less engaging than anticipated, and the event closed at a loss.
Every value ordering below is reasoned, not measured. No menu choice here carries a figure tying it to remote attendance, engagement or satisfaction.
Never invent any of these to justify a rung:
  • A parity threshold.
  • A remote-to-in-room staffing ratio.
  • A share of Q&A owed to remote.
  • A tolerable stream delay.
混合式活动中的远程观众报告说,当他们只能观看而无法参与时,感觉像二等参与者。失败不在于设备,而在于关注。
两个有记录的案例:
  • 房间里的工作坊进行到很晚,而远程参与者没有被告知。
  • 远程签到滞后,因为团队忙于现场。
在这两种情况下,工作人员都在看房间,远程观众得到的是剩下的。一个缩减规模的混合会议证实了这种模式:在线参与者报告说它比预期的吸引力低,活动最终亏损结束。
下面的每个价值排序都是经过推理的,而不是测量出来的。这里的菜单选项没有任何数字将其与远程参与度、参与感或满意度挂钩。
绝不要为了证明一个层级而编造以下任何内容:
  • 对等阈值。
  • 远程与现场人员比例。
  • 应归给远程的问答份额。
  • 可容忍的流延迟。

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 - those orderings cannot be picked for the user.
  1. What was the remote audience actually promised, and to whom? A paid virtual ticket, a sponsor deliverable naming the stream, an access commitment to people who cannot travel, or nothing written down. It reorders every menu below, and the rest of the day gets argued against it.
  2. How many rooms run at once, and how many of them can physically carry a feed? A room the production sibling cannot instrument deletes rungs rather than reordering them.
  3. Where is the remote audience relative to the room: the same working day, or a spread wide enough that part of your programme lands in the middle of their night?
  4. What is the recording and publication consent posture per session, and who holds that record? Does the in-room audience appear on the outgoing feed during Q&A?
  5. Does anything constrain which platform may carry the feed, or where attendee data may sit: an employer's procurement, a sponsor's contract, an umbrella organization's rules?
  6. Has the schedule document arrived with a disruption priority order, and does it say anything about the remote side? Silence there is a gap you close in advance (see § The cue track the stream needs).
  7. What is the last date a session can still join or leave the remote programme? These menus are ranked against that deadline, not against the event date.
  8. One-off edition or a recurring event? A recurring event promotes every rung whose payoff lands after this edition: a briefed advocate, a cue template carrying both audiences, a consent form that already asks the right question.
  9. What is the effort ceiling: how many people can work the remote side alone during a session, rather than also covering something in the room?
  10. What already exists that should re-rank these defaults: a room already wired, an organizer who has streamed before, last edition's remote complaints, a community that already lives in a chat space?
一次问一个问题,尽可能用选择题。问题7-9之所以存在,是因为菜单在生效时间、持久性和工作量上分歧很大——这些排序不能替用户选择。
  1. 远程观众实际上被承诺了什么,对谁承诺的? 付费虚拟门票、点名直播流的赞助商交付物、对无法出行的人的访问承诺,还是什么都没有写下来。它会重新排序下面的每个菜单,而当天其余部分都会围绕它争论。
  2. 同时运行多少个房间,其中有多少个在物理上能够承载直播流?制作兄弟 skill 无法配置仪器的房间会删除层级,而不是重新排序它们。
  3. 远程观众相对于房间在哪里:同一个工作日,还是分布足够广,以至于你的部分节目落在他们的半夜?
  4. 每个环节的录制和发布同意立场是什么,谁持有该记录?问答期间,现场观众会出现在对外直播流中吗?
  5. 是否有任何因素限制承载直播流的平台,或限制与会者数据的存放位置:雇主的采购政策、赞助商的合同、上级组织的规则?
  6. 日程文档是否已经带有中断优先级顺序,它是否提到了远程侧?那里的沉默是一个你要提前弥补的空白(参见 § 流媒体需要的提示轨)。
  7. 一个环节可以加入或退出远程节目的最后日期是什么?这些菜单是针对那个截止日期排序的,而不是针对活动日期。
  8. 一次性活动还是经常性活动?经常性活动会提升每个回报落在这届活动之后的层级:一个有准备的倡导者、一个同时承载两组观众的提示模板、一个已经提出正确问题的同意表单。
  9. 工作量上限是什么:在一个环节期间,有多少人可以单独负责远程侧,而不是同时还要覆盖房间里的某件事?
  10. 已经存在什么应该重新排序这些默认值:一个已经布好线的房间、一个以前直播过的组织者、上一届的远程投诉、一个已经生活在某个聊天空间的社区?

What actually splits this work

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

Community-run and vendor-run events diverge at one question, not across the menus. A remote attendee waits the same seconds for an answer whoever funded the room.
That question is Q1. A vendor-run event more often arrives with the remote audience already sold something:
  • A virtual ticket.
  • A customer commitment.
  • A sponsor line naming the stream.
Being sold something promotes rungs rather than reordering them, because a promise is not a preference.
Two things reshape every menu instead:
  • Whether the remote audience has a return path at all.
  • After that, how many rooms carry a feed.
A single streamed room with a one-way feed is a broadcast attached to a conference, and it needs almost nothing new. Two streamed rooms with live Q&A is a staffing problem before it is a technical one. Say which case a recommendation assumes whenever the two differ.
社区运营和供应商运营的活动在一个问题上分叉,而不是在菜单上。无论谁资助了房间,远程参与者等待答案的秒数是一样的。
那个问题是问题1。供应商运营的活动更经常地带着已经向远程观众出售了某种东西的状态到来:
  • 虚拟门票。
  • 客户承诺。
  • 点名直播流的赞助商条目。
被出售了某种东西会提升层级,而不是重新排序它们,因为承诺不是偏好。
有两件事会重塑每个菜单:
  • 远程观众是否有一条返回路径。
  • 在那之后,有多少房间承载直播流。
一个单一直播房间的单向流是附属于会议的一次广播,它几乎不需要什么新的东西。两个直播房间加上实时问答,在技术问题之前首先是一个人员配置问题。当两者不同时,说明建议假设的是哪种情况。

Workflow

工作流程

  1. Confirm the format decision is closed. If hybrid is still being weighed, route to
    samber/dev-event-organizer-skills@event-format-selection
    and stop. Re-arguing it here wastes the only pass you get.
  2. Write down what the remote audience was promised, in one sentence, from Q1. Every later choice is measured against that sentence, not against what is technically possible.
  3. Mark remote eligibility on the published grid (Menu 1) as a column, not as a separate list. A separate list is a second document, and second documents drift.
  4. Choose the parity depth (Menu 2). For what each rung looks like minute to minute, read references/remote-eligibility-and-parity-mechanics.md.
  5. Hand the eligible-session list to
    samber/dev-event-organizer-skills@event-production
    as an input to its own coverage-tier decision, per room. You name the sessions and the return path. It names the equipment. Never specify equipment yourself.
  6. Check the consent record covers what the feed will carry (Q4).
    samber/dev-event-organizer-skills@event-speaker-experience
    holds that record, and
    samber/dev-event-organizer-skills@event-production
    states the constraint a live feed adds: "a speaker's opt-out has to be honoured in the room rather than in an edit". Settle this before the grid is marked, not after.
  7. Staff the remote side (Menu 3), by name per streamed session rather than by function.
  8. Add the stream's cue track to the run of show (see below) and hand it to
    samber/dev-event-organizer-skills@event-run-of-show
    as an addition to its document.
  9. Close the two-audience gap in the disruption priority order (Q6) before the day, in writing, and say who decided it.
  10. Report the staffing consequence to
    samber/dev-event-organizer-skills@event-budget
    , split by what a lean tier can drop. The feed itself survives every tier; the return path and the people watching it are what a lean tier cuts first.
Present the plan section by section for validation, in this order:
  1. The promise.
  2. Eligibility.
  3. Parity.
  4. Staffing.
  5. The cue track.
Do this before the grid is published. After publication, removing a session from the remote programme is a public retraction rather than a decision.
If your harness has persistent memory, record per edition:
  • What the remote audience was promised, and in whose words.
  • Which sessions were marked eligible, and which speakers declined.
  • How many remote questions actually reached a stage.
  • Every moment the remote side was left unattended, and what the room was doing instead.
  • What the disruption order turned out to say about remote.
A second edition should start from that record rather than from these defaults.
  1. 确认格式决策已经关闭。 如果混合式仍在权衡中,路由到
    samber/dev-event-organizer-skills@event-format-selection
    并停止。在这里重新论证只会浪费你唯一的机会。
  2. 写下远程观众被承诺了什么,用一句话,来自问题1。之后的每个选择都针对那句话来衡量,而不是针对技术上可能的东西。
  3. 在已发布的日程表上标记远程资格(菜单1)作为一列,而不是一个单独的列表。单独的列表是第二份文档,而第二份文档会漂移。
  4. 选择对等深度(菜单2)。关于每个层级每分钟是什么样子,阅读 references/remote-eligibility-and-parity-mechanics.md。
  5. 将符合条件的环节列表交给
    samber/dev-event-organizer-skills@event-production
    作为其自身覆盖层级决策的输入,按房间进行。你指定环节和返回路径。它指定设备。绝不要自己指定设备。
  6. 检查同意记录是否覆盖流将承载的内容(问题4)。
    samber/dev-event-organizer-skills@event-speaker-experience
    持有该记录,
    samber/dev-event-organizer-skills@event-production
    陈述了直播流增加的限制:"演讲者的退出选择必须在房间里被尊重,而不是在剪辑中"。在标记日程表之前解决这个问题,而不是之后。
  7. 为远程侧配备人员(菜单3),按每个直播环节的名字,而不是按职能。
  8. 将流的提示轨添加到运行表中(见下文),并将其交给
    samber/dev-event-organizer-skills@event-run-of-show
    作为其文档的补充。
  9. 在活动之前以书面形式弥合中断优先级顺序中的两组观众差距(问题6),并说明谁决定的。
  10. 向
    samber/dev-event-organizer-skills@event-budget
    报告人员配置后果
    ,按精简层级可以砍掉什么来拆分。直播流本身在每个层级都能存活;返回路径和看着它的人才是精简层级最先削减的。
按以下顺序逐节展示计划以供验证:
  1. 承诺。
  2. 资格。
  3. 对等。
  4. 人员配置。
  5. 提示轨。
在日程表发布之前完成这些。发布之后,从远程节目中移除一个环节是公开撤回,而不是决定。
如果你的 harness 有持久记忆,请按届记录:
  • 远程观众被承诺了什么,用谁的话。
  • 哪些环节被标记为合格,哪些演讲者拒绝了。
  • 有多少远程问题真正到达了舞台。
  • 远程侧被无人看管的每个时刻,以及房间当时在做什么。
  • 中断顺序最终对远程说了什么。
第二届应该从那个记录开始,而不是从这些默认值开始。

Menu 1 - Session remote eligibility

菜单1 - 环节远程资格

Which sessions the remote audience gets. Mark this on the grid
samber/dev-event-organizer-skills@event-schedule-design
published - that skill's own limit is "You stop at the published grid", so the column is yours to add and the placement is never yours to change.
Ranking (default, not a law - Q1, Q2, Q7 and Q10 re-rank it):
  • effort (rooms instrumented, crew committed, consent chased, editorial passes over the grid):
    every session in every room > per-session speaker opt-in > curated remote programme > one designated streamed room > plenary only
    . Opt-in outranks curation on cost, for two reasons worth stating:
    • An opt-in can land in any room, so you instrument every room, which is the top rung's bill.
    • Constrain where speakers may opt in and it stops being an opt-in. A curated set is bounded because you chose it, and you can choose it to sit in rooms already carrying a feed.
  • value, breadth (how much of the programme a remote attendee can actually watch):
    every session in every room > per-session speaker opt-in == curated remote programme > one designated streamed room > plenary only
    - argued tie: neither delivers a predictable share of the programme. How many speakers say yes sets opt-in's breadth; the organizer's own editorial ceiling sets curation's. Which ends up wider is not knowable before the fact.
  • value, coherence (a remote attendee gets a day that holds together rather than a scatter of fragments):
    curated remote programme > one designated streamed room > plenary only > every session in every room > per-session speaker opt-in
    . This axis is why the menu is not a ladder:
    • A curated programme is designed as a remote day. A single streamed room is at least a continuous thread. Plenary-only is short but complete.
    • Streaming everything hands a remote attendee a multi-track grid they can watch only one stream of, with none of the corridor cues that make a room's choice easy.
    • Opt-in ranks worst: it produces holes at times nobody can predict.
  • compliance cost (the review it triggers and what stops being reversible):
    every session in every room > curated remote programme == per-session speaker opt-in > one designated streamed room > plenary only
    - argued tie: both put a mid-sized, organizer-known subset of the programme out. The curated set arrives needing each chosen speaker's consent chased. The opt-in set arrives with the speaker's consent already given and needs the in-room audience's covered instead: the questioners whose voices and faces go out live. Same review, different half of it. What makes this axis real rather than decorative is the sibling constraint quoted above, an opt-out honoured in the room rather than in an edit, and "A published stream cannot be recalled from the people already watching it."
  • efficiency:
    plenary only > one designated streamed room > curated remote programme > per-session speaker opt-in > every session in every room
Dominance check: 5 rungs, 10 pairs, two cost axes and two value axes, and one real strict-dominance relation.
The curated remote programme strictly dominates per-session speaker opt-in: cheaper on effort, tied on compliance, tied on breadth, strictly better on coherence.
The remaining nine pairs split into two blocks:
  • Blocked by breadth alone, where the cheaper rung also wins coherence and loses only on how much a remote attendee can watch (five pairs): plenary-only against opt-in, plenary-only against every-session, one-room against opt-in, one-room against every-session, and curated against every-session.
  • Blocked by cost running opposite to both value axes (four pairs): plenary-only against one-room, plenary-only against curated, one-room against curated, and opt-in against every-session.
That accounts for all ten (1 relation + 5 + 4).
  • One designated streamed room - the default: one room is the remote room, and whatever the grid puts in it is what remote gets. It buys a continuous day for the cost of instrumenting one room, needs no per-session negotiation, and collapses the eligibility question into a room-booking question the schedule already answered. Move up to the curated programme whenever Q1 says the remote audience paid or was promised specific content. A room chosen for its cabling is not a programme anyone was promised.
  • Plenary only - the minimum, and it wins outright more often than it looks. The opening, the keynotes and the closing carry the widest audience, usually sit in the room already best equipped, and make sense to someone who is not in the building. It is the honest choice when Q1's answer is "nothing written down".
  • Curated remote programme - organizers choose the sessions that serve a remote audience specifically, and mark them. Tops coherence, mid on everything else. It treats the remote audience as an audience rather than as an overflow.
  • Per-session speaker opt-in - strictly dominated above, and kept on the menu for one reason: a consent posture can hand it to you already decided. Where
    samber/dev-event-organizer-skills@event-speaker-experience
    's consent record is per-speaker and opt-out is genuinely offered, the eligible set is whoever said yes. Make the resulting holes legible rather than pretending they are a programme.
  • Every session in every room - the starved option: tops breadth, tops both cost axes, bottoms coherence, so efficiency never picks it. Promotion conditions:
    • Keyed to Q1: a paid virtual ticket sold as access to the whole programme.
    • Keyed to Q2: a venue where every room is already instrumented, so breadth costs nothing extra to reach.
  • Delete, do not demote: publishing the recordings afterwards and calling that the remote programme. Strike it from this menu and from the axis lines above. It reads as the cheapest hybrid and it is not a hybrid at all. A remote audience that watches next week is the in-person-with-record-and-post delivery mode, which
    samber/dev-event-organizer-skills@event-format-selection
    names separately and which this event has already decided against. Leaving it parked at the bottom is how a hybrid quietly becomes a recorded event with a broken promise attached. Post-event publication is real work, and it belongs to
    samber/dev-event-organizer-skills@event-content-repurposing
    .
远程观众能得到哪些环节。在
samber/dev-event-organizer-skills@event-schedule-design
发布的日程表上标记这个——那个 skill 自身的限制是"你止步于已发布的日程表",所以这一列是你的添加,而位置永远不是你能改变的。
排序(默认,不是法则——问题1、问题2、问题7和问题10会重新排序它):
  • 工作量(房间的仪器配置、投入的人员、追索的同意、对日程表的编辑审查):
    每个房间的每个环节 > 每环节演讲者选择加入 > 策划的远程节目 > 一个指定的直播房间 > 仅全体会议
    。选择加入在成本上优于策划,有两个值得说明的原因:
    • 选择加入可以落在任何房间,所以你要为每个房间配置仪器,这是最高层级的账单。
    • 限制演讲者可以选择加入的地点,它就不再是选择加入了。策划的集合是有边界的,因为是你选择的,你可以选择它落在已经承载直播流的房间里。
  • 价值,广度(远程参与者实际能观看多少节目):
    每个房间的每个环节 > 每环节演讲者选择加入 == 策划的远程节目 > 一个指定的直播房间 > 仅全体会议
    - 有争议的平局:两者都不能提供可预测的节目份额。有多少演讲者说“是”决定了选择加入的广度;组织者自己的编辑上限决定了策划的广度。哪个最终更广在事前是无法知道的。
  • 价值,连贯性(远程参与者得到一个能够自洽的一天,而不是零散的碎片):
    策划的远程节目 > 一个指定的直播房间 > 仅全体会议 > 每个房间的每个环节 > 每环节演讲者选择加入
    。这个轴是为什么这个菜单不是梯子的原因:
    • 策划的节目是被设计成一个远程日的。单一直播房间至少是一条连续的线。仅全体会议很短但完整。
    • 直播一切会把一个多轨日程表交给远程参与者,而他们只能看其中一条流,没有任何走廊提示来帮助选择房间。
    • 选择加入排名最差:它在没人能预测的时间产生空洞。
  • 合规成本(它触发的审查以及什么变得不可逆):
    每个房间的每个环节 > 策划的远程节目 == 每环节演讲者选择加入 > 一个指定的直播房间 > 仅全体会议
    - 有争议的平局:两者都将一个中等规模、组织者已知的节目子集放出去。策划的集合到来时需要追索每个被选中演讲者的同意。选择加入的集合到来时演讲者的同意已经给出,而需要覆盖的是现场观众:那些声音和面孔实时外传的提问者。同样的审查,不同的另一半。这个轴是真实而非装饰性的原因,是上面引用的兄弟限制,一个在房间里而不是在剪辑中被尊重的退出选择,以及"已发布的流无法从已经在观看的人那里召回。"
  • 效率:
    仅全体会议 > 一个指定的直播房间 > 策划的远程节目 > 每环节演讲者选择加入 > 每个房间的每个环节
支配性检查:5个层级,10对,两个成本轴和两个价值轴,以及一个真正的严格支配关系。
策划的远程节目严格支配每环节演讲者选择加入:在努力上更便宜,在合规上平局,在广度上平局,在连贯性上严格更好。
其余九对分成两块:
  • 仅因广度受阻,其中更便宜的层级也赢得连贯性,只在远程参与者能看多少上输(五对):仅全体会议对选择加入,仅全体会议对每个环节,单房间对选择加入,单房间对每个环节,以及策划对每个环节。
  • 因成本与两个价值轴都相反受阻(四对):仅全体会议对单房间,仅全体会议对策划,单房间对策划,以及选择加入对每个环节。
这说明了全部十对(1个关系 + 5 + 4)。
  • 一个指定的直播房间 - 默认:一个房间是远程房间,日程表放在里面的东西就是远程得到的。它用配置一个房间的成本换来了连续的一天,不需要逐环节谈判,并把资格问题折叠成一个日程表已经回答的房间预订问题。每当问题1说远程观众付费或被承诺了特定内容时,升级到策划的节目。 一个因为布线而选中的房间,不是任何人被承诺的节目。
  • 仅全体会议 - 最低限度,它直接获胜的频率比看起来更高。开场、主题演讲和闭幕拥有最广泛的观众,通常坐在已经装备最好的房间里,并且对不在楼里的人也有意义。当问题1的回答是"什么都没写下来"时,这是诚实的选择。
  • 策划的远程节目 - 组织者选择专门服务于远程观众的环节,并标记它们。连贯性最高,其他方面居中。它把远程观众当作一个观众群,而不是溢出。
  • 每环节演讲者选择加入 - 上面被严格支配,保留在菜单上一个原因:同意立场可能已经把它决定好了交给你。在
    samber/dev-event-organizer-skills@event-speaker-experience
    的同意记录是每演讲者并且退出选择被真正提供的情况下,合格集合就是那些说“是”的人。让产生的空洞清晰可见,而不是假装它们是一个节目。
  • 每个房间的每个环节 - 饥饿选项:广度最高,两个成本轴最高,连贯性最低,所以效率永远不会选它。提升条件:
    • 与问题1相关:付费虚拟门票作为对整个节目的访问权限出售。
    • 与问题2相关:一个每个房间都已经配置好仪器的场地,所以广度不需要额外成本就能达到。
  • 删除,不要降级:事后发布录制内容并称之为远程节目。 把它从这个菜单和上面的轴线中划掉。它看起来像最便宜的混合式,但它根本不是混合式。下周才观看的远程观众属于"带录播和邮件的现场"交付模式,
    samber/dev-event-organizer-skills@event-format-selection
    单独命名了它,而这个活动已经决定放弃它。把它停在底部,就是混合式悄悄变成一个有食言承诺的录制活动的方式。事后发布是真正的工作,它属于
    samber/dev-event-organizer-skills@event-content-repurposing
    。

Menu 2 - Parity depth

菜单2 - 对等深度

How far a remote attendee's voice reaches the stage. This is the menu the second-class finding is about, and the one where doing very little is a legitimate answer.
Ranking (default, not a law - Q1, Q3, Q9 and Q10 re-rank it):
  • effort (equipment in the room, a person's attention during the session, briefing, rehearsal, a return path into the room's audio):
    remote participants appear in the room > reserved floor time for remote questions > live relay by a named person > an asynchronous written return path > feed only
  • value, the remote voice reaches the stage (a remote attendee's question is actually answered by the speaker, live):
    remote participants appear in the room > reserved floor time for remote questions > live relay by a named person > an asynchronous written return path > feed only
  • value, the room's own session is undamaged (the speaker and the in-room audience get a session that is not slowed, interrupted or reshaped by the remote layer):
    feed only > an asynchronous written return path > live relay by a named person > reserved floor time for remote questions > remote participants appear in the room
    . This axis is rank-identical to inverse effort, which is the pathology the ranking discipline warns about. On its own it would collapse this menu into cheapest-first. It stays because it discriminates nothing about the ordering and everything about the incidence: it names who pays for each rung, and that payer is the in-room audience rather than the organizer. Read it as a statement of who bears the cost, never as an independent reason to pick a rung.
  • compliance cost (the review it triggers and what stops being reversible):
    remote participants appear in the room > reserved floor time == live relay by a named person == an asynchronous written return path > feed only
    - argued tie for the middle three: each collects text a remote attendee typed into a channel the event already opened. That is the same record under the same terms whether it is read aloud, read on a rule, or answered next week, and none of the three puts a new person's likeness anywhere. Feed-only is lowest because no return channel means no remote-side record to hold. The top rung differs in kind: it puts an identifiable person into the room's own captured output, so it needs that person's consent and it lands inside the in-room recording's envelope, where "A camera in the room is not agreement" and a published stream cannot be recalled.
  • efficiency:
    feed only > live relay by a named person > an asynchronous written return path > reserved floor time for remote questions > remote participants appear in the room
Dominance check: 5 rungs, 10 pairs, two cost axes and two value axes, zero strict-dominance relations.
One mechanism accounts for all ten, and it is the only one operating. The reaching-the-stage axis runs strictly opposite to effort and strictly opposite to the room's own session. On every pair the cheaper rung wins the room and loses the stage, so no rung is at least equal on everything.
Compliance runs the same way but does not carry the block on its own: the three middle rungs tie on it by the argued tie above, so on three of the ten pairs compliance separates nothing.
The check catches no misordering. What follows is argument, not verification, and this menu is clean only by construction.
  • Live relay by a named person - the default: remote questions arrive in a channel, and one named person in the room reads them aloud during Q&A. It is the cheapest rung on which a remote attendee's question is answered by the speaker, out loud, while they are watching. Sitting one rung above the efficiency leader is deliberate. An event that passed the format decision's gate did so because a remote audience mattered enough to pay for. Buying the most expensive delivery mode while delivering the cheapest parity is the failure this whole skill exists to name.
  • Feed only - the minimum, and genuinely often the right answer. Remote watches and that is all. Drop to it whenever Menu 3 cannot name a person for a session. An open question channel nobody reads during the session is worse than no channel: it invites a question in the moment and drops it in the moment, in front of the person who asked. That is the second-class experience in its purest form.
  • An asynchronous written return path - questions collected with a stated promise: answered in writing, by whom, by when. It costs no attention during the session, and it is honest, which is what separates it from the deleted rung below. It buys a real answer and never a live one.
  • Reserved floor time for remote questions - the moderator holds part of Q&A for remote by rule rather than by goodwill. The rule is the point: goodwill loses to a room full of raised hands every time, because the in-room audience has a default channel and the remote one does not. It costs the moderator a brief, and the discipline to hold the rule under time pressure.
  • Remote participants appear in the room - the starved option: tops the voice axis, tops effort, tops compliance, so efficiency never picks it. It is the only rung where the speaker answers a person rather than reading a line. The return audio path itself is
    samber/dev-event-organizer-skills@event-production
    's to build: specify the requirement, never the equipment. Promotion conditions:
    • Keyed to Q1: a paid virtual ticket sold on participation rather than viewing.
    • Keyed to Q1: a sponsor deliverable that names remote interaction.
    • Keyed to Q3: a remote audience concentrated enough that the people awake are the people who matter.
  • Delete, do not demote: an open remote question channel with nobody reading it. Strike it from this menu and from the axis lines above. It reads as parity's free version, and it is the one rung worse than the floor: it makes a promise inside the session and breaks it inside the same session. It also carries a conduct duty with no responder, which
    samber/dev-event-organizer-skills@event-comms-channels
    already argues as a standing cost rather than a setup cost. The asynchronous rung above is a different artifact: it states what will happen, and someone is answerable for it.
远程参与者的声音能多大程度传上舞台。这是关于二等参与者发现的菜单,也是做得很少是合理答案的那个。
排序(默认,不是法则——问题1、问题3、问题9和问题10会重新排序它):
  • 工作量(房间里的设备、环节期间一个人的注意力、简报、演练、进入房间音频的返回路径):
    远程参与者出现在房间里 > 为远程问题保留的提问时间 > 由指定的人实时转述 > 异步书面返回路径 > 仅直播流
  • 价值,远程声音到达舞台(远程参与者的提问实际上被演讲者实时回答):
    远程参与者出现在房间里 > 为远程问题保留的提问时间 > 由指定的人实时转述 > 异步书面返回路径 > 仅直播流
  • 价值,房间自身的环节不受损害(演讲者和现场观众得到一个不被远程层拖慢、打断或重塑的环节):
    仅直播流 > 异步书面返回路径 > 由指定的人实时转述 > 为远程问题保留的提问时间 > 远程参与者出现在房间里
    。这个轴与逆向工作量完全相同,这是排序纪律警告的病理。 单独看它会把这个菜单折叠成最便宜优先。它保留下来是因为它对排序没有任何区分力,而对_发生率_则区分一切:它指定每个层级谁买单,而这个买单者是现场观众,而不是组织者。把它读作谁承担成本的陈述,而不是选择层级的独立理由。
  • 合规成本(它触发的审查以及什么变得不可逆):
    远程参与者出现在房间里 > 为远程问题保留的提问时间 == 由指定的人实时转述 == 异步书面返回路径 > 仅直播流
    - 中间三个有争议的平局:每个都收集远程参与者输入到活动已经打开的频道中的文本。无论它是被大声朗读、按规则阅读,还是下周回答,都是相同条款下的相同记录,而且三个中的任何一个都不会在任何地方出现新人的肖像。仅直播流最低,因为没有返回通道意味着没有远程侧记录需要持有。最高层级在种类上不同:它把一个可识别的人放入房间自身采集的输出中,所以它需要那个人的同意_并且_它落在现场录制的外包封内,在那里"房间里的摄像机不是同意",而已发布的流无法被召回。
  • 效率:
    仅直播流 > 由指定的人实时转述 > 异步书面返回路径 > 为远程问题保留的提问时间 > 远程参与者出现在房间里
支配性检查:5个层级,10对,两个成本轴和两个价值轴,零严格支配关系。
一个机制解释了全部十对,而且它是唯一在运作的。到达舞台的轴与工作量严格相反,与房间自身环节也严格相反。在每一对上,更便宜的层级赢得房间,输掉舞台,所以没有层级在一切上至少相等。
合规性以同样的方式运作,但单独不构成阻碍:中间三个层级在上面论证的平局下打平,所以在十对中的三对上合规性不区分任何东西。
检查没有抓住任何排序错误。接下来的是论证,不是验证,而这个菜单只是通过构造才干净的。
  • 由指定的人实时转述 - 默认:远程问题到达一个频道,房间里一个指定的人在问答期间大声读出它们。这是远程参与者的提问被演讲者在他们观看的同时大声回答的最便宜层级。坐在效率领导者上方一层是故意的。一个通过格式决策门槛的活动,之所以如此是因为远程观众重要到值得为之付费。购买最昂贵的交付模式却提供最便宜的对等,是这个整个 skill 存在的目的所要指出的失败。
  • 仅直播流 - 最低限度,而且确实经常是正确的答案。远程观看,仅此而已。每当菜单3不能为一个环节指定一个人时,降到它。 一个在环节期间没人阅读的开放提问频道比没有频道更糟:它在一个时刻邀请问题并在同一时刻丢弃它,当着提问者的面。这是二等体验最纯粹的形式。
  • 异步书面返回路径 - 带着_明确的_承诺收集问题:以书面形式回答,由谁,在什么时候之前。它在环节期间不花费注意力,而且它是诚实的,这是把它与下面被删除的层级区分开来的原因。它买到的是一个真实的答案,而不是实时的。
  • 为远程问题保留的提问时间 - 主持人通过规则而不是善意将部分问答保留给远程。规则是关键:善意每次都会输给一屋子举起的手,因为现场观众有默认频道,而远程没有。它花费主持人一份简报,以及在时间压力下坚守规则的自律。
  • 远程参与者出现在房间里 - 饥饿选项:声音轴最高,工作量最高,合规性最高,所以效率永远不会选它。它是唯一一个演讲者回答一个人而不是读一行字的层级。返回音频路径本身由
    samber/dev-event-organizer-skills@event-production
    构建:指定要求,绝不指定设备。提升条件:
    • 与问题1相关:付费虚拟门票作为参与而非观看出售。
    • 与问题1相关:点名远程互动的赞助商交付物。
    • 与问题3相关:远程观众足够集中,醒着的人就是重要的人。
  • 删除,不要降级:一个开放但没有人在读的远程问题频道。 把它从这个菜单和上面的轴线中划掉。它看起来像对等的免费版本,而它是比底线还差的一层:它在环节内部做出承诺并在同一环节内打破它。它还带着一个没有回应者的行为义务,
    samber/dev-event-organizer-skills@event-comms-channels
    已经将其论证为持续成本而非设置成本。上面的异步层级是一个不同的产物:它说明了将要发生什么,并且有人对它负责。

Menu 3 - The crew split and the remote advocate

菜单3 - 工作人员分工和远程倡导者

Who is looking after the remote side, and where they are standing. Define the remote advocate's authority explicitly in your document, as you would for any role that is not an industry standard.
Ranking (default, not a law - Q2, Q8, Q9 and Q10 re-rank it):
  • effort (people committed per streamed session-hour, briefing depth, roster complexity):
    a host on the feed as well > a watcher off the floor and an advocate in each room > an advocate inside each streamed room > one watcher off the floor, event-wide > no split
    . The advocate outranks the watcher on cost for two compounding reasons:
    • It scales with streamed rooms. One watcher covers however many rooms exist, so the gap widens with every room added.
    • It needs a session-by-session briefing on the programme and the questions. The watcher needs only the output.
  • value, the remote audience is served inside a session (a question is relayed, remote is acknowledged, the speaker knows they are there):
    a host on the feed as well == a watcher off the floor and an advocate in each room > an advocate inside each streamed room > one watcher off the floor, event-wide > no split
    - argued tie: the host works the gaps between sessions, so it adds nothing inside one. The two rungs put the same person doing the same relay in the same room.
  • value, a remote failure is noticed and named (a dead, silent or frozen feed is caught and the remote audience is told):
    a host on the feed as well > a watcher off the floor and an advocate in each room > one watcher off the floor, event-wide > an advocate inside each streamed room > no split
    . The crossing here is the finding: the lone watcher beats the in-room advocate on this axis while costing less, because the watcher sees what the audience receives and the advocate sees the room. An advocate standing beside the stage is the last person who will notice the stream died.
  • efficiency:
    an advocate inside each streamed room > one watcher off the floor, event-wide > a watcher off the floor and an advocate in each room > a host on the feed as well > no split
No compliance-cost axis is printed, because nothing here varies on one. Every rung's exposure is whatever Menu 1's eligibility and Menu 2's parity depth already fixed. Adding a person changes who notices a failure, not what is captured or published.
Dominance check: 5 rungs, 10 pairs, one cost axis and two value axes, zero strict-dominance relations.
Three mechanisms account for all ten, and none covers another's pairs:
  • Blocked by the plain mechanism, cost running opposite to both value axes at once (eight pairs): no-split against each of the four staffed rungs, the lone watcher against the both-rung and against the host rung, and the advocate against those same two.
  • Blocked by the two value axes genuinely crossing (one pair): the lone watcher against the in-room advocate, where the watcher is cheaper and catches failures better, and only in-session service saves the advocate.
  • Blocked because in-session service ties and only the failure axis separates them (one pair): the both-rung against the host rung.
Zero relations means the check caught no misordering.
  • An advocate inside each streamed room - the default: one named person per streamed session whose job is the remote audience. They relay questions, they say out loud that remote is watching so the speaker addresses them, and they are the person Menu 2's default rung requires. It scales with streamed rooms rather than with remote headcount, so it needs no per-attendee ratio. None has been published. Move up to the both-rung as soon as Q2 says more than one room carries a feed at once, since nobody standing in one room can see another room's output.
  • One watcher off the floor, event-wide - a person in no room at all, watching the outgoing feed as a remote attendee receives it. The watcher sees what the room's crew structurally cannot: whether the feed is live, audible, or frozen. It beats the default whenever Menu 2 landed on feed-only, where there is nothing to relay and everything to watch.
  • A watcher off the floor and an advocate in each room - both postures at once, and the first rung that covers both value axes properly rather than trading one for the other.
  • A host on the feed as well - the starved option: ties the top of in-session service, tops the failure axis, tops effort, so efficiency never picks it. It is the only rung where somebody speaks to the remote audience during the gaps a room fills with corridor conversation, the stretch where a remote attendee has nothing at all and no way to tell a break from a failure. Promotion conditions:
    • Keyed to Q1: a paid virtual ticket.
    • Keyed to Q1: a sponsor deliverable naming the stream.
    • Keyed to Q8: a recurring event where the same person can hold the role again and the briefing is written once.
  • Delete, do not demote: the room lead doubling as the remote advocate. Strike it from this menu and from the axis lines above.
    samber/dev-event-organizer-skills@event-run-of-show
    defines that role as "one person per room who owns that room's clock: holds a start, cuts a Q&A, gets the tech owner, and escalates to the on-duty organizer". That is precisely the job competing with relaying a remote question, at precisely the moment both come due. It reads as the free version of the default, and it guarantees which of the two gets dropped.
谁在照顾远程侧,他们站在哪里。在你的文档中明确定义远程倡导者的权力,就像你为任何不是行业标准的角色所做的那样。
排序(默认,不是法则——问题2、问题8、问题9和问题10会重新排序它):
  • 工作量(每个直播环节小时投入的人员、简报深度、排班复杂性):
    流上还有一个主持人 > 一个场外观察者加每个房间一个倡导者 > 每个直播房间内一个倡导者 > 一个全场范围的场外观察者 > 不分摊
    。倡导者在成本上胜过观察者有两个叠加的原因:
    • 它随直播房间数扩展。一个观察者覆盖无论存在多少个房间,所以差距随着每个房间的增加而扩大。
    • 它需要针对节目和问题的逐环节简报。观察者只需要输出。
  • 价值,远程观众在环节内得到服务(问题被转述,远程被承认,演讲者知道他们在那里):
    流上还有一个主持人 == 一个场外观察者加每个房间一个倡导者 > 每个直播房间内一个倡导者 > 一个全场范围的场外观察者 > 不分摊
    - 有争议的平局:主持人在环节之间的间隙工作,所以它在环节内部不增加任何东西。两个层级把同一个人放在同一个房间里做同样的转述。
  • 价值,远程故障被注意到并命名(一个死掉的、静音的或冻结的流被抓住并且远程观众被告知):
    流上还有一个主持人 > 一个场外观察者加每个房间一个倡导者 > 一个全场范围的场外观察者 > 每个直播房间内一个倡导者 > 不分摊
    。这里的交叉是发现:单独的观察者在这个轴上胜过房间内倡导者,同时成本更低,因为观察者看到观众接收到的内容,而倡导者看到房间。站在舞台旁边的倡导者是最后一个会注意到流死掉的人。
  • 效率:
    每个直播房间内一个倡导者 > 一个全场范围的场外观察者 > 一个场外观察者加每个房间一个倡导者 > 流上还有一个主持人 > 不分摊
没有印刷合规成本轴,因为这里没有任何东西在一个轴上变化。每个层级的风险暴露就是菜单1的资格和菜单2的对等深度已经固定的东西。增加一个人改变谁注意到失败,而不是采集或发布什么。
支配性检查:5个层级,10对,一个成本轴和两个价值轴,零严格支配关系。
三个机制解释了全部十对,没有一个覆盖另一个的对:
  • 因普通机制受阻,成本同时与两个价值轴相反(八对):不分摊对四个有人员的层级中的每一个,单独观察者对双位层级和主持人层级,以及倡导者对同样的两个。
  • 因两个价值轴真正交叉受阻(一对):单独观察者对房间内倡导者,其中观察者更便宜且更好地抓住故障,只有环节内服务拯救倡导者。
  • 因环节内服务平局而只有故障轴区分它们受阻(一对):双位层级对主持人层级。
零关系意味着检查没有抓住任何排序错误。
  • 每个直播房间内一个倡导者 - 默认:每个直播环节一个指定的人,其工作就是远程观众。他们转述问题,他们大声说远程在观看以便演讲者对他们讲话,他们是菜单2默认层级所要求的人。它随直播房间数扩展,而不是随远程人数扩展,所以它不需要每人比例。没有发布过任何比例。一旦问题2说多个房间同时承载直播流,就升级到双位层级,因为站在一个房间里的人无法看到另一个房间的输出。
  • 一个全场范围的场外观察者 - 一个不在任何房间里的人,作为远程参与者接收的方式观看输出流。观察者看到房间工作人员在结构上无法看到的东西:流是活的、可听的,还是冻结的。每当菜单2落在仅直播流上时,它胜过默认,因为那里没有东西可以转述,而一切都需要观看。
  • 一个场外观察者加每个房间一个倡导者 - 两种姿态同时出现,第一个正确覆盖两个价值轴而不是在它们之间交易的层级。
  • 流上还有一个主持人 - 饥饿选项:环节内服务平局最高,故障轴最高,工作量最高,所以效率永远不会选它。它是唯一一个在房间用走廊谈话填满的间隙中有人对远程观众说话的层级,那段远程参与者什么都没有、也无法区分休息和故障的时间。提升条件:
    • 与问题1相关:付费虚拟门票。
    • 与问题1相关:点名直播流的赞助商交付物。
    • 与问题8相关:一个经常性活动,同一个人可以再次担任该角色,简报只写一次。
  • 删除,不要降级:房间负责人兼任远程倡导者。 把它从这个菜单和上面的轴线中划掉。
    samber/dev-event-organizer-skills@event-run-of-show
    将该角色定义为"每个房间一个人,拥有那个房间的时钟:把握开始时间,截断问答,找到技术负责人,并升级到值班组织者"。这正是与转述远程问题竞争的工作,恰恰在两个都到期的时候。它看起来像默认的免费版本,它保证了两个中哪一个被丢弃。

The cue track the stream needs

流媒体需要的提示轨

This is a delta on an existing artifact, not a menu. Forcing a ranked ladder onto one added column would be padding, so it stays a section.
samber/dev-event-organizer-skills@event-run-of-show
owns the day-of document. A hybrid needs no second one. It needs a second column on the same rows, because two documents drift and the drift is invisible until the day.
  • Hand that column to that skill as an addition.
  • Never author a parallel document.
What the column carries, per row:
  • What the stream is showing at that moment: the stage, the slides, or a holding card.
  • Who owns that decision.
  • What the remote audience is being told.
The synchronization rule: the room's transition and the stream's transition are the same row. A cue that exists in only one column is exactly where the two audiences diverge, and it is the row to re-read at the briefing.
Two row types deserve the most attention, and neither is a session:
  • Every gap. The room fills a break with corridor conversation and the stream fills it with nothing, so a remote attendee cannot distinguish a scheduled break from a failure.
  • Any moment the room is told something out loud that was never typed anywhere: a room change, a delay, a swapped speaker.
The second type is the documented failure this skill exists around: a workshop running late, remote participants never told, the staff busy in the room.
A gap this order does not close.
samber/dev-event-organizer-skills@event-schedule-design
writes a disruption priority order into the grid document and hands it over.
samber/dev-event-organizer-skills@event-run-of-show
restates it in its own words as "protect the plenary or keynote first, protect the headline commitment the audience showed up for next, minimize how many other sessions the fix disturbs, then lock the revised grid for the rest of the block", and executes it.
Read the audience in that sentence. It is singular, and a hybrid has two.
Hybrid conferences and AV crews document a default for most of what that raises:
  • Keep the room going and fix a dead feed in parallel, rather than pausing on reflex.
  • Put the authority to give up on a feed inside the technical chain, escalated to a senior organizer, never a volunteer left alone with the call.
  • Give the remote side a named live-chat contact rather than an intermittently checked inbox.
Two questions have no documented answer:
  • Who wins when the remote-side person and the room lead need the same technician at once.
  • Whether a session moved to fix an in-room problem takes the remote programme with it.
Decide both in advance. Write them into the document beside the documented defaults, say who decided them, and never present either as inherited practice, because neither is. For each default and where it comes from, read references/dual-audience-cue-track.md.
这是对现有产物的增量,不是菜单。把排序的梯子强加到一列新增列上是填充内容,所以它保持为一个章节。
samber/dev-event-organizer-skills@event-run-of-show
拥有当日文档。混合式不需要第二份。它需要在同一行上的第二列,因为两份文档会漂移,而漂移在当天之前是不可见的。
  • 把那列交给那个 skill 作为补充。
  • 绝不要编写平行文档。
列的内容,按行:
  • 流在那个时刻显示什么:舞台、幻灯片,还是保持卡。
  • 谁拥有那个决定。
  • 远程观众被告知什么。
同步规则:房间的过渡和流的过渡是同一行。只存在于一列中的提示正是两组观众分叉的地方,也是简报时要重读的行。
两种行类型最值得注意,而且都不是环节:
  • 每一个间隙。房间用走廊谈话填满休息时间,而流用什么都没有填满,所以远程参与者无法区分计划中的休息和故障。
  • 任何房间被大声告知某事而它从未被输入任何地方的时刻:房间变更、延迟、演讲者更换。
第二种类型是这个 skill 存在的文档化失败:一个工作坊进行到很晚,远程参与者从未被告知,工作人员忙于房间。
这个顺序没有弥合的空白。
samber/dev-event-organizer-skills@event-schedule-design
在日程表文档中写入中断优先级顺序并移交它。
samber/dev-event-organizer-skills@event-run-of-show
用自己的话复述它为"首先保护全体会议或主题演讲,其次保护观众前来的头条承诺,最小化修复打扰多少其他环节,然后为其余的块锁定修订后的日程表",并执行它。
读那句话中的观众。它是单数的,而混合式有两个。
混合会议和AV团队为它提出的大部分内容记录了一个默认:
  • 保持房间继续,并行修复死掉的流,而不是反射性地暂停。
  • 把放弃一条流的权力放在技术链中,升级到资深组织者,绝不让志愿者独自承担这个决定。
  • 给远程侧一个指定的实时聊天联系人,而不是一个间歇性检查的收件箱。
两个问题没有记录的答案:
  • 当远程侧人员和房间负责人同时需要同一个技术人员时,谁赢。
  • 为修复房间内问题而移动的环节是否带着远程节目一起移动。
提前决定两者。把它们写在文档中记录的默认值旁边,说明谁决定的,并且绝不要把任何一个呈现为继承的实践,因为两者都不是。关于每个默认及其来源,阅读 references/dual-audience-cue-track.md。

Failure modes

失败模式

  • Re-deciding the format. The cost case against hybrid is owned upstream, and it is strong. Rehearsing it means you are in the wrong skill: the user needs the format decision, not this one.
  • Attention, not equipment. Both documented failures are about where the staff were looking: remote attendees not told a schedule slipped, and remote check-in lagging because the team was checking in the room. Buying more equipment fixes neither.
  • Parity by goodwill. "We'll take remote questions too" loses to a room of raised hands every time, because the in-room audience has a default channel and remote does not. Either a person owns it or a rule reserves it.
  • A question channel nobody reads. The one rung worse than giving remote nothing: it invites a question and drops it in front of the person who asked.
  • The gaps. Between sessions the room has a corridor and the remote audience has silence, indistinguishable from a dead feed. Say something on the stream, or publish in advance what the silence means.
  • Marking eligibility after publication. A session removed from the remote programme after the grid is public is a retraction, not a decision. Settle consent and instrumentation first.
  • Specifying equipment. Cameras, encoders, uplinks and return audio belong to the production sibling. State the requirement. Let it state the kit.
  • Assuming the remote audience is small enough not to matter. Academic conferencing data on remote turnout exists but transfers poorly to technology events. The contexts are too different. Do not invent a planning number here.
  • 重新决定格式。 反对混合式的成本论证在上游拥有,而且它很强。排练它意味着你处于错误的 skill:用户需要格式决定,而不是这个。
  • 关注,而不是设备。 两个文档化的失败都是关于工作人员在看哪里:远程参与者没有被告知日程滑动,远程签到滞后因为团队在房间里签到。买更多设备修不了任何一个。
  • 靠善意的对等。 "我们也会接受远程问题"每次都会输给一屋子举起的手,因为现场观众有默认频道,而远程没有。要么一个人拥有它,要么一条规则保留它。
  • 一个没人读的问题频道。 唯一比什么都不给远程更糟的层级:它邀请一个问题并当着提问者的面丢弃它。
  • 间隙。 在环节之间,房间有走廊而远程观众有沉默,与死掉的流无法区分。在流上说些什么,或提前发布沉默意味着什么。
  • 在发布后标记资格。 在日程表公开后从远程节目中移除一个环节是撤回,而不是决定。先解决同意和仪器配置。
  • 指定设备。 摄像机、编码器、上行链路和返回音频属于制作兄弟 skill。说明要求。让它说明设备。
  • 假设远程观众小到无关紧要。 关于远程出席的学术会议数据存在,但转移到技术活动上效果很差。上下文太不同了。不要在这里编造一个规划数字。

Measurement

衡量

Three completeness gates, checkable before the first session and free of any threshold to argue about:
  • Every remote-eligible session has a named person for the remote side, or its return path is closed. Not a function - a name.
  • Every row of the cue sheet that changes what the room sees also says what the stream shows.
  • The disruption priority order says, in writing, what happens when a remote-side failure and an in-room one compete.
Everything below is a metric you set rather than an industry standard. Say so when you present it.
  • Remote questions that reached a stage, against remote questions asked (self-set). This is the number Menu 2 actually moves, and the one that tells you whether the parity rung was real or nominal.
  • Announcements made in the room that never reached the remote channel (self-set). Counted, never minimized - this is the documented failure, measured directly.
  • Time from a feed problem starting to the remote audience being told something (self-set). This is what Menu 3's watcher rung buys.
  • Remote-eligible sessions delivered without an audience-visible failure, over remote-eligible sessions scheduled (self-set).
Pick two or three, write down what change each would trigger, and record them before the event rather than after.
三个完整性门,可在第一节之前检查,并且没有任何需要争论的阈值:
  • 每个远程合格环节都有一个为远程侧指定的有名有姓的人,或者它的返回路径被关闭。不是一个职能——一个名字。
  • 提示表的每一行,如果改变房间看到的内容,也说明流显示什么。
  • 中断优先级顺序以书面形式说明,当远程侧故障和房间内故障竞争时会发生什么。
以下一切都是你自己设定的指标,而不是行业标准。呈现时说明这一点。
  • 到达舞台的远程问题,对远程问题被问出的数量(自设)。这是菜单2实际改变的数字,也是告诉你对等层级是真实的还是名义上的数字。
  • 在房间里做出但从未到达远程频道的公告(自设)。数出来,绝不最小化——这是文档化的失败,直接测量。
  • 从流问题开始到远程观众被告知某事的时间(自设)。这是菜单3的观察者层级买到的东西。
  • 没有观众可见失败交付的远程合格环节,对计划中的远程合格环节(自设)。
选择两三个,写下每个会触发什么改变,并在活动之前而不是之后记录它们。

Invocation examples

调用示例

  • "We're streaming our conference this year as well as running the room. Which talks should remote actually get?"
  • "How do we make sure remote attendees get real Q&A and not just a video feed?"
  • "Who do we need on the day for the remote side, on top of the AV crew?"
  • "Write the run of show for a day with both an in-room and an online audience."
  • "Our remote attendees said they felt like second-class attendees last year. What do we change?"
Expected output: a hybrid design with:
  1. What the remote audience was promised, in one sentence.
  2. The eligibility column marked on the published grid, with the rung chosen.
  3. The parity depth and what it looks like inside a session.
  4. The remote-side staffing assigned by name per streamed session.
  5. The stream's cue column handed to the run of show.
  6. The two-audience disruption rule, with the person who decided it.
  7. The staffing consequence split for the budget.
Presented section by section for validation before the grid is published.
  • "我们今年除了办房间还要直播我们的会议。远程应该真正得到哪些演讲?"
  • "我们如何确保远程与会者获得真正的问答而不只是视频流?"
  • "除了AV团队,我们在当天还需要谁负责远程侧?"
  • "为同时有现场和在线观众的一天编写运行表。"
  • "我们的远程与会者说他们去年感觉像二等与会者。我们要改变什么?"
预期输出:一个混合式设计,包含:
  1. 远程观众被承诺了什么,用一句话。
  2. 在已发布的日程表上标记的资格列,以及选择的层级。
  3. 对等深度以及它在环节内部的样子。
  4. 按每个直播环节的名字分配的远程侧人员。
  5. 交给运行表的流提示列。
  6. 两组观众的中断规则,以及决定它的人。
  7. 为预算拆分的人员配置后果。
在日程表发布之前逐节呈现以供验证。

References

参考

  • references/remote-eligibility-and-parity-mechanics.md - read while choosing the parity depth: what each rung looks like minute to minute, the relay mechanic, and the consent questions a live feed adds.
  • references/dual-audience-cue-track.md - read while writing the cue column: worked rows, the gap rows, and where each disruption default comes from.
  • references/remote-eligibility-and-parity-mechanics.md - 在选择对等深度时阅读:每个层级每分钟是什么样子、转述机制,以及直播流增加的同意问题。
  • references/dual-audience-cue-track.md - 在编写提示列时阅读:工作行、间隙行,以及每个中断默认值的来源。