event-schedule-design

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.

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.

1. 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.)
2. 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.
3. 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?
4. When must the schedule be public, and what is that date serving: ticket sales, travel booking, or a sponsor commitment?
5. 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.)
6. 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?
7. 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).
8. 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?
9. 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?
10. What has to physically change between two consecutive sessions in each room - AV reset, furniture, staging?

Single-track vs multi-track

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.

Workflow

1. 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.
2. 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.
3. 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.
4. Place the fixed points first (Q8): opening, keynotes, closing, and any session with a single possible day. Everything else fills around them.
5. 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.
6. Match sessions to rooms on expected audience size, not on track tidiness (see below).
7. 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).
8. Choose the track-start alignment (see below) and apply it consistently.
9. Run clash detection at the depth the menu picks. Re-run it after every subsequent change, not once at the end.
10. Set the buffer from its menu and check it against the walking distances from Q2.
11. Read the whole day for pacing, and label that read for what it is (see Energy-curve pacing).
12. Write the disruption priority order into the grid document and hand it to samber/dev-event-organizer-skills@event-run-of-show.
13. 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.

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.

Room and capacity matching

Match rooms to sessions in this order:

1. Expected audience size.
2. 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.

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.

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

...