event-schedule-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Event Schedule Design

活动日程设计

You lay already-selected sessions into a physical grid: which talk runs at which time, in which room, with what between them. Your inputs arrive decided, fixed by these sources:

Track count, event shape, session-format mix, delivery mode -
```
samber/dev-event-organizer-skills@event-format-selection
```
, which states the split from its own side: "You do not build the schedule - grid layout, clash avoidance, and room-capacity matching belong to
```
samber/dev-event-organizer-skills@event-schedule-design
```
. Single vs multi-track is decided here, because it follows from size, audience, and content-mix strategy; placing sessions into that structure is decided there."

Accepted talks, with format and track tags -

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

Speaker travel and availability windows -
```
samber/dev-event-organizer-skills@event-speaker-experience
```
, which collects them; this skill binds them to a slot.

You stop at the published grid. How staff execute it minute by minute on the day, and how they respond live to a no-show or an AV failure, is

samber/dev-event-organizer-skills@event-run-of-show

Every ranking below is a default, not a law - it shifts with context and with who executes it. After the interview, re-rank all three menus against what you know about this event:

A venue whose rooms open onto one narrow corridor.
A scheduling tool already in use that computes clashes for free.
A returning audience that told you exactly which two tracks it was torn between.
A hard publication date.

Each of these can overturn a default rung.

你将已选定的分会场放入一个物理网格中：哪个演讲在什么时间、在哪个房间、房间之间有什么间隔。你的输入已经由以下来源决定并固定：

轨道数、活动形态、会议形式组合、交付模式 ——
```
samber/dev-event-organizer-skills@event-format-selection
```
，它从自己的角度说明了分工：“你不负责构建日程——网格布局、冲突避免和房间容量匹配属于
```
samber/dev-event-organizer-skills@event-schedule-design
```
。单轨 vs 多轨在这里决定，因为它取决于规模、受众和内容组合策略；将分会场放入该结构则在那边决定。”

已接受的演讲，含形式和轨道标签 ——

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

。

讲者的出行与可用时间窗口 ——
```
samber/dev-event-organizer-skills@event-speaker-experience
```
负责收集；本 skill 将其绑定到某个时段。

你止步于已发布的网格。工作人员当天如何逐分钟执行它，以及如何实时应对缺席或 AV 故障，属于

samber/dev-event-organizer-skills@event-run-of-show

。

下面的每个排序都是默认值，而非铁律——它会随上下文和执行者而改变。访谈之后，根据你对这次活动了解的情况，重新对所有三个菜单排序：

一个房间都通向同一条狭窄走廊的场地。
已经在使用、可免费计算冲突的日程工具。
返场观众明确告诉你他们在哪两个轨道之间纠结。
一个不可更改的发布日期。

其中任何一点都可能推翻默认档位。

Interview

访谈

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

How many rooms run simultaneously, and how many sessions are you placing across how many days? (This is the split that changes everything below - see the next section.)
What are the rooms: names, seated capacity, and how far apart they are in walking minutes? A grid built without capacities is a seating plan you will discover on the day.
What did the venue contract fix - doors open and close, catering windows, room-hire start and end times, any room you only hold for part of the day?
When must the schedule be public, and what is that date serving: ticket sales, travel booking, or a sponsor commitment?
Is this a one-off edition or a compounding annual asset? (A compounding mandate promotes the slow rungs: recorded room-turnover times, a versioned public grid, a survey question that tells you next year which clashes hurt.)
What is the effort ceiling - who actually builds and maintains this grid, in how many hours, and who arbitrates when two sessions want the same slot?
Do you have every speaker's availability window, and for multi-speaker sessions, all co-speakers' windows? If not, get them before laying anything (see the workflow).
Which sessions are fixed points rather than free pieces: keynotes, an opening, a closing, a sponsor slot, a session a speaker can only give on one day?
What already exists that should re-rank the menus: last edition's grid and its complaints, recorded overruns, a scheduling tool with clash detection, a known corridor bottleneck, an attendee survey naming the clashes that hurt?
What has to physically change between two consecutive sessions in each room - AV reset, furniture, staging?

一次只问一个问题，在可能的情况下给出多项选择。问题 4-6 之所以存在，是因为下面的菜单在见效时间、持久性和付出上分歧很大——这些排序不能替用户决定。

多少个房间同时运行？你要在多少天内安排多少个分会场？(这是改变下面所有东西的分水岭——见下一节。)
房间情况：名称、座位容量以及彼此之间步行多少分钟？没有容量数据构建的网格，只会在当天变成你才知道的座位方案。
场地合同固定了什么——开门和关门时间、餐饮窗口、房间租用起止时间、是否有只在你持有部分时段使用的房间？
日程必须在何时公开？这个日期服务于：售票、旅行预订，还是赞助商承诺？
这是一次性活动，还是一项会逐年累积的年度资产？(累积型任务会提升较慢的档位：记录房间周转时间、带版本的公开网格、告诉你明年哪些冲突会伤人的调查问题。)
投入上限是什么——谁实际构建和维护这个网格，多少小时，当两个分会场想占同一个时段时由谁仲裁？
你是否拥有每位讲者的可用时间窗口？对于多讲者分会场，是否拥有所有共同讲者的窗口？如果没有，在布置任何内容之前先拿到它们(见工作流)。
哪些分会场是固定点而不是自由块：主旨演讲、开场、闭幕、赞助商时段、讲者只能在某一天给出的演讲？
已经存在哪些应该重新排序菜单的东西：上一版的网格及其投诉、记录在案的超时、带冲突检测的日程工具、已知的走廊瓶颈、点名了哪些冲突会伤人的参会者调查？
每个房间内两个连续分会场之间需要实际改变什么——AV 重置、家具、舞台布置？

Single-track vs multi-track

单轨 vs 多轨

Neither does this collection's usual community-run versus vendor-run split: a developer walks a corridor at the same speed whichever kind of event they paid for. Who owns the event changes which content gets picked, not how a room empties.

What genuinely changes the work is whether more than one session ever runs at once:

Single track - there is no clash problem in the sense the tools mean it: nothing overlaps, so clash detection collapses to a single question, whether the speaker is in the building. Room-capacity matching does not exist either; everyone is in the one room or the event is oversold. The entire design load moves onto pacing, break placement and buffer, and one overrun propagates to the whole day rather than to one track.
Multi track - all four clash types apply, room-capacity matching becomes a real allocation problem, corridor throughput becomes a design constraint rather than an afterthought, and the plenary moments that are free in a single-track day now have to be deliberately re-created.
Ceiling scale - dozens of rooms. FOSDEM 2026 published 1,079 events across 37 rooms and 71 tracks, and publishes a separate "room occupation by track" overview alongside the grid: at that scale the grid stops being one document and room-to-track mapping becomes its own artifact. Read it as a benchmark ceiling, not a target.

Say which pole a recommendation assumes when they differ.

这个合集通常的“社区运营 vs 厂商运营”之分在这里并不适用：无论开发者参加的是哪种活动，他们走过走廊的速度是一样的。谁拥有活动改变的是选择哪些内容，而不是房间如何清空。

真正改变工作形态的是是否有多个分会场同时运行：

单轨——不存在工具意义上的冲突问题：没有重叠，所以冲突检测坍缩成一个问题：讲者是否已到场。房间容量匹配也不存在；要么大家都在一个房间，要么活动超额售票。整个设计负荷转移到节奏、休息安排和缓冲上，一次超时会传播到全天，而不是单个轨道。
多轨——四种冲突类型全部适用，房间容量匹配变成真正的分配问题，走廊吞吐量成为设计约束而非事后才想的事情，单轨日中免费的全体环节现在必须有意识地重新创造。
极限规模——几十个房间。FOSDEM 2026 在 37 个房间和 71 个轨道上发布了 1,079 场活动，并在网格之外单独发布“按轨道的房间占用”概览：在这个规模下，网格不再是单个文档，房间到轨道的映射本身成为一份产物。把它当作基准上限，而不是目标。

当推荐在不同情况下有分歧时，说明它假设的是哪一端。

Workflow

工作流

Run the interview. Get the room list with capacities and walking distances (Q2) and the venue's fixed windows (Q3) before touching a grid - both delete options rather than adjusting them.
Collect every speaker's availability window, and the co-speaker windows for multi-speaker sessions, before laying anything. Collecting it upfront on the submission form is the sourced practice: availability is gathered at proposal time through a calendar widget. If your form did not ask, ask now and wait; discovering an availability conflict after publication costs a public correction. The form-depth decision this field belongs in is
```
samber/dev-event-organizer-skills@event-cfp-design
```
's.
Standardize session lengths (see below) so slots are interchangeable. Do this before assigning anything - a grid of bespoke durations cannot be re-sequenced when one piece moves.
Place the fixed points first (Q8): opening, keynotes, closing, and any session with a single possible day. Everything else fills around them.
Place lunch and breaks next, not last. In a multi-track day they double as plenary re-sync points that reset accumulated per-track drift. PyCon US runs keynotes 9:00-9:45 in one dedicated large room, mid-morning break around 10:30, lunch around 12:30-1:15, mid-afternoon break around 4:00.
Match sessions to rooms on expected audience size, not on track tidiness (see below).
Lay the remaining sessions into the grid. Where several accepted talks compete for one prime slot, place the hardest-constrained first - the speaker with one available day goes before the speaker who is free all week (borrowed from earliest-due-date job-shop dispatching; a structuring analogy, not a rule to apply mechanically).
Choose the track-start alignment (see below) and apply it consistently.
Run clash detection at the depth the menu picks. Re-run it after every subsequent change, not once at the end.
Set the buffer from its menu and check it against the walking distances from Q2.
Read the whole day for pacing, and label that read for what it is (see Energy-curve pacing).
Write the disruption priority order into the grid document and hand it to
```
samber/dev-event-organizer-skills@event-run-of-show
```
.
Publish at the posture the menu picks, then treat the grid as a living document rather than a final artifact.

Present the grid section by section for validation - fixed points, breaks, room assignments, then the full grid - before it goes public. Once a schedule is published, every change costs an attendee who planned around the old one.

If your harness has persistent memory, record:

The session-length standard.
The buffer figure and why it was chosen.
The room-capacity assumptions that turned out wrong.
The clashes attendees reported.
The walking-distance facts about this venue.

A venue you use twice is worth not re-measuring.

先运行访谈。在触碰网格之前，取得带容量和步行距离的房间清单(Q2)以及场地的固定时间窗口(Q3)——两者删除选项，而不是调整选项。
在布置任何内容之前，收集每位讲者的可用时间窗口，以及多讲者分会场的共同讲者窗口。在提交流程中提前收集是有据可循的做法：可用性在提案时通过日历组件收集。如果你的表单没有询问，现在就问并等待；发布后发现可用性冲突，代价是公开更正。这个字段所属的表单深度决策由
```
samber/dev-event-organizer-skills@event-cfp-design
```
负责。
标准化分会场时长(见下文)，让时段可以互换。在任何分配之前完成——一个由定制时长组成的网格，在某个块移动时无法重新排序。
先放置固定点(Q8)：开场、主旨演讲、闭幕，以及任何只有一个可能日期的分会场。其他一切围绕它们填充。
接下来放置午餐和休息，而不是最后。在多轨日中，它们兼作重新同步点，重置每个轨道累积的漂移。PyCon US 在 9:00-9:45 在一个专用大房间举行主旨演讲，上午中段休息约 10:30，午餐约 12:30-1:15，下午中段休息约 4:00。
按预期观众规模而不是轨道整洁度将分会场匹配到房间(见下文)。
将剩余分会场放入网格。当几个已接受的演讲竞争一个黄金时段时，先放约束最紧的——只有一天可用的讲者先于整周空闲的讲者(借用最早截止日期车间调度；这是一个结构类比，不是机械套用的规则)。
选择轨道开始对齐方式(见下文)并一致地应用。
按菜单选择的深度运行冲突检测。在随后的每次更改后重跑，而不仅在最后跑一次。
从其菜单设置缓冲，并对照 Q2 的步行距离检查。
通读全天以检查节奏，并如实标记该判断(见能量曲线节奏)。
将扰动优先级顺序写入网格文档，交给
```
samber/dev-event-organizer-skills@event-run-of-show
```
。
按菜单选择的姿态发布，然后把网格视为活文档，而非最终产物。

在公开之前，逐节呈现网格以供验证——固定点、休息、房间分配，然后是完整网格。日程一旦发布，每次更改都会让按旧日程规划的参会者付出代价。

如果你的运行框架有持久记忆，请记录：

分会场时长标准。
缓冲数值及其选择原因。
结果证明错误的房间容量假设。
参会者报告的冲突。
该场地的步行距离事实。

一个你用过两次的场地，值得不再去测量。

Session-length standardization

分会场时长标准化

Pick a small set of slot lengths and make every session fit one. Two sourced points, at different scales: FOSDEM runs ~50-minute talks with lightning talks capped at 15 minutes, and PyCon US runs 45-minute talks. Both standardize; neither offers a menu of bespoke durations.

Standardize the slot, not the talk. A 30-minute slot holding a 25-minute talk carries its own turnover time inside the number you publish, which is why the default buffer rung below costs nothing extra to compute. Say the talk length and the slot length separately in the speaker brief, or speakers will use the slot.

挑选一小组时间段长度，让每个分会场都符合其中一个。两个有据可查的例子，规模不同：FOSDEM 采用约 50 分钟的演讲，闪电演讲上限 15 分钟；PyCon US 采用 45 分钟演讲。两者都标准化；都没有提供定制时长菜单。

标准化的是_时段_，而不是演讲。一个 30 分钟时段容纳 25 分钟演讲，其自身的周转时间包含在你发布的数字里，这就是为什么下面默认的缓冲档位计算不需要额外成本。在讲者简报中分别说明演讲时长和时段时长，否则讲者会用满整个时段。

Room and capacity matching

房间与容量匹配

Match rooms to sessions in this order:

Expected audience size.
Room adjacency.

Never match on which track feels like it deserves the big room. The failure this prevents is one-directional and public: a session that draws more people than its room seats turns away attendees at the door, while a session in an over-large room merely looks quiet.

Estimate expected size from whatever you actually have:

Last edition's per-session counts.
The topic's draw in your community.
A speaker with a following.
The track's share of the CFP.

Every estimate here is yours rather than a benchmark, so present it as such. Where a session could plausibly overflow, either give it the larger room or place it opposite something else that draws well, so the audience splits rather than concentrates.

At many-room scale, keep the room-to-track mapping as its own artifact rather than reading it off the grid - that is what FOSDEM's separate room-occupation overview does.

Two further placement moves cost little against a multi-track grid's continuity and its fairness, both self-set rather than published practice:

Group adjacent slots by topic where the content allows it, so an attendee can stay in one room across two consecutive sessions instead of a room change between every pair.
Where each track alternates between a larger and a smaller room across the day, swap which track holds which at the midpoint, so one track's audience does not sit in the lesser room for the whole day.

按以下顺序将房间匹配到分会场：

预期观众规模。
房间邻近性。

永远不要因为某个轨道“感觉”配得上大房间而匹配。这防止的失败是单向且公开的：一个吸引的人数超过座位数的分会场会把参会者挡在门口，而一个房间里坐不满仅仅看起来冷清。

根据你实际掌握的信息估算预期规模：

上一版每个分会场的人数。
该主题在你社区中的吸引力。
有粉丝的讲者。
该轨道在 CFP 中的占比。

这里的每个估算都是你自己的，而非基准，所以要如实呈现。对于可能超员的演讲，要么给更大的房间，要么把它排在与另一个热门演讲对打的位置，让观众分流而不是集中。

在多个房间的规模下，把房间到轨道的映射作为独立产物保留，而不是从网格中读出来——这正是 FOSDEM 单独的“房间占用”概览所做的。

两个额外的排布手段对多轨网格的连续性和公平性代价很小，都是自己设定而非公开实践：

在内容允许的情况下，按主题将相邻时段分组，让参会者可以在两个连续分会场中留在同一个房间，而不必每对之间换房间。
当每个轨道全天在较大和较小房间之间交替时，在中点交换哪个轨道使用哪个，以免某个轨道的观众一整天都坐在较小的房间。

Clash detection depth

冲突检测深度

A real scheduling tool models this as four distinct conflict types rather than one generic flag:

A session outside its room's availability window.
A session conflicting with a speaker's stated unavailability.
Two sessions overlapping in the same room.
One speaker double-booked across simultaneous sessions.

For multi-speaker sessions the valid window is the intersection of all co-speakers' availabilities - a session cannot sit where even one co-speaker is unavailable. None of this requires that tool, or any tool: the four types are what a grid has to represent, and a spreadsheet holds all of them.

Ranking (default, not a law - Q1, Q6 and Q9 re-rank it):

effort (new data you must collect, passes over the grid, judgment required):
```
audience-overlap pass > availability-window checking > speaker double-booking == same-room overlap
```
- the tie is argued, not a dodge: both are pure arithmetic over data the grid already contains, need no new collection and no judgment call, and cost one pass whether you run one or both.
value, sessions that can physically happen as published:
```
availability-window checking > speaker double-booking == same-room overlap > audience-overlap pass
```
. Availability leads because it fails silently - nothing on the grid looks wrong while the speaker is on a plane.
value, a program the audience is glad about:
```
audience-overlap pass > availability-window checking > speaker double-booking == same-room overlap
```
. This axis is why the starved rung exists; the three mechanical checks buy a schedule that runs, not a schedule anyone enjoyed.

efficiency:

same-room overlap == speaker double-booking > availability-window checking > audience-overlap pass

Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass. Three mechanisms block the six:

The audience-overlap pass against each of the other three is blocked by opposed value axes - it tops program quality and bottoms will-it-run.
Availability checking against each of the two arithmetic checks is blocked by effort alone: availability leads on both value axes and still costs more.
The last pair, same-room overlap against speaker double-booking, is blocked because the two rungs are tied on every axis, so nothing about either is strict.

None of the three reasons is evidence; the efficiency line rests on the arguments below.

The three mechanical checks - the default, run as one pass: same-room overlap, speaker double-booking, and both availability windows with the multi-speaker intersection. Together they are the whole of what a tool automates, and they are cheap enough that running fewer than all three is never the right economy.
Audience-overlap pass - the starved option: two sessions a shared audience would both want, scheduled head to head. Nothing computes this; it needs someone who knows the community reading the grid and naming the pairs. It tops the program-quality axis and tops effort, so efficiency never picks it.
- Promotion conditions: two tracks that visibly share an audience, a track added specifically to reduce head-to-head competition, or a returning audience that already told you which clash hurt last edition.
Delete, do not demote: on a single-track event, drop the overlap and double-booking checks and the audience-overlap pass entirely - nothing runs at once, so the only live check is speaker availability. A multi-track checklist parked at the bottom of a single-track plan is how a second track quietly reappears as scope.

真实的日程工具将冲突建模为四种不同类型的冲突，而不是一个通用标志：

分会场在其房间可用时间窗口之外。
分会场与讲者声明的不可用时间冲突。
两个分会场在同一个房间重叠。
同一位讲者在同时段的分会场中被重复预订。

对于多讲者分会场，有效窗口是所有共同讲者可用时间的_交集_——即使只有一位共同讲者不可用，分会场也不能放在那里。这些都不需要该工具或任何工具：网格必须表示的是这四种类型，而电子表格就能容纳全部。

排序(默认，非铁律——Q1、Q6 和 Q9 会重新排序)：

付出(必须收集的新数据、对网格的遍历次数、所需判断)：
```
audience-overlap pass > availability-window checking > speaker double-booking == same-room overlap
```
——这个平局是有论证的，不是回避：两者都是对网格已有数据的纯算术，不需要新收集、不需要判断，无论跑一个还是两个都只是一次遍历。
价值，能按发布实际发生的分会场：
```
availability-window checking > speaker double-booking == same-room overlap > audience-overlap pass
```
。可用性领先是因为它无声地失败——讲者还在飞机上时，网格上看起来没有任何问题。
价值，一个观众感到满意的节目：
```
audience-overlap pass > availability-window checking > speaker double-booking == same-room overlap
```
。这个轴正是“饥饿档位”存在的原因；三个机械检查买到的是一个能运行的日程，而不是一个任何人喜欢的日程。

效率：

same-room overlap == speaker double-booking > availability-window checking > audience-overlap pass

支配性检查：4 个档位、6 对组合、零严格支配关系——只是由于构造才干净，而“由于构造”从来不是过关。 三个机制阻断了这六对：

audience-overlap pass 对另外三个的每一对都被相反的价值轴阻断——它在节目质量上最高，而在“能否运行”上垫底。
availability checking 对两个算术检查的每一对都被付出单独阻断：可用性在_两个_价值轴上都领先，却仍然更贵。
最后一对，same-room overlap 对 speaker double-booking，被阻断是因为两个档位在每个轴上都平局，所以两者都没有严格之处。

这三个理由中没有一个是证据；效率这一行依赖于下面的论证。

三个机械检查 —— 默认选项，作为一次遍历运行：same-room overlap、speaker double-booking，以及带多讲者交集的两个可用性窗口。它们合起来是工具自动化的全部，而且便宜到少于三者从来不是正确的节省。
Audience-overlap pass —— 被饥饿的选项：两个共享观众都想去的分会场被排在对打位置。没有东西能计算这个；需要某个了解社区的人阅读网格并指出这些配对。它在节目质量轴上最高，在付出上也最高，所以效率永远不会选它。
- 提升条件：两个明显共享受众的轨道、一个专门为了减少对打竞争而增加的轨道，或者一个已经告诉你上一版哪些冲突会伤人的返场观众。
删除，而不是降级： 在单轨活动中，完全去掉 overlap 和 double-booking 检查以及 audience-overlap pass——没有东西同时运行，所以唯一活跃的检查是讲者可用性。一个被放在单轨计划底部的多轨检查清单，就是第二条轨道悄悄以范围扩张的方式重新出现的方式。

Buffer between sessions

分会场之间的缓冲

Ranking (default, not a law - Q2, Q5 and Q9 re-rank it):

effort (grid arithmetic, per-room bookkeeping, day-length consumed):
```
room-turnover-aware > proportional > fixed inter-slot gap == slot-internal buffer
```
- argued tie: both publish one number that holds for the whole grid and take one decision to set; whether the buffer sits inside or between slots changes what attendees read, not what you compute.
value, sessions that start when they say they will:
```
room-turnover-aware > proportional > fixed inter-slot gap == slot-internal buffer
```
- the same tie holds for the same reason, since the minutes absorbed are identical either way.
value, hallway-track time attendees can actually plan into:
```
fixed inter-slot gap > room-turnover-aware > proportional > slot-internal buffer
```
. A published gap is visible time someone can spend on a corridor conversation; a buffer hidden inside a slot reads as dead air and gets spent by an overrunning speaker instead.

efficiency:

slot-internal buffer > fixed inter-slot gap > proportional > room-turnover-aware

Slot-internal buffer - the default: publish slots longer than the talks they hold and brief speakers on both numbers. Near-zero cost, because the buffer lives inside a figure you were publishing anyway.
Fixed inter-slot gap - one published gap between slots, the same everywhere. FOSDEM's visible gap between its 09:30-09:50 opening keynote and the 10:00-10:50 slot that follows is 10 minutes, across a venue spanning 37 rooms. Cite that as a real density-versus-buffer trade-off at ceiling scale, not as a recommended figure - 10 minutes is tight for that footprint, and it is what buys the 1,079-event count.
Proportional gap - size the buffer as a share of the preceding session's length rather than a flat number, and read buffer consumption as a graded signal (comfortable, tightening, blown) rather than a binary on-time/late. This pattern comes from manufacturing production scheduling. Take the pattern, not manufacturing's specific percentages - its 50% sizing and 33/67% zone boundaries come from a different domain and do not transfer.
Room-turnover-aware gap - the starved option: gaps sized per room-pair to what physically changes between two consecutive sessions in that room - AV reset, a workshop's tables going back to theatre rows, a panel's chairs coming on. This pattern comes from manufacturing production scheduling's changeover sequencing, and tops both on-time value and effort because it is per-pair bookkeeping.
- Promotion conditions, keyed to Q10: one room hosting mixed formats, a venue whose AV needs a real reset between sessions, or a compounding mandate where you record actual turnover times once and reuse them every edition.
- Its cheap companion is free: sequence same-format sessions together within a room so there is less to change.
Delete, do not demote: a zero-gap grid, whenever rooms are on different floors or more than a couple of minutes' walk apart. A schedule that assumes teleportation is corrected all day by attendees arriving late, and leaving it on the menu invites it back when the day looks too long.

排序(默认，非铁律——Q2、Q5 和 Q9 会重新排序)：

付出(网格算术、按房间记账、消耗的白天长度)：
```
room-turnover-aware > proportional > fixed inter-slot gap == slot-internal buffer
```
——有论证的平局：两者都发布一个适用于整个网格的数字，并只需做一个设置决策；缓冲是位于时段内部还是时段之间，改变的是参会者读到的东西，而不是你计算的东西。
价值，能按宣称时间开始的分会场：
```
room-turnover-aware > proportional > fixed inter-slot gap == slot-internal buffer
```
——同样的平局以同样的理由成立，因为无论哪种方式吸收掉的分钟数相同。
价值，参会者实际可以规划进去的走廊时间：
```
fixed inter-slot gap > room-turnover-aware > proportional > slot-internal buffer
```
。一个已发布的间隔是可见时间，有人可以用它进行走廊对话；隐藏在时段内部的缓冲读起来像死空气，会被超时的讲者消耗掉。

效率：

slot-internal buffer > fixed inter-slot gap > proportional > room-turnover-aware

Slot-internal buffer —— 默认选项：发布比演讲实际时长更长的时段，并让讲者了解两个数字。成本接近零，因为缓冲位于你无论如何都会发布的数字内部。
Fixed inter-slot gap —— 时段之间一个已发布的间隔，处处相同。FOSDEM 在 09:30-09:50 的开场主旨演讲和其后的 10:00-10:50 时段之间有 10 分钟的可见间隔，而场地横跨 37 个房间。把它作为极限规模下密度与缓冲之间的真实权衡来引用，而不是推荐数值——10 分钟对那种场地规模来说很紧，而正是它换来了 1,079 场活动的总数。
Proportional gap —— 将缓冲设置为前一分会场时长的一个比例，而不是固定数字，并将缓冲消耗读作分级信号(舒适、收紧、爆掉)，而不是非准时即迟到的二元。这种模式来自制造业生产排程。取模式，不要取制造业的具体百分比——它的 50% 规模和 33/67% 区间边界来自另一个领域，不能迁移。
Room-turnover-aware gap —— 被饥饿的选项：按每对房间来设置间隔，取决于该房间两个连续分会场之间实际需要改变什么——AV 重置、工作坊的桌子恢复成剧场排布、小组讨论的椅子搬上台。这种模式来自制造业生产排程的换型排序，并在准时价值和付出上都最高，因为它是逐对记账。
- 提升条件，对应 Q10：一个房间承载混合形式、场地 AV 需要在分会场之间真正重置，或一个累积型任务，你只记录一次实际周转时间并在每一届复用。
- 它便宜的搭档是免费的：在同一房间内将相同形式的分会场排在一起，这样需要改变的东西更少。
删除，而不是降级： 零间隔网格，只要房间位于不同楼层或步行相距超过几分钟。一个假设瞬移的日程需要参会者整天迟到来纠正，而把它留在菜单上，当天看起来太长时就会被再次采用。

Track-start alignment

轨道开始对齐

No ranking here, deliberately. Synchronized and staggered starts cost the same to decide and the same to apply - one call, one pass over the grid - so an efficiency ordering between them would be false precision. The choice is determined by the venue, not by the ratio:

Stagger when simultaneous room changes would jam a corridor. PyCon US 2026 runs staggered starts across five main rooms - observed starts at 11:00, 11:45, 12:30, 1:45, 2:45, 3:30 and 4:30 - so that when one track ends another is mid-session and foot traffic spreads instead of concentrating. Staggering costs you the clean "everything starts on the hour" rule and makes the clash pass fiddlier to read.
Synchronize when the room count is small enough that everyone moving at once still clears, or when you want the whole audience arriving at plenary moments together.

Either way, keep the plenary sync points: a keynote or lunch that pulls every track into one room also resets whatever drift each track accumulated before the next block starts. PyCon US and FOSDEM both bookend their grids this way, with plenary moments at open and close.

这里刻意不排序。同步开始和错峰开始的决定成本和实施成本相同——一次决策、对网格的一次遍历——所以对它们做效率排序是虚假的精确。选择由场地决定，而不是由比例决定：

错峰，当同时换房间会堵塞走廊时。PyCon US 2026 在五个主房间运行错峰开始——观测到的开始时间为 11:00、11:45、12:30、1:45、2:45、3:30 和 4:30——这样当一个轨道结束时另一个正在会议中，人流分散而不是集中。错峰让你失去干净的“整点开始”规则，也让冲突遍历更难读。
同步，当房间数量小到所有人同时移动也能清空，或者当你希望整个观众在全体时刻一起到达时。

无论哪种方式，保留全体同步点：一个把每个轨道都拉进同一个房间的主旨演讲或午餐，也会在每个下一个块开始前重置各轨道累积的漂移。PyCon US 和 FOSDEM 都用这种方式在网格两端放置全体时刻。

Energy-curve pacing

能量曲线节奏

Named organizers vary session format and density across the day rather than holding it constant, and graveyard slots (positions with a structurally high chance of low attendance) are a real, named problem, not just a manufacturing analogy relabeled (see

references/published-schedule-benchmarks.md

§ Energy-curve pacing and graveyard slots: named sources for the full source list):

DevOpsDays' own organizing guide runs structured talks in the morning, then short Ignite talks, then self-organized Open Space in the afternoon - a published format gradient from high structure to low structure.
The post-lunch alertness dip is circadian, documented independent of what attendees ate, which is the physiological basis for avoiding dense content right after lunch.
The last slot of the last day is, at the conferences studied, empirically the worst-attended and least-engaged position; a weekend day carries the same risk at whole-day scale.

Two concrete techniques these sources describe, beyond reading your own grid:

Format substitution over content substitution. DevOpsDays does not just avoid content after lunch; it swaps the format - lecture-style talks give way to self-organized Open Space, matching the slot to the audience's actual energy state instead of fighting it.
Track no-show rate per slot as a diagnostic (see Measurement below). Recording which slots underperform their expected turnout, slot by slot and edition over edition, turns "which slot is a graveyard here" from received wisdom into something you measure at your own event.

The heijunka (levelled production sequencing) analogy in

references/production-scheduling-concepts.md

still supplies the closest thing to a mechanism for why front-loading intensity helps: the sources above confirm its direction but say nothing about why, and the post-lunch dip they add is a second risk window the end-of-shift-crunch analogy misses entirely. State that a claim is sourced or judgment when you present the pacing read, and do not invent a number for either.

知名的组织者会在一天中改变会议形式和密度，而不是保持恒定；“墓地时段”(结构性高概率低出席率的位置)是一个真实的、有名字的问题，而不仅仅是重新贴标签的制造业类比(见

references/published-schedule-benchmarks.md

§ 能量曲线节奏和墓地时段：完整来源列表见命名来源)：

DevOpsDays 自己的组织指南在上午进行结构化演讲，然后进行简短的 Ignite 演讲，下午进行自组织的 Open Space——一个从高结构到低结构的已发布形式梯度。
午餐后警觉性下降是昼夜节律驱动的，已有记录且与参会者吃什么无关，这正是午餐后避免高密度内容的生理基础。
在所研究的会议中，最后一天的最后时段经验上是出席率最差、参与度最低的位置；周末全天也带有同样的风险。

这些来源描述了两个具体技术，超越只读你自己的网格：

用形式替换替代内容替换。 DevOpsDays 不只是避免午餐后的内容；它交换形式——讲座式演讲让位于自组织的 Open Space，把时段匹配到观众的实际能量状态，而不是与之对抗。
按时段的轨道未出席率作为诊断(见下面的测量)。记录哪些时段的出席率低于预期，一个时段一个时段、一届一届地记录，把“这里哪个时段是墓地”从经验之谈变成你在自己活动中测量出来的东西。

references/production-scheduling-concepts.md

中的 heijunka(平准化生产排序)类比仍然提供了最接近机制的解释，说明为什么前置加载强度有帮助：上面的来源确认了它的方向，但没有说明原因，而它们补充的午餐后低谷是另一个风险窗口，是“班末赶工”类比完全没有捕捉到的。在呈现节奏读法时，说明某个论断是有来源的还是判断，并且不要为任何一边编造数字。

Speaker constraints and disruption

讲者约束与扰动

Rooms and speakers each carry their own availability windows, and they are separate constraints: a room's booking window is not a speaker's calendar. At slot assignment:

Reconcile both.
Take the intersection for multi-speaker sessions.
Treat a travel window as an availability window - a speaker landing the morning of cannot open the day.

Design the grid so a disruption is survivable, and write the priority order into the document rather than leaving it to be invented under pressure (borrowed - disruption re-sequencing from manufacturing production scheduling; its communication and lock-duration figures belong to that domain and do not carry over):

Protect the plenary or keynote slot first.
Protect the headline commitment the audience showed up for next.
Minimize how many other sessions the fix disturbs.
Lock the revised grid for the remainder of the block instead of re-shuffling repeatedly as the day goes on.

Executing that order live on the day is

samber/dev-event-organizer-skills@event-run-of-show

, not this skill.

房间和讲者各有自己的可用时间窗口，它们是相互独立的约束：房间的预订窗口不是讲者的日历。在分配时段时：

同时协调两者。
对多讲者分会场取交集。
将出行窗口视为可用性窗口——当天早上才落地的讲者不能开场。

设计网格让扰动可生存，并把优先级顺序写进文档，而不是留到压力下临时发明(借用——来自制造业生产排程的扰动重排序；其沟通和锁定时长数字属于该领域，不迁移)：

先保护全体或主旨演讲时段。
接下来保护观众为之而来的头号承诺。
最小化修复所打扰的其他分会场数量。
在块的剩余时间内锁定修订后的网格，而不是随白天推进反复重新洗牌。

当天实时执行该顺序的是

samber/dev-event-organizer-skills@event-run-of-show

，而不是本 skill。

Publication posture

发布姿态

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

effort (maintenance after the first release, announcement coordination):

versioned release > release early and iterate > staged reveal > lock late

value, attendees who can book travel and plan a personal agenda:

versioned release > release early and iterate > staged reveal > lock late

value, announcement moments bought:
```
staged reveal > versioned release == release early and iterate > lock late
```
- argued tie: both put the whole grid out at once, so each buys exactly one moment; a changelog changes what a returning visitor sees, not how many times you get to announce.

efficiency:

release early and iterate > staged reveal > versioned release > lock late

Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations - clean only by construction, and that is not a pass. Two mechanisms block the six:

Effort alone blocks four: the rung ahead on planning value costs strictly more to maintain. That includes all three pairs against lock-late, which loses on value rather than winning anything for free, and the versioned-against-early pair, where versioning leads on planning value, ties on announcement moments, and still costs more.
Opposed value axes block the other two: early against staged reveal, and staged reveal against versioned.

The check catches nothing here.

Release early and iterate - the default, and the sourced guidance: "Don't wait for a perfect schedule before releasing – release early and iterate." It treats the published schedule as a living document revised in place, which is also the only posture honest about how often a grid moves.
Staged reveal - announce speakers and talks first, the grid later. Cheap, and it buys a second marketing beat; it just leaves travel planning waiting on the second one.
Versioned release - the starved option: publish early and carry a visible marker of what changed since, so someone who planned their day can see what moved. Highest planning value, highest effort because maintaining it is a standing job rather than a task. Promotion conditions: a multi-day multi-track grid people build personal agendas against, a change landing after tickets are sold, or a compounding annual event whose audience returns expecting the same reliability.
Delete, do not demote: lock-late publication whenever attendees travel to reach you. A grid published a fortnight out cannot inform a flight booked two months earlier, and keeping the option parked at the bottom is how a busy program chair takes it. It survives only for a same-city, meetup-scale event nobody buys a ticket to travel for.

排序(默认，非铁律——Q4、Q5 和 Q9 会重新排序)：

付出(首次发布后的维护、公告协调)：

versioned release > release early and iterate > staged reveal > lock late

价值，能预订旅行和规划个人议程的参会者：

versioned release > release early and iterate > staged reveal > lock late

价值，买到的公告时刻：
```
staged reveal > versioned release == release early and iterate > lock late
```
——有论证的平局：两者都会一次性放出整个网格，所以各买到恰好一个时刻；changelog 改变的是返场访客看到的东西，而不是你能公告多少次。

效率：

release early and iterate > staged reveal > versioned release > lock late

支配性检查：4 个档位、6 对组合、零严格支配关系——只是由于构造才干净，而那不是过关。 两个机制阻断了这六对：

仅付出就阻断了四对：在规划价值上领先的档位，维护成本严格更高。这包括所有三对对抗 lock-late 的组合——lock-late 是在价值上输，而不是免费赢到任何东西——以及 versioned 对抗 early 这对，其中 versioning 在规划价值上领先、在公告时刻上平局，却仍然更贵。
对立的价值轴阻断了另外两对：early 对 staged reveal，以及 staged reveal 对 versioned。

这个检查在这里什么都没抓住。

Release early and iterate —— 默认选项，也是有据可查的指导：“不要等到有一个完美日程才发布——尽早发布并迭代。”它把已发布日程视为就地修订的活文档，这也是唯一对网格移动频率诚实的姿态。
Staged reveal —— 先公布讲者和演讲，稍后公布网格。便宜，而且能买到第二个营销节奏；只是让旅行规划等第二个节奏。
Versioned release —— 被饥饿的选项：提前发布_并且_携带一个可见的变更标记，让计划好一天的人能看到什么变了。规划价值最高，付出也最高，因为维护它是持续职责而不是一次性任务。提升条件：人们会据此构建个人议程的多日多轨网格、门票售出后落地的变更，或者每年累积、观众返场时期待同样可靠性的年度活动。
删除，而不是降级： 只要参会者需要旅行来参加，就不要 lock-late 发布。提前两周发布的网格无法影响两个月前订好的航班，而把这个选项停在底部正是忙碌的节目主席会采用它的方式。它只在一个同城、meetup 规模、没有人会买票专门前往的活动里存活。

Failure modes

失败模式

Double-booking a multi-speaker talk. Each co-speaker's window was checked, the intersection was not. Compute the intersection explicitly; a session cannot sit where even one co-speaker is unavailable.
Capacity mismatch. A session estimated small, placed in a small room, and an overflow crowd turned away at the door. Estimate before assigning, and put anything that could plausibly overflow in the larger room - an over-large room only looks quiet.
Synchronized starts jamming the corridor. Every room emptying at once into a venue that cannot absorb it. PyCon US's staggering is the sourced counter; it costs the clean on-the-hour rule and buys back the hallway.
No buffer for room turnover. A grid whose gaps assume nothing physical happens between two sessions, in a room where the format changes. Turnover is real and session-pair-dependent.
Treating a borrowed heuristic as an events fact, or a sourced finding as universally transferable. The heijunka analogy is manufacturing, not events, and stays labelled as such. The graveyard-slot and post-lunch-dip sources are real events- and physiology-specific findings, but their measured magnitudes come from economics-conference and lab data, not developer conferences - cite the direction, not the number, unless you have your own.
Re-litigating the track count in the grid. A grid that will not fit is not a signal to add a track -
```
samber/dev-event-organizer-skills@event-format-selection
```
owns that decision and already made it, and adding a track mid-build silently changes the content mix it was coupled to.
Clash detection run once. Every move invalidates the previous pass. Re-run after each change, including the ones made after publication.

重复预订多讲者演讲。 每个共同讲者的窗口都检查了，但交集没有。显式计算交集；只要有一位共同讲者不可用，会话就不能放在那里。
容量不匹配。 一个会话被低估、放进小房间，超员人群被挡在门口。在分配之前估算，并把任何可能超员的内容放进更大的房间——过大的房间只是看起来安静。
同步开始堵塞走廊。 每个房间同时清空到无法吸收的场地里。PyCon US 的错峰是有据可查的反例；它牺牲了干净的整点规则，买回了走廊。
没有房间周转缓冲。 一个网格的间隔假设两个分会场之间没有物理变化发生，而房间的形式却变了。周转是真实的，且取决于分会场对。
把借来的启发式当成活动事实，或把有来源的发现当作普遍可迁移。 heijunka 类比是制造业的，不是活动的，并应保持这样标记。墓地时段和午餐后低谷的来源是真实的活动与生理学特定发现，但它们的测量幅度来自经济学会议和实验室数据，而不是开发者大会——引用方向，不要引用数字，除非你有自己的。
在网格中重新争论轨道数量。 一个放不下的网格不是增加轨道的信号——
```
samber/dev-event-organizer-skills@event-format-selection
```
拥有那个决定并且已经做了，在构建中途加轨道会静默改变与之耦合的内容组合。
冲突检测只跑一次。 每一次移动都会使前一次遍历失效。在每次更改后重跑，包括发布之后做的更改。

Measurement

测量

Every threshold here is one you set rather than a benchmark to hit. Say so when you present them.

On-time start rate per room (self-set): the share of sessions that began within the buffer. A room that drifts all day is a buffer-sizing problem, not a speaker problem.
Buffer consumption, graded (self-set thresholds; the graded framing is borrowed from production buffer management): how much of each buffer was actually eaten, read as comfortable / tightening / blown rather than on-time / late.
Room-fit outcomes (self-set): sessions that overflowed and sessions that ran near-empty, both counted. The first is a public failure, the second is wasted capacity, and the ratio tells you how to estimate next edition.
Post-publication change count and last-change date (self-set): how much moved after the grid went public, and how late. This is what decides whether the versioned-release rung is worth its cost next time.
Reported clashes (self-set): a post-event survey question asking which two sessions attendees were torn between. It is the only measurement that reaches the audience-overlap rung the efficiency ordering starves.
No-show rate per slot (a technique named in event-scheduling guidance, tracked by you): the share of expected attendees who did not show, recorded by slot position rather than by session. A slot that underperforms across multiple sessions and editions is a graveyard slot at your venue, whatever a published source says about slots in general (see Energy-curve pacing above).

Pick two or three, write down the revision each would trigger, and record them before the event rather than after.

这里的每个阈值都是由你设定，而不是要达成的基准。呈现时要说明这一点。

每个房间的准时开始率(自设)：在缓冲内开始的分会场比例。一个整天漂移的房间是缓冲设置问题，而不是讲者问题。
缓冲消耗，分级(自设阈值；分级框架借自生产缓冲管理)：每个缓冲实际被吃掉多少，读作舒适 / 收紧 / 爆掉，而不是准时 / 迟到。
房间匹配结果(自设)：超员的会话和近乎空场的会话都计数。前者是公开失败，后者是浪费容量，比例告诉你怎么估算下一届。
发布后变更次数和最后变更日期(自设)：网格公开后移动了多少，以及多晚。这决定了下一次 versioned-release 档位是否值得成本。
报告的冲突(自设)：活动后调查问题，问参会者在哪两个会话之间纠结。它是唯一触达被效率排序饿死的 audience-overlap 档位的测量。
每个时段的未出席率(活动日程指导中命名、由你跟踪的技术)：预期参会者中未出席的比例，按时段位置而非按会话记录。一个在多个会话和多个版本中表现不佳的时段，就是你这个场地的墓地时段，无论已发布来源对一般时段怎么说(见上文能量曲线节奏)。

挑选两到三个，写下各自会触发的修订，并在活动前而不是活动后记录它们。

Invocation examples

调用示例

"We have 42 accepted talks, four rooms and two days. Build me the grid."
"Our rooms are on three floors and people were late to everything last year - how much buffer do we need?"
"Two of our tracks share the same audience. How do I stop scheduling them against each other?"
"One keynote speaker only lands at 11am on Saturday. Where does she go?"
"Should we publish the schedule now or wait until it's final?"

Expected output: a schedule plan covering:

The session-length standard and what a slot contains.
Fixed points placed with their reasons.
Breaks and plenary sync points.
Room assignments with the capacity estimate behind each.
The full grid.
The clash-detection depth run and its findings.
The buffer figure and the walking distances it was checked against.
The track-start alignment and why.
The pacing read labelled as judgment.

The disruption priority order to hand to

samber/dev-event-organizer-skills@event-run-of-show

The publication posture with a date.

Presented section by section for validation before anything goes public.

“我们有 42 个已接受的演讲、四个房间和两天。帮我排好网格。”
“我们的房间分布在三层楼，去年大家都迟到——我们需要多少缓冲？”
“我们两个轨道共享同一个观众群。怎么避免把它们排在对打位置？”
“一位主旨讲者周六上午 11 点才落地。她排在哪里？”
“我们现在就发布日程，还是等到最终版？”

预期输出：一份日程方案，包括：

分会场时长标准以及一个时段包含什么。
已放置的固定点及其理由。
休息和全体同步点。
房间分配以及每个分配背后的容量估算。
完整网格。
执行的冲突检测深度及其发现。
缓冲数值及其对照过的步行距离。
轨道开始对齐方式及原因。
标记为判断的节奏读法。

要交给

samber/dev-event-organizer-skills@event-run-of-show

的扰动优先级顺序。

带日期的发布姿态。

在公开之前逐节呈现以供验证。

References

参考

references/grid-mechanics-and-clash-types.md - the rooms-by-time grid model, the four clash types in full with what each one catches and misses, the room-versus-speaker availability distinction and the multi-speaker intersection, breaks versus internal blockers, and a worked positive/negative slotting example.
references/published-schedule-benchmarks.md - FOSDEM and PyCon US published schedules, the two contrasting congestion strategies side by side, named organizer and peer-reviewed sources on energy-curve pacing and graveyard slots, and what each schedule does not show.
references/production-scheduling-concepts.md - the manufacturing scheduling concepts this skill borrows (graded buffer zones, disruption re-sequencing with a stability lock, changeover sequencing, levelled pacing), each with the mapping made explicit, plus the parts that do not carry over and the numbers that must not be reused.