workshop-program-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Workshop Program Design

工作坊课程设计

You design the internal mechanics of a hands-on workshop or training session:

How many people can be in the room.
Who helps them when they get stuck.
What has to be true about their machine before they sit down.
What they leave with.
What happens when the room's network cannot carry what the exercise needs.

Your inputs arrive decided:

Whether a workshop day or track exists at all, how it is bracketed against the talk days, and how it is ticketed -
```
samber/dev-event-organizer-skills@event-format-selection
```
. Do not re-argue any of it.

Which proposals were accepted -

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

Where each session lands in the grid, and the buffer around it -
```
samber/dev-event-organizer-skills@event-schedule-design
```
, which consumes the capacity and length you set here as inputs.
The recording and streaming signal path for a captured workshop -
```
samber/dev-event-organizer-skills@event-production
```
, a different failure surface from a room of participant laptops that cannot install a dependency. You stop at the attendee-side environment.

Every ranking below is a default, not a law: it shifts with context and with who executes it. After the interview, re-rank all four menus against what you already know. Any one of these overturns a default rung:

An instructor who already runs this exact workshop commercially.
A venue you have used four times and whose network you have measured.
A sponsor providing the cloud environment.
A cohort on employer-managed laptops.

你设计的是动手实践型工作坊或培训课程的内部机制：

房间里能有多少人。
他们卡住时谁会帮忙。
在他们坐下来之前，他们的机器必须具备什么条件。
他们离开时带走了什么。
当房间的网络无法承载练习所需时会发生什么。

你的输入是已经决定好的：

工作坊日或专场是否存在、如何与演讲日并列安排、如何售票——
```
samber/dev-event-organizer-skills@event-format-selection
```
。不要重新争论其中任何一点。

哪些提案被接受——

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

。

每个环节在日程网格中的位置及其周围缓冲——
```
samber/dev-event-organizer-skills@event-schedule-design
```
，它会把你在本文中设定的容量和时长作为输入。
被录制工作坊的录制与直播信号链路——
```
samber/dev-event-organizer-skills@event-production
```
，它与“一屋子参与者笔记本电脑装不上依赖”是不同层面的故障。你只负责到参会者侧环境为止。

下面的每个排序都是默认值，而不是铁律：它会随上下文和由谁执行而变化。访谈之后，根据你已经知道的情况重新排序全部四个菜单。下面任意一个因素都会推翻默认档位：

一位已经商业性地讲过这个完全相同工作坊的讲师。
一个你用过的、并且实测过网络的场地。
一个提供云环境的赞助商。
一群使用公司统一管理笔记本电脑的学员。

Interview

访谈

Ask one question at a time, multiple-choice where possible. Question 11 exists because the menus diverge sharply on time-to-effect, durability and effort - those orderings cannot be picked for the user.

Which part of the delivery is on the table: one session's mechanics, every session inside a workshop day, or a post-mortem on a workshop that went badly? Skip the menus already settled.
What must a participant be able to do at the end that they cannot do now - and can that be acquired by reading the material instead of doing it in the room?
Does the exercise need anything installed, downloaded or signed into on a participant's own machine: software, a toolchain, a vendor account?
Does any part of the exercise depend on a live network service while the session runs - a hosted console, an API, a package registry, a remote lab?
Can every participant be expected to bring a machine capable of running it, and be permitted to install on it? Would requiring one exclude anyone in the intended cohort?
Does the exercise run at distinct workstations or physical steps, or does everyone do the same thing at their own seat?
How many participants are expected, and what does the room actually give you: seats, movable furniture, power at the seats?
Who is in the room to help besides the person presenting, and are they competent in the material or only in the logistics?
What has the venue answered in writing about this room's network: sustained bandwidth, how many devices it holds, and whether it blocks unusual protocols or device types?
Will you, the organizer, be the party accepting a third-party platform's terms and issuing credentials on participants' behalf - and will any participant be a minor?
Three that re-rank everything:
- By what date must this be ready.
- Is this a one-off session or a curriculum you will run every edition.
- What is the effort ceiling: organizer hours, people you can recruit into the room, and how reversible the choice has to be.
Did a prior edition's workshop network fail, and what specifically broke - bandwidth, a blocked protocol, a blocked device class, or the venue never answering?

一次只问一个问题，尽可能用选择题。第 11 题存在是因为这些菜单在见效时间、持久性和投入上分歧很大——这些排序不能替用户决定。

本次要讨论的是交付的哪个部分：单个环节的机制、工作坊日内的每一个环节，还是对一次出问题工作坊的事后复盘？跳过已经确定的菜单。
参与者结束时必须能做到什么之前做不到的事——这件事能不能通过阅读材料获得，而不是必须在房间里动手做？
练习是否需要在参与者自己的机器上安装、下载或登录任何东西：软件、工具链、厂商账号？
练习的任何部分是否在环节进行中依赖实时网络服务——托管控制台、API、包仓库、远程实验环境？
能否期待每个参与者都自带一台能跑起来的机器，并且被允许在上面安装软件？要求自带机器是否会排除目标学员中的某些人？
练习是在不同的工位或物理步骤上进行，还是每个人在自己的座位上做同样的事？
预计有多少参与者，房间实际能提供什么：座位、可移动家具、座位旁边的电源？
除了主讲人之外，房间里还有谁可以帮忙，他们懂材料还是只懂后勤？
场地对房间的网络问题书面回答了什么：持续带宽、能容纳多少设备、是否屏蔽不常见协议或设备类型？
作为组织者，你是否要替参与者接受第三方平台的条款、并代他们发放凭证——以及参与者中是否有未成年人？
三个会重新排序一切的问题：
- 必须在什么日期前准备好。
- 这是一次性环节，还是每届都会跑的课程。
- 投入上限是多少：组织者工时、你能招进房间的人、以及选择必须有多么可逆。
上一届的工作坊网络是否出过故障，具体坏在哪里——带宽、被屏蔽的协议、被屏蔽的设备类型，还是场地一直不回应？

Hands-on commitment

动手实操承诺

The first decision, and the one most often skipped: does this session put hands on keyboards at all? Ranking (default, not a law - Q2 and Q9 re-rank it):

effort (build, rehearsal, room support, day-of exposure):
```
full hands-on > demonstration only > no live hands-on
```
value, participants leave able to do the thing themselves:
```
full hands-on > demonstration only > no live hands-on
```
value, the content gets delivered whatever the room does:
```
no live hands-on > demonstration only > full hands-on
```

efficiency:

no live hands-on > demonstration only > full hands-on

No live hands-on - the material ships as published resources, or the content runs as a talk. On a delivery view this is no workshop at all, and it wins the efficiency round outright: nothing in it can fail on the day. It is an established practice rather than a cop-out. MLH's hardware guide builds a whole async layer for exactly this: "Async resources allow students to familiarize themselves with tools and concepts on their own schedule before the hackathon begins". The same guide tells organizers to "Limit the number of workshops during an event as they consume valuable building time". Note the boundary: whether the day exists is
```
samber/dev-event-organizer-skills@event-format-selection
```
's call, already made; whether this session is hands-on is yours.
Demonstration only - the instructor drives, the room watches, nobody installs anything. One machine and one connection can fail, and both are yours.
Full hands-on - the default only for what reading cannot teach. MLH's pre-event workshop covers the component the participants will actually use, stating "This covers basic wiring and the necessary initial code upload". Promotion condition, keyed to Q2: the answer to "can it be acquired by reading" is no.
Delete, do not demote: strike full hands-on from this menu and from the axis lines above when Q4 says the exercise needs a live network service and Q9 says the venue has not answered the network question in writing. Run the demonstration and publish the material instead. A hands-on session nobody can connect to is the specific failure this skill exists to prevent. A deleted rung parked at the bottom reappears as scope on the day.

第一个决定，也最常被跳过：这个环节到底要不要让大家动手敲键盘？排序（默认值，不是铁律——Q2 和 Q9 会重排）：

投入（搭建、彩排、房间支持、当天风险敞口）：
```
full hands-on > demonstration only > no live hands-on
```

价值，参与者离开时能自己动手做：

full hands-on > demonstration only > no live hands-on

价值，无论房间发生什么内容都能交付：
```
no live hands-on > demonstration only > full hands-on
```

效率：

no live hands-on > demonstration only > full hands-on

No live hands-on（无现场实操）——材料以已发布的资源形式交付，或内容以演讲形式进行。从交付视角看，这_根本不是工作坊_，而且它全面赢得效率项：当天不会有任何东西可失败。这是一个成熟做法，不是逃避。MLH 的硬件指南正是为此构建了一整层异步内容：“异步资源让学生可以在黑客松开始之前按自己的时间表熟悉工具和概念。”同一份指南还告诉组织者“限制活动期间的工作坊数量，因为它们会消耗宝贵的构建时间”。注意边界：_工作坊日_是否存在是
```
samber/dev-event-organizer-skills@event-format-selection
```
的决定，已经做完了；_这个环节_是否动手实操是你的决定。
Demonstration only（仅演示）——讲师操作，房间观看，没人安装任何东西。只有一台机器和一条连接可能出故障，而且都是你的。
Full hands-on（完全动手实操）——只有阅读无法教会的东西才默认使用。MLH 的会前工作坊会覆盖参与者将实际使用的组件，并指出“这涵盖了基本接线和必要的初始代码上传”。提升条件，对应 Q2：对“能否通过阅读获得”的回答是“否”。
**删除，而不是降级：**当 Q4 说练习需要实时网络服务、且 Q9 说场地没有书面回答网络问题时，从本菜单和上面对应的排序轴中划掉 full hands-on。改为做演示并发布材料。一个无人能连接上的动手实操环节，正是本 skill 要防止的具体失败。被删掉并扔到底部的档位，会在当天以“范围蔓延”的形式重新出现。

Facilitator coverage

助教/引导者覆盖

How a stuck participant gets unstuck. Ranking (default, not a law - Q6 and Q8 re-rank it):

effort (recruiting, briefing, coordination on the day):

stationed helpers per work area > roaming troubleshooter > structured peer pairing > solo instructor

value, a stuck participant gets unstuck before giving up:

stationed helpers > roaming troubleshooter > structured peer pairing > solo instructor

value, coverage that holds as the room grows:
```
structured peer pairing > stationed helpers > roaming troubleshooter == solo instructor
```
- argued tie: both put a fixed number of answerers in front of a variable number of participants, so doubling the room halves what each participant can get either way; the difference between them is where that one extra person stands, which this axis does not measure.

efficiency:

structured peer pairing > roaming troubleshooter > solo instructor > stationed helpers

⚠️ The first value axis is rank-identical to inverse effort. Recovery latency is a real quantity, but ordering the rungs by it discriminates nothing effort has not already ordered, and an efficiency line resting on it alone collapses into cheapest-first. The growth axis is therefore the only one doing work, and it alone is why peer pairing leads rather than the solo rung.

Roaming troubleshooter - the default: MLH tells the workshop host to "have a backup speaker walking around to help troubleshoot for those who start falling behind", and, for a remote room, to "ask them to share their screen to troubleshoot their issues". One recruited person who knows the material, not a logistics volunteer - Q8 asks which you have.
Structured peer pairing - the efficiency leader. Its help capacity grows with the room by definition, which is what wins it the growth axis. CS-classroom pair-programming pedagogy gives that a mechanism rather than a headcount argument: assigned driver/navigator roles, swapped every 5-10 minutes, keep a navigator watching the driver's screen for the whole session. "Structured" is the load-bearing word. The same guidance calls plain, role-free pairing the version that "can often lead to one, or both, learners quickly losing focus" - this rung's own unmanaged failure under a different name. It can still pair two people who are both stuck and nobody notices; check in with pairs on the cadence the roaming rung already keeps.
Stationed helpers per work area - the starved option: top of latency, top of effort, so efficiency never picks it. MLH's tool stations say to "ensure a mentor is stationed nearby" and to "Ensure these stations are staffed by experienced volunteers". Promotion condition, keyed to Q6: the exercise genuinely runs at distinct workstations or physically distinct steps, so a helper posted at one covers everyone who reaches it.
Delete, do not demote: strike solo instructor from this menu and from the axis lines above as soon as the hands-on menu lands on full hands-on. Someone in a room doing the exercise will be stuck while the instructor is mid-sentence, and no rung below the roaming one addresses that.

Size coverage from Q6 and Q7 and mark the figure as yours - this number must come from your own judgment, not an external standard.

卡住的参与者如何脱困。排序（默认值，不是铁律——Q6 和 Q8 会重排）：

投入（招募、简报、当天协调）：

stationed helpers per work area > roaming troubleshooter > structured peer pairing > solo instructor

价值，卡住的参与者在放弃前得到帮助：

stationed helpers > roaming troubleshooter > structured peer pairing > solo instructor

价值，覆盖能力随房间规模增长：
```
structured peer pairing > stationed helpers > roaming troubleshooter == solo instructor
```
——有争议的并列：两者都是用固定数量的回答者面对可变数量的参与者，所以房间人数翻倍，每个参与者能得到的帮助都会减半；区别只在于那多出来的人站在哪里，这是本轴不衡量的。

效率：

structured peer pairing > roaming troubleshooter > solo instructor > stationed helpers

⚠️ **第一个价值轴与“反向投入”排序完全相同。**恢复延迟是一个真实数量，但用它给档位排序并没有区分出投入没有区分出的东西，而仅靠它的效率线会塌缩成“最便宜优先”。因此成长轴才是唯一做功的轴，也只有它解释了为什么对等配对领先于单人讲师档。

Roaming troubleshooter（巡回排障者）——默认：MLH 告诉工作坊主持人“安排一位备用讲师四处走动，帮助那些开始落后的人排障”，对远程房间则“让他们共享屏幕来排障”。这是一个懂材料的招募人员，而不是后勤志愿者——Q8 问的就是你拥有哪种。
Structured peer pairing（结构化对等配对）——效率冠军。它的帮助能力按定义会随房间规模增长，这正是它赢得成长轴的原因。CS 课堂的结对编程教学法给了它一个机制而非人头论证：分配 driver/navigator 角色，每 5-10 分钟交换一次，让 navigator 在整个环节中看着 driver 的屏幕。“结构化”才是承重的词。同一份指南把无角色的普通配对称为“往往会导致一个或两个学习者很快失去专注”的版本——也就是这个档位在无人管理时的失败，换了个名字。它仍然可能把两个都卡住的人配在一起而没人注意到；要按巡回档已有的节奏去检查各对。
Stationed helpers per work area（每个工作区驻点助教）——被冷落的选项：延迟最低、投入最高，所以效率永远不会选它。MLH 的工具站说要“确保附近有导师驻点”，并“确保这些站点有经验丰富的志愿者值守”。提升条件，对应 Q6：练习确实在不同的工位或在物理上不同的步骤上进行，因此驻守在一个点位的助教能覆盖所有来到该点位的人。
**删除，而不是降级：**一旦动手实操菜单落在 full hands-on 上，就立即从本菜单和上面的排序轴中划掉 solo instructor。房间里正在做练习的人会在讲师说到一半时卡住，而巡回档以下的任何档位都解决不了这个问题。

根据 Q6 和 Q7 确定覆盖规模，并把数字标为你自己的判断——这个数字必须来自你自己的判断，而不是外部标准。

Prerequisites and environment

前置条件与环境

What has to be true about a participant's machine and accounts before the session starts. Ranking (default, not a law - Q3, Q5 and Q10 re-rank it):

effort (build, maintenance, two support surfaces or one):

both paths offered > provisioned environment only > published prerequisites > nothing published

value, share of the room that can actually start:

both paths offered > provisioned environment only > published prerequisites > nothing published

value, independence from the room's network while the session runs:

published prerequisites > both paths offered > provisioned environment only > nothing published

compliance cost (review triggered, and reversibility):
```
provisioned environment only == both paths offered > published prerequisites > nothing published
```
- argued tie: both rungs put you, not the participant, in the position of accepting a platform's terms for a room of people and issuing credentials on their behalf; offering a second path alongside changes nothing about who signed.

efficiency:

published prerequisites > provisioned environment only > nothing published > both paths offered

Published prerequisites - the default: most workshop pages fill a prerequisites section. They sort into three classes the sheet in references/prerequisite-and-environment-sheet.md writes out: prior knowledge, machine state, and accounts. Accounts are the class most often forgotten and the one that fails worst at minute zero.
Both paths offered - local machine or a pre-configured environment, participant's choice. As one workshop puts it: "You will have the option of either doing the workshop on the laptop or using GitHub Codespaces and a pre-configured environment". Top of readiness, top of effort, because you now maintain and support two environments.
Provisioned environment only - the starved option: it removes the hardware and install-permission barrier entirely. One workshop puts it this way: "Everything is done in a web browser (Chrome, Firefox) - no local commands or installations are needed on your laptop", with per-participant logins and a versioned preinstalled toolchain. Promotion condition, keyed to Q5 and Q10: participants cannot be expected to own a capable machine, or are not permitted to install on the one they bring, or requiring one would exclude part of the intended cohort.
Delete, do not demote: strike nothing published from this menu and from the axis lines above the moment Q3 says anything must be installed, downloaded or signed into. An empty prerequisites section is a promise that nothing is needed; publish it empty only when that promise is true.

Compliance concerns. Standing up an environment for a room means you accept a vendor's terms on behalf of people who never read them, and you issue and hold credentials. Where Q10 says minors are present, that acceptance is made for someone who cannot make it themselves. Name the review it triggers:

The platform's terms for third-party use.
Your own data posture for credentials.

The same consent question

samber/dev-event-organizer-skills@event-accessibility-inclusion

sets for participant data.

On reversibility the rungs genuinely differ. The asymmetry is this skill's own argument rather than a published one: an environment you built is torn down on your schedule; an account a participant created because you told them to persists after you stop, and you cannot delete it for them.

在环节开始前，参与者的机器和账号必须满足什么条件。排序（默认值，不是铁律——Q3、Q5 和 Q10 会重排）：

投入（构建、维护、两个支持面还是一个）：

both paths offered > provisioned environment only > published prerequisites > nothing published

价值，房间里真正能开始的人的比例：

both paths offered > provisioned environment only > published prerequisites > nothing published

价值，环节运行期间对房间网络的独立性：

published prerequisites > both paths offered > provisioned environment only > nothing published

合规成本（触发的审查，以及可逆性）：
```
provisioned environment only == both paths offered > published prerequisites > nothing published
```
——有争议的并列：两个档位都把你而不是参与者放在“替一屋子人接受平台条款并代发凭证”的位置上；在旁边提供第二条路径并不会改变谁签署了条款。

效率：

published prerequisites > provisioned environment only > nothing published > both paths offered

Published prerequisites（发布前置条件）——默认：大多数工作坊页面都会填写前置条件部分。它们分为 references/prerequisite-and-environment-sheet.md 中清单列出的三类：先备知识、机器状态、账号。账号是最常被忘记、也是在第零分钟失败得最惨的一类。
Both paths offered（提供两条路径）——本地机器_或_预配置环境，参与者自己选。正如一个工作坊所说：“你可以选择在笔记本电脑上完成工作坊，也可以使用 GitHub Codespaces 和预配置环境。”准备就绪度最高、投入也最高，因为你现在要维护和支持两个环境。
Provisioned environment only（仅提供预配置环境）——被冷落的选项：它完全消除了硬件和安装权限障碍。一个工作坊这样说：“所有操作都在网页浏览器（Chrome、Firefox）中完成——不需要在你的笔记本电脑上执行本地命令或安装任何东西”，并提供每个参与者的登录账号和带版本号的预装工具链。提升条件，对应 Q5 和 Q10：不能期待参与者拥有能用的机器，或不允许在他们带来的机器上安装，或要求自带机器会排除目标学员中的一部分人。
**删除，而不是降级：**一旦 Q3 说需要安装、下载或登录任何东西，就立即从本菜单和上面的排序轴中划掉 nothing published。空的前置条件部分是一个“什么都不需要”的承诺；只有当这个承诺为真时才发布空版本。

**合规关注点。**为一屋子人搭建环境意味着你代表那些从未读过条款的人接受厂商条款，并且你发放和持有凭证。当 Q10 说有未成年人时，这种接受是为无法自己做出同意的人做出的。指出它触发的审查：

平台关于第三方使用的条款。
你自己对凭证数据的处理姿态。

与

samber/dev-event-organizer-skills@event-accessibility-inclusion

为参与者数据设定的同一个同意问题。

在可逆性上，这些档位确实不同。这种不对称是本 skill 自己的论点，而不是某个已发布的论点：你搭建的环境会按你的时间表拆除；一个参与者因为你告诉他才创建的账号，在你停止后仍然存在，而且你无法替他删除。

Capacity: three ceilings, take the lowest

容量：三个上限，取最低值

No ranking here, deliberately. These are three ceilings on one number, not alternatives with different value. Which one binds is a fact about your exercise and your room, not a choice with an efficiency ratio, so ranking them would be false precision. Compute all three, take the lowest, and say which one bound.

Room ceiling - seats with the furniture the exercise needs. The typical band for a technical event's breakout rooms is 10-20 or 20-40 with chairs movable into a circle (see
```
samber/dev-event-organizer-skills@event-venue-sourcing
```
's space program), and power at the seats is a separate question from seats.
Coverage ceiling - how many people the instructor plus whatever the facilitator menu bought can actually reach before someone gives up. This number is yours; say so when you state it.
Exercise-throughput ceiling - how many can get real hands-on time given what is genuinely limited: kit, per-participant logins, licence seats, physical stations. This is the ceiling most often missed, because it is invisible until the twenty-first person needs the ninth board.

One low-cost mechanic worth trying, though it traces to a single 2017 event and no current conference in the record runs it - see references/capacity-length-and-network-evidence.md for what's confirmed running today instead: ask attendees before the day to "vote for your favorite workshops", explaining that "This will help us determine which rooms to place them in". Demand collected before the day beats a guess made at scheduling time, and it is a cheap request to add to whatever pre-event mail

samber/dev-event-organizer-skills@event-attendee-email-sequences

is already sending.

Session length is observed, never prescribed: published workshops cluster on 45-minute granularity and land at 150-180 minutes for real hands-on sessions. The full record, with each workshop's event and length, is in references/capacity-length-and-network-evidence.md. Hand the chosen length to

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

as an input; do not pick a slot length by averaging across events.

**这里故意不排序。**这是同一个数字上的三个上限，而不是具有不同价值的替代方案。哪一个会约束住，取决于你的练习和房间的事实，而不是一个有效率比的选择，所以对它们排序会是虚假的精确。计算全部三个，取最低值，并说明是哪一个约束住了。

房间上限——能提供练习所需家具的座位数。技术活动分组讨论室的典型区间是 10-20 或 20-40 人，椅子可以摆成圈（见
```
samber/dev-event-organizer-skills@event-venue-sourcing
```
的空间方案），而座位旁有没有电源是与座位数不同的问题。
覆盖上限——讲师加上 facilitator 菜单买到的东西，能在有人放弃之前实际触达多少人。这个数字是你的；说出来时请声明这一点。
练习吞吐量上限——在真正受限的东西（套件、每参与者登录数、许可证席位、物理工位）下，有多少人能得到真正的动手时间。这是最常被遗漏的上限，因为它在第二十一个人需要第九块板之前是不可见的。

一个值得一试的低成本机制——虽然它源自 2017 年的单一活动，记录中也没有当前会议在跑它——见 references/capacity-length-and-network-evidence.md 了解今天被确认在跑的做法：在活动前请参会者“为你最喜欢的工作坊投票”，并解释“这将帮助我们决定把它们放在哪些房间”。活动前收集的需求优于排期时的猜测，而且把它加进

samber/dev-event-organizer-skills@event-attendee-email-sequences

已经在发送的会前邮件，是一个很便宜的请求。

环节时长是被观察得到的，而不是被规定出来的：已发布工作坊以 45 分钟为粒度聚集，真正的动手实操环节落在 150-180 分钟。完整记录（含每个工作坊的活动和时长）在 references/capacity-length-and-network-evidence.md。把选定的时长作为输入交给

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

；不要通过跨活动平均来选时段长度。

Network and dependency posture

网络与依赖姿态

What you do about the room's connection before you find out the hard way. Ranking (default, not a law - Q4 and Q9 re-rank it):

effort (coordination, venue pressure, design constraint accepted):

remove the live dependency > clear the room's network in writing > declare the dependency with a fallback > assume the network holds

value, the session still runs when the room's network is bad:

remove the live dependency > clear the room's network in writing > declare the dependency with a fallback > assume the network holds

value, the exercise can still teach the topic:
```
assume the network holds == declare the dependency with a fallback == clear the room's network in writing > remove the live dependency
```
- argued tie across the three: none of them changes a single thing about what the exercise may contain; they differ only in what you know and what you said beforehand. Only the fourth deletes topics from what can be taught.

efficiency:

declare the dependency with a fallback > clear the room's network in writing > assume the network holds > remove the live dependency

Declare the dependency with a fallback - the default, near-free: one workshop states "Internet is required as we would be using the cloud-based ClickHouse instance", another asks for internet access to a remote lab and names the participant-side fallback outright, "(Use Wi-Fi or your own data)". Policy breaks these sessions more often than bandwidth does: a VPN, an ad-blocker, a blocked protocol. The named causes are listed in references/capacity-length-and-network-evidence.md.
Clear the room's network in writing - promotion condition, keyed to Q9 and Q4: the exercise needs an unusual protocol, port or device class, or the venue has not answered. Policy, not capacity, is what breaks: MLH tells organizers to work with venue infrastructure and "ensure the network allows IoT and other devices, as these are often blocked by standard university networks", and a published workshop's own prerequisites hinge on "(RDP protocol allowed)". Ask the venue the written question
```
samber/dev-event-organizer-skills@event-venue-sourcing
```
already puts to them, plus the device count and the protocol list.
Remove the live dependency - the starved option: top of resilience, top of effort, and the only rung that costs content. Promotion conditions: a venue that will not answer Q9, a prior edition where the room's network failed (keyed to Q12), or a topic that genuinely does not need the network. A cheap companion step: ask participants to pre-download, with MLH's own reason attached - "Encourage hackers to pre-download software drivers and IDEs ahead of time to reduce network load during the event".
Delete, do not demote: strike assume the network holds from this menu and from the axis lines above whenever Q3 or Q4 says a participant must download, install or authenticate during the session. A whole room installing at once is a load case, not an assumption - and asking for pre-downloads exists to remove exactly this case.

在你用惨痛方式发现之前，你如何处理房间的连接。排序（默认值，不是铁律——Q4 和 Q9 会重排）：

投入（协调、场地压力、接受的设计约束）：

remove the live dependency > clear the room's network in writing > declare the dependency with a fallback > assume the network holds

价值，房间网络很差时环节仍能跑起来：

remove the live dependency > clear the room's network in writing > declare the dependency with a fallback > assume the network holds

价值，练习仍能教这个主题：
```
assume the network holds == declare the dependency with a fallback == clear the room's network in writing > remove the live dependency
```
——三个并列有争议：它们三个都不会改变练习可能包含的内容；它们只在你事先知道什么、事先说了什么上不同。只有第四个会从可教内容中删掉主题。

效率：

declare the dependency with a fallback > clear the room's network in writing > assume the network holds > remove the live dependency

Declare the dependency with a fallback（声明依赖并提供备用方案）——默认，几乎免费：一个工作坊写道“需要互联网，因为我们使用基于云的 ClickHouse 实例”，另一个要求访问远程实验环境的互联网，并直接点出参与者侧备用方案，“（使用 Wi-Fi 或你自己的数据）”。策略配置比带宽更常搞坏这些环节：VPN、广告拦截器、被屏蔽的协议。已命名的原因列在 references/capacity-length-and-network-evidence.md 中。
Clear the room's network in writing（书面确认房间网络）——提升条件，对应 Q9 和 Q4：练习需要不常见的协议、端口或设备类型，或者场地没有回答。是策略而不是容量把事情搞坏：MLH 告诉组织者与场地基础设施合作，“确保网络允许 IoT 和其他设备，因为这些通常会被标准大学网络屏蔽”，一个已发布工作坊的前置条件也依赖于“（允许 RDP 协议）”。向场地询问
```
samber/dev-event-organizer-skills@event-venue-sourcing
```
已经在问他们的书面问题，再加上设备数量和协议清单。
Remove the live dependency（移除实时依赖）——被冷落的选项：韧性最高、投入最高，也是唯一以内容为代价的档位。提升条件：场地不愿回答 Q9、上一届房间网络出过故障（对应 Q12）、或主题确实不需要网络。一个便宜的配套步骤：让参与者预下载，并附上 MLH 自己的理由——“鼓励黑客提前预下载软件驱动程序和 IDE，以减少活动期间的网络负载”。
**删除，而不是降级：**当 Q3 或 Q4 说参与者必须在环节中下载、安装或认证时，就从本菜单和上面的排序轴中划掉 assume the network holds。整个房间同时安装是一个负载场景，而不是一个假设——要求预下载就是为了消除这个场景。

In the room, and after it

在房间里，以及之后

Workshop mechanics for day-of execution - see references/coverage-and-room-mechanics.md for detail and negative examples:

Build the recovery time into the plan rather than hoping it fits: "build time into your schedule to do breakout sessions, troubleshooting, and questions".
Size the opening to the room: "For workshops with fewer attendees, we recommend starting with an icebreaker".
Lower the cost of admitting you are stuck. MLH puts this squarely on the instructor: "be extremely aware of how intimidating code reviews and questions will be for participants".
Give the material somewhere to live afterwards: "Have a channel in slack/Discord so hackers can ask follow-up questions about the workshop topic after it ends." Publish the window that access lasts (common examples are 72 hours or a month after the conference).

当天执行的工作坊机制——详见 references/coverage-and-room-mechanics.md 及其反面示例：

把恢复时间构建进计划，而不是希望它能挤进去：“在你的时间表中留出时间做分组讨论、排障和提问。”
根据房间规模调整开场：“对于参与者较少的工作坊，我们建议以破冰开始。”
降低承认自己卡住的心理成本。MLH 把这一点明确放在讲师身上：“要非常清楚代码评审和提问对参与者来说会有多么令人生畏。”
让材料在之后有地方可去：“在 slack/Discord 中建一个频道，让黑客可以在工作坊结束后继续提出关于工作坊主题的后续问题。”公布访问持续的窗口（常见例子是会议结束后 72 小时或一个月）。

Failure modes

失败模式

Inventing a facilitator ratio. Say "one instructor plus a roaming troubleshooter, sized from the room and the exercise" and mark the sizing as yours.
Prerequisites that list software and forget accounts. Published workshops ask for a GitHub account, a vendor registration or a free product account as often as they ask for an install. An account needs a signup, an email confirmation, and sometimes an employer's SSO - all at minute zero, on the room's network, for everyone at once.
Treating a provisioned environment as the safe option. It removes the local-install failure and replaces it with total dependence on the room's connection for the whole session, plus the compliance exposure above. It is safer only against the failures you named.
Copying a session length off another event's page. Each event's length reflects its rooms, cohort and exercise. Take the granularity if it helps; do not take the number.
Letting the venue's WiFi answer be "it's fine". Real network breakages are often policy - blocked device classes, blocked protocols, a VPN, an ad-blocker - none of which a bandwidth figure would have caught.
Reopening the format decision. If the conversation drifts to whether the workshop day should exist or how to price it, that is
```
samber/dev-event-organizer-skills@event-format-selection
```
and it is already decided.
Confusing attendee-side failure with production failure. A room of laptops that cannot install a dependency is yours; a dropped camera feed on the recording is
```
samber/dev-event-organizer-skills@event-production
```
.

**凭空编造助教比例。**说“一位讲师加一位巡回排障者，规模根据房间和练习确定”，并把规模标为你的判断。
**前置条件只列软件却忘了账号。**已发布工作坊要求 GitHub 账号、厂商注册或免费产品账号的频率，和要求安装一样高。账号需要注册、邮箱确认，有时还需要雇主的 SSO——所有这些都在第零分钟、在房间网络上、每个人同时进行。
**把预配置环境当作安全选项。**它消除了本地安装失败，却用整个环节对房间连接的完全依赖来替代它，再加上上面的合规风险敞口。它只对你列出的那些失败更安全。
**从另一个活动的页面复制环节时长。**每个活动的时长反映的是它的房间、学员和练习。如果粒度有帮助就借鉴粒度；不要照抄数字。
**让场地方对 WiFi 的答复停留在“没问题”。**真实的网络故障往往是策略——被屏蔽的设备类型、被屏蔽的协议、VPN、广告拦截器——这些都不是带宽数字能捕捉到的。
**重新打开格式决策。**如果对话滑向“工作坊日是否应该存在”或“如何定价”，那是
```
samber/dev-event-organizer-skills@event-format-selection
```
，而且已经决定了。
**把参会者侧故障与制作故障混为一谈。**一屋子笔记本电脑装不上依赖是你的问题；录制中掉了一个摄像头画面是
```
samber/dev-event-organizer-skills@event-production
```
的问题。

Measurement

度量

Pick two or three. Decide in advance what result would change next edition, and write the metric and that trigger down before the session.

Ready at minute zero (self-set): the share of the room that completed the prerequisites before arriving. This is the number that tells you whether to move up the prerequisite menu, and the only way to get it is to ask at the door.
Confidence, before and after (sourced convention): a short "I am confident in my ability to..." rating for the specific skill taught, asked before the session starts and again at the end. This is the one metric here with a named precedent. The Carpentries run exactly this pair of surveys across thousands of hands-on technical-skill workshops and have reported swings from roughly a third to roughly two-thirds of respondents confident on the same task, pre-to-post. The precedent is life-sciences and data-science training rather than a developer conference, and it measures self-reported confidence, not observed task completion. Borrow the convention, not the figure.
Started-versus-finished (self-set): how many participants reached the last exercise. A wide gap with a full room points at coverage; a wide gap with a small room points at prerequisites.
Help latency (self-set): how long a raised hand waits. Set your own target, and note that it is the axis the facilitator menu's efficiency line deliberately does not rest on.
Post-session material use (self-set): traffic to the published material inside the window you announced. It is also the honest test of the no live hands-on rung - if the material carries the learning on its own, the room was optional.
Sell-through of a separately ticketed workshop day belongs to
```
samber/dev-event-organizer-skills@event-format-selection
```
, not here.

选两到三个。提前决定什么样的结果会改变下一届，并在环节前把指标和那个触发条件写下来。

第零分钟就绪（自设）：到达前完成前置条件的人占房间的比例。这个数字告诉你是否要把前置条件菜单往上提，而获得它的唯一方法是在门口问。
信心，前后对比（有出处的惯例）：针对所教授的特定技能，问一个简短的“我对……的能力有信心”评分，在环节开始前和结束时各问一次。这是这里唯一一个有具名先例的指标。Carpentries 在上千个动手技术技能工作坊中运行了完全相同的成对调查，并报告同一任务上、前后之间自信的受访者比例大约从三分之一摆动到三分之二。这个先例来自生命科学和数据科学培训，而不是开发者大会，而且它测量的是自我报告的信心，不是观察到的任务完成。借用这个惯例，不要照搬数字。
开始与完成对比（自设）：有多少参与者做到了最后一个练习。房间满但差距大，指向覆盖问题；房间小但差距大，指向前置条件。
求助延迟（自设）：举手后要等多久。设定你自己的目标，并注意这正是 facilitator 菜单的效率线刻意不依赖的轴。
环节后材料使用（自设）：在你公布的窗口内，已发布材料的流量。它也是对 no live hands-on 档位的诚实检验——如果材料能独立承载学习，那么房间就是可选的。
单独售票工作坊日的售卖率属于
```
samber/dev-event-organizer-skills@event-format-selection
```
，不属于这里。

Invocation examples

调用示例

"We have a three-hour Kubernetes workshop for 40 people. How many helpers, and what do we ask attendees to install?"
"Last year's workshop day fell apart because the venue WiFi died during the setup step. Fix it for this year."
"Should we run this as hands-on, or just record the demo and publish the repo?"
"Write the prerequisites section for our LLM workshop - the exercise needs a cloud console and a vendor account."

Expected output: a per-session delivery sheet carrying:

the hands-on commitment, with the reason;
the capacity number, and which of the three ceilings bound it;
the facilitator coverage, with the basis of its sizing stated;
the prerequisites, split into knowledge, machine state and accounts;
the network posture, with what the venue answered;
the materials, and the window they stay available;
the trigger that would revise each choice next edition.

Present it section by section for validation, not as one block.

If your harness has persistent memory, record the capacity that bound and which ceiling bound it, the prerequisite sheet as shipped, what actually broke on the day, and the venue's written network answer. Next edition starts from that instead of re-deriving it.

“我们要为一个 40 人的 Kubernetes 工作坊安排三小时。需要多少助教，我们要让参会者安装什么？”
“去年的工作坊日因为场地 WiFi 在安装步骤时挂掉而崩溃。今年把它修好。”
“我们应该把它做成动手实操，还是只录演示并发布 repo？”
“为我们的 LLM 工作坊写前置条件部分——练习需要一个云控制台和一个厂商账号。”

预期输出：一张按环节交付表，包含：

动手实操承诺，以及理由；
容量数字，以及三个上限中哪一个约束住了它；
facilitator 覆盖，以及其规模设定的依据；
前置条件，分为知识、机器状态和账号；
网络姿态，以及场地的答复；
材料，以及它们保持可用的窗口；
会在下一届修订每个选择的触发条件。

分段呈现以便验证，而不是作为一整块。

如果你的 harness 有持久记忆，记录住约束住的容量和哪个上限、实际发出的前置条件清单、当天真正坏掉的东西，以及场地书面的网络答复。下一届从这些出发，而不是重新推导。

References

参考

references/coverage-and-room-mechanics.md - the four coverage rungs written out, in-room and after-the-workshop mechanics with a negative example, the mentor-model contrast.
references/prerequisite-and-environment-sheet.md - the prerequisite artifact: three content classes, the provisioned-environment and both-paths rungs, materials and their access windows, the compliance review triggers, plus a filled example and a negative one.
references/capacity-length-and-network-evidence.md - the three ceilings, the demand-vote room-assignment mechanic, published session lengths with their events, the density ratios with their caveats, and the named live-failure causes.