event-format-selection

{
  "skill_name": "event-format-selection",
  "evals": [
    {
      "id": 1,
      "prompt": "I help run the Leeds Elixir meetup - three years running, we consistently get 130-140 people at the monthly sessions and there are about 900 people in the Slack. A friend who organizes events told me the rule of thumb is once you pass 500 community members you should launch a conference, so we're planning ElixirNorth as a two-day conference next autumn. There are four of us organizing, all with day jobs, and we've never run a CFP before. Can you help us figure out the right setup?",
      "expected_output": "A format brief that rejects the headcount rule of thumb, recommends a single-day single-track conference as the graduation target instead of a two-day debut, gates the jump on content depth and venue-risk tolerance, and validates section by section after an interview.",
      "files": [],
      "expectations": [
        "Recommends a single-day, single-track conference as the graduation target rather than endorsing the two-day conference plan",
        "Rejects the 500-community-member rule of thumb, and any fixed headcount, as the graduation gate",
        "States the published graduation trigger: a meetup consistently at 100-150+, enough quality local speakers for one curated day, and a team willing to carry venue risk",
        "Cites divergent debut sizes (DartUP jumping at around 250, GopherCon debuting at 700) as evidence that no fixed headcount gates the jump",
        "Flags the never-run-a-CFP fact as the open content-supply question, since content depth and speaker supply gate the jump",
        "Cites North Bay Python's inaugural benchmark: roughly a $40,000 budget, planned in under 6 months",
        "Gates any multi-day option on content depth and travel justification, citing Strange Loop's benchmark that 2-3 days is the sweet spot and 1-day conferences are not worth the travel time",
        "Keeps the recurring meetup running as the demand engine for the conference rather than replacing it",
        "Asks interview questions before recommending a structure, including at least the effort ceiling for four organizers with day jobs and whether this is a one-off bet or a compounding annual asset",
        "Presents 2-3 candidate structures with trade-offs and one explicit recommendation",
        "Proposes validating the structure section by section with explicit user approval rather than delivering one final block",
        "Points first-edition sizing and launch logistics to a dedicated first-edition process rather than covering launch planning inline"
      ]
    },
    {
      "id": 2,
      "prompt": "PulseConf is our single-track TypeScript conference, 300 attendees, third edition coming up. This year's CFP pulled 105 submissions for 22 slots and rejecting that many great talks feels wasteful - honestly it makes me think our CFP process is broken. The plan for next year is to split into a frontend track and a backend track so we can accept twice as much. Sanity-check this before we announce it?",
      "expected_output": "A recommendation to stay single track: the roughly 4.8x oversubscription sits well below the published 8-10x multi-track trigger, high rejection rates are normal at popular single-track events, and the rejected content gets an outlet through an open-space afternoon or ignite block instead of a second track.",
      "files": [],
      "expectations": [
        "Recommends keeping the single track and advises against adding the second track next year",
        "Computes or states the oversubscription ratio from the given figures (roughly 4.8x, about 5x)",
        "States the published multi-track promotion condition: a CFP pool oversubscribed roughly 8-10x beyond slots",
        "Cites the benchmark of 8-12 speakers per day per track, or the 200-1,200 applicant pool range for a JSConf-tier event",
        "States that 8-30x oversubscription is normal at a popular single-track conference and rejects the user's conclusion that the CFP process is broken",
        "Frames multi-track as a scale and attendee-agency decision, never a quality upgrade",
        "Cites the independent single-track convergence of named events, naming at least two of Strange Loop, GOTO, Monktoberfest, Deconstruct, SmashingConf",
        "Names what multi-track sells off: the shared experience or story arc and the organizer's editorial control",
        "Offers an outlet for content that misses the curated track, such as an open-space afternoon or an ignite block",
        "States that if multi-track is ever adopted, plenary moments (opening keynote, shared lunch, closing) must be added to preserve shared experience",
        "States that track count and content-mix policy are one coupled decision, not two separate ones",
        "Records the revision trigger for next edition: re-read CFP pressure against the roughly 8-10x floor, treating that floor as where the conversation opens rather than an automatic switch"
      ]
    },
    {
      "id": 3,
      "prompt": "I run developer marketing at NimbusWorks and own our annual user conference - about 400 attendees. Our VP wants next year's edition to be hybrid: 'best of both worlds, more reach, and low risk since we keep the in-person part anyway.' In the post-event survey a bunch of people did ask for a livestream. Budget is flat year over year. What do we need to plan to make hybrid work?",
      "expected_output": "A pushback on the premise: interactive hybrid is the maximum-cost, maximum-risk option, backed by the published CHI finances, with in-person plus record-and-post recommended instead and a concrete promotion condition under which hybrid would be revisited.",
      "files": [],
      "expectations": [
        "Advises against interactive hybrid rather than answering the how-to question as asked",
        "Rejects the 'low risk / best of both worlds' framing explicitly: hybrid is the maximum-cost, maximum-risk option, two simultaneous productions, not a middle ground",
        "Cites the published cost evidence that hybrid roughly doubles AV and logistics cost",
        "Cites CHI 2022's loss of $484,886 (or approximately $485K) as the published cautionary figure",
        "States that low virtual registration fees did not cover the cost of virtual inclusion and were subsidized by in-person fees",
        "Treats the survey requests for a livestream as non-evidence of paying remote demand",
        "Cites the figure that free livestreams draw well under 10% of sign-ups",
        "Flags that the sub-10% livestream figure comes from academic conferencing, not tech, and is indicative only",
        "Recommends in-person with talks recorded and posted afterward (or a one-feed unmonitored stream) as the default delivery mode",
        "States the hybrid promotion condition: remote registrations reliably above roughly 25-30% of paid attendance and covering their marginal cost",
        "Names the flat budget as directly contradicting the dedicated production budget hybrid requires, sized for roughly double AV and logistics",
        "Sets a next-edition measurement: compare engaged remote attendance against the published benchmarks before the hybrid question is reopened"
      ]
    },
    {
      "id": 4,
      "prompt": "We're organizing CodeSprint, a 48-hour student hackathon at the university in March - expecting around 250 hackers, about 40 teams. Since some teams are remote we planned it hybrid: on-site at the engineering building plus a Discord server for the remote teams, and everyone gets judged together at the end. For judging we're leaning toward having every team pitch on stage to the jury. Does this hold up?",
      "expected_output": "A refusal of the hybrid hackathon plan - pick in-person or fully digital and commit - backed by MLH's position and named failure modes, plus a judging structure that scales to 40 teams: expo tables by default, two-stage only if a legible finale is needed.",
      "files": [],
      "expectations": [
        "Refuses the hybrid hackathon plan and recommends committing to either in-person or fully digital",
        "States that for hackathons hybrid is deleted outright, not merely deprioritized or made conditional",
        "Cites MLH's refusal of hybrid hackathons as worse for both organizers and hackers",
        "Names at least two concrete hybrid-hackathon failure modes, such as remote attendees feeling second-class, inconsistent judging when remote teams cannot present science-fair style, sponsor interactions skewing to the booth, or swag and prize fulfilment skewing in-person",
        "States that a well-run digital hackathon is more than just a Discord server, so the planned Discord layer does not make the event digital-capable",
        "Advises against having all 40 teams pitch on stage because serial stage pitching does not scale",
        "Recommends expo-table (science-fair style) judging as the default because judges rotate in parallel and it scales",
        "Offers two-stage expo-then-finals as the structure to use when press or sponsor reporting needs a legible on-stage finale",
        "Notes video-only judging as the digital-format default and the only structure that scales past what judge-hours allow",
        "Matches demo format to jury composition: technical judges need to touch the demo, business judges need the narrative slot",
        "Hands the scoring rubric, weights, and jury mechanics to a separate judging process rather than designing them here",
        "Presents fully digital as a legitimate deliberate choice if the remote teams matter, not as a downgrade from in-person"
      ]
    },
    {
      "id": 5,
      "prompt": "First edition of HelmForge Day, a community DevOps conference - single day, 220 registered so far, and money is tight. Our platinum sponsor just offered to double their contribution if their CTO can host a panel on stage with two of their customers, and they floated a 'sponsored keynote' too. Separately I was thinking a panel of local engineering leaders would be an easy way to fill the dead 4pm slot. How should we play this?",
      "expected_output": "A refusal to sell any program slot, a counter-offer built from legitimate sponsor inventory, and both panels cut: panels are deleted from a first event, with a fireside chat or one more curated talk in the 4pm slot instead.",
      "files": [],
      "expectations": [
        "Refuses to sell the panel or sponsored keynote to the sponsor - no sponsor buys a program slot",
        "States the community-event sponsor inventory: expo, side events, and 1-minute inter-talk slots, never the stage",
        "Cites at least one named precedent for refusing sold program content, such as Strange Loop never selling keynotes, CNCF's no-sales-pitch wording, or DevOpsDays' rule that no sponsor may buy a speaking slot",
        "Deletes panels from this first event entirely rather than demoting or conditionally allowing them",
        "Cites at least one named panel critic among Fred Wilson, Brad Feld, Scott Berkun, and Duncan Green",
        "Names a structural panel flaw, such as four panelists' 5-minute introductions burning 20 minutes, or the moderator being too deferential to challenge guests",
        "Rejects the fill-the-4pm-slot reasoning as the known failure mode of scheduling a panel to flatter sponsors or fill a gap",
        "Offers the substitution for the 4pm slot: a fireside chat or one more curated talk",
        "States the panel promotion condition reserved for established events: a strong, prepared, willing-to-interrupt moderator with pre-briefed provocative questions and no long self-introductions",
        "Explains the neutrality rationale: credibility and attendee trust come from refusing sold stage content",
        "Routes the funding gap to the event's budget and funding structure rather than solving it with program inventory",
        "Makes a concrete counter-offer to the platinum sponsor from legitimate inventory, such as expo presence, a side event, or a 1-minute inter-talk slot"
      ]
    },
    {
      "id": 6,
      "prompt": "Help me design the day for KernelDay: one day, single room, about 200 attendees, community-run. Current draft is 45-minute talks back to back from 9 to 6 with 10-minute breaks. Two goals this year: get more first-time speakers on stage, and lean into the fact that attendees keep telling us the best part is the conversations between sessions. One headache: the CFP attracted a pile of vendor tool-demo submissions we don't want on the main stage but hate to just reject.",
      "expected_output": "A day architecture built from the session-format catalog: shorter curated talks in the morning, an ignite block for first-time speakers, an open-space afternoon absorbing the vendor tool content, and the hallway track protected as a designed choice with long breaks.",
      "files": [],
      "expectations": [
        "Shortens the curated talks from 45 minutes to roughly 25-30 minutes, citing that length as a sourced balance point for content rather than an arbitrary preference",
        "Adds an ignite block as the format that gets first-time speakers on stage at lower commitment",
        "States the ignite mechanics: 5 minutes, 20 slides, auto-advancing on a fixed timer",
        "States that the auto-advance mechanic, not organizer discipline, is what enforces the length",
        "Includes ignite operational safeguards: collect slides in advance and run the whole block from one dedicated laptop, never presenters' own machines",
        "Steers the vendor tool-demo submissions to open space instead of the curated stage, as the content-mix rule",
        "States that the single track is what makes the tool-talks-to-open-space rule enforceable - track count and content policy are one coupled decision",
        "Proposes a day shape with curated talks in the morning, an ignite block, and open space in the afternoon",
        "Describes real open-space ceremony elements, such as the marketplace or agenda wall, facilitators handling logistics but never content, or the Law of Two Feet",
        "Treats the hallway track as a designed format choice: lengthens breaks or otherwise protects unstructured time instead of keeping the packed 9-to-6 grid",
        "Cites Monktoberfest as the precedent for optimizing structure around the hallway track, such as its late start time",
        "Keeps an explicit written ban on sales pitches from the curated track",
        "Picks session-mix measurement signals with revision triggers written down before the event, such as the open-space wall filling or ignite application volume"
      ]
    },
    {
      "id": 7,
      "prompt": "GreenStack Conf has sold out two editions at 450 people, and next year we're expanding from one day to three. What percentage of a conference should be workshops? I read somewhere the industry standard is around 30% hands-on content. We were also thinking of running the workshops in parallel with the talks so attendees can pick their own mix.",
      "expected_output": "A refusal to endorse any industry-average workshop percentage, per-event named ratios cited instead, and the bracketing model recommended: optional separately ticketed workshop days around the talk days rather than workshops running parallel to the curated track.",
      "files": [],
      "expectations": [
        "Refuses to give an industry-average workshop percentage and declines the 30% figure rather than adjusting it",
        "Cites named per-event ratios instead, naming at least two of: SmashingConf's 2 workshop days plus 2 conference days, PyCon's separately paid tutorial days, GOTO's masterclass day, DevOpsDays' optional pre-event workshop day",
        "States the rule explicitly: report workshop ratios as named-event examples and never collapse them into one industry number",
        "Recommends the bracketing model: optional workshop days placed before or after the talk days",
        "States that workshop days under the bracketing model are separately ticketed",
        "Advises against running workshops in parallel with the curated talks because it dilutes the curated track",
        "Names the separately ticketed workshop day as a real revenue lever",
        "Checks the one-day-to-three-day jump against content depth and travel justification rather than the sellouts alone, citing the 2-3-day sweet-spot benchmark",
        "Explains that the workshop day stops competing for program hours once it moves out of the program into its own ticketed day",
        "Sets workshop sell-through measurement with a threshold fixed in advance, such as 60% of capacity, with fewer workshop days next edition if missed",
        "States that the bracketing model makes the workshop-day decision reversible edition to edition",
        "Hands workshop-day execution - capacity, facilitators, prerequisites, environment setup - to a dedicated workshop process rather than designing it here"
      ]
    },
    {
      "id": 8,
      "prompt": "I organize DataForge Summit, our company's annual user conference - around 350 attendees. The audience is split roughly half data-platform engineers, half analytics managers and directors. The feedback is contradictory every year: engineers say the talks are too fluffy, managers say they're too deep. Our fix for next year is to brief every speaker to pitch their talk at an intermediate level so it works for everyone. Good plan?",
      "expected_output": "A rejection of the flat intermediate difficulty band, replaced by the two-audience track split: two tracks under one banner keyed to depth, with per-session maturity tags, preserved plenary moments, and the vendor-conference pole named where it changes the defaults.",
      "files": [],
      "expectations": [
        "Rejects briefing every speaker to an intermediate level - a flat difficulty band serves neither audience",
        "Applies the two-audience promotion condition: two genuinely different audiences sharing the same underlying problem at different depths justify two tracks under one banner",
        "Distinguishes this condition from the CFP-oversubscription trigger, noting it is a separate promotion path",
        "Recommends tagging each session with a maturity or depth level so each track carries sessions at the depth its audience wants",
        "Structures the split by depth and audience - decision-makers wanting the why, practitioners wanting the how - rather than by technology topic alone",
        "Preserves plenary moments such as an opening keynote, shared lunch, or closing alongside the track split",
        "Identifies the event as the vendor/user-conference pole and says which recommendations assume which pole",
        "Notes that vendor conferences run invited content organized around the vendor's architecture with a narrower vertical scope",
        "Does not frame the second track as a quality upgrade - frames it as an audience and agency decision",
        "Keeps the two tracks under one event banner rather than proposing two separate events",
        "Records the revision trigger for next edition, such as per-track attendance or depth feedback deciding whether the split stays",
        "Asks for audience evidence or interview answers, such as numbers behind the audience split, before finalizing the structure"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Our Rust meetup pulls 120 people every month. Should we run a conference, and what shape should it take?", "should_trigger": true },
    { "query": "Single track or multi-track for a 500-person developer conference?", "should_trigger": true },
    { "query": "We got 90 CFP submissions for 24 slots - time to add a second track?", "should_trigger": true },
    { "query": "Should our developer conference go hybrid next year?", "should_trigger": true },
    { "query": "The CEO wants remote customers to join our user conference live. Talk me through hybrid.", "should_trigger": true },
    { "query": "Is an unconference the right format for our 150-person community day?", "should_trigger": true },
    { "query": "Hackathon or conference - which should our community run first?", "should_trigger": true },
    { "query": "What mix of talks, workshops and open space should fill our one-day event?", "should_trigger": true },
    { "query": "Panel or fireside chat for the famous CTO we invited?", "should_trigger": true },
    { "query": "How should teams demo at our hackathon - stage pitches or science-fair tables?", "should_trigger": true },
    { "query": "Design the day: one day, 200 attendees, community-run, more first-time speakers on stage.", "should_trigger": true },
    { "query": "We're going from one day to two days - how do workshops fit in?", "should_trigger": true },
    { "query": "Should the hackathon be in person or online?", "should_trigger": true },
    { "query": "Our meetup has outgrown the sponsor's office - what's the next step up?", "should_trigger": true },
    { "query": "Everyone keeps asking us to livestream the conference. Worth doing properly?", "should_trigger": true },
    { "query": "What percentage of the program should be hands-on workshops?", "should_trigger": true },
    { "query": "Thinking about turning our Python user group into an annual conference", "should_trigger": true },
    { "query": "two tracks or three for devfest?", "should_trigger": true },
    { "query": "Is a multi-day conference worth it or should we stay single day?", "should_trigger": true },
    { "query": "What session format lets first-time speakers on stage without giving them a full talk slot?", "should_trigger": true },
    { "query": "Open space all afternoon - good idea or chaos?", "should_trigger": true },
    { "query": "Should we replace the closing keynote with a panel?", "should_trigger": true },
    { "query": "Our conference is basically a meetup that got too big. What structure should year one have?", "should_trigger": true },
    { "query": "Fireside chat vs keynote for our headline guest who hates public speaking", "should_trigger": true },
    { "query": "Considering a lean coffee session at the start of each day - is that the right format?", "should_trigger": true },
    { "query": "What's the right event concept for launching our local Kubernetes community, meetup or something bigger?", "should_trigger": true },
    { "query": "we want remote attendees but can't afford a big AV budget, what do we do", "should_trigger": true },
    { "query": "Does it make sense to run our internal hackathon as hybrid so the Singapore office can join?", "should_trigger": true },
    { "query": "How many talks versus workshops for a 2-day, 300-person conference?", "should_trigger": true },
    { "query": "Choosing between a hackathon and an unconference for our developer community weekend", "should_trigger": true },
    { "query": "The sponsor wants a panel slot - should panels even be on our program?", "should_trigger": true },
    { "query": "What event format gets 300 developers actually talking to each other instead of just watching talks?", "should_trigger": true },
    { "query": "Do we really need a second stage, or can the whole program fit in one room?", "should_trigger": true },
    { "query": "Our virtual meetup community wants a bigger annual event - stay online or go physical?", "should_trigger": true },
    { "query": "judging format for 60 hackathon teams, what scales?", "should_trigger": true },
    { "query": "Is video-only judging acceptable for an online hackathon?", "should_trigger": true },
    { "query": "We're a devtools vendor planning our first user conference - one track for everyone or split by audience?", "should_trigger": true },
    { "query": "What shape should our first community event take if we only have four volunteers and weekends?", "should_trigger": true },
    { "query": "Ignite talks - worth adding a block to our conference?", "should_trigger": true },
    { "query": "Should the workshop day be part of the conference ticket or separate?", "should_trigger": true },
    { "query": "How do conferences balance curated talks with attendee-driven sessions?", "should_trigger": true },
    { "query": "Turn our monthly meetup into a one-day conference - does this plan make sense: 3 tracks, 12 workshops, hybrid?", "should_trigger": true },
    { "query": "should we do an open spaces afternoon like devopsdays", "should_trigger": true },
    { "query": "What's the minimum meetup size before a conference is viable?", "should_trigger": true },
    { "query": "Two very different audiences (data engineers and analysts) at one event - one program or two?", "should_trigger": true },
    { "query": "Remote attendance for our conference: full virtual tier, plain recording, or nothing?", "should_trigger": true },
    { "query": "Best format for a 24-hour student hackathon finale - pitches on stage or demos at tables?", "should_trigger": true },
    { "query": "Lay out the session grid so no two Python talks clash", "should_trigger": false },
    { "query": "Which rooms should each accepted talk go in given the room capacities?", "should_trigger": false },
    { "query": "We've decided on hybrid - how does remote Q&A reach the stage?", "should_trigger": false },
    { "query": "What cue track does the livestream crew need beside the room's?", "should_trigger": false },
    { "query": "Pick a virtual event platform for our fully-online summit", "should_trigger": false },
    { "query": "How do we staff chat and Q&A moderation for our online conference?", "should_trigger": false },
    { "query": "Design the judging rubric and criteria weights for our hackathon", "should_trigger": false },
    { "query": "How do we normalize scores across hackathon judges?", "should_trigger": false },
    { "query": "Write the challenge tracks and rules document for our fintech hackathon", "should_trigger": false },
    { "query": "How big should the hackathon cash prize be?", "should_trigger": false },
    { "query": "Set up a mentor program for our hackathon weekend", "should_trigger": false },
    { "query": "How should we form teams at the hackathon kickoff?", "should_trigger": false },
    { "query": "How many facilitators per workshop room, and what prerequisites do we send participants?", "should_trigger": false },
    { "query": "Our workshop room's wifi can't handle 80 laptops - what's the backup plan?", "should_trigger": false },
    { "query": "When should our CFP open and close relative to the event date?", "should_trigger": false },
    { "query": "What fields should the CFP submission form have?", "should_trigger": false },
    { "query": "How do we review and select from 200 talk submissions fairly?", "should_trigger": false },
    { "query": "Build the budget and break-even model for a 300-person conference", "should_trigger": false },
    { "query": "What should early-bird tickets cost?", "should_trigger": false },
    { "query": "Find us a venue that fits 500 with three breakout rooms", "should_trigger": false },
    { "query": "Should we run a multi-city roadshow or one big user conference?", "should_trigger": false },
    { "query": "Executive summit or trade-show booth - where should our company show up this year?", "should_trigger": false },
    { "query": "What's the ROI case for running our user conference at all?", "should_trigger": false },
    { "query": "Which quarter and weekday should the conference land on?", "should_trigger": false },
    { "query": "How do we grow the event from 400 to 800 attendees next edition?", "should_trigger": false },
    { "query": "Write the sponsorship prospectus and tier structure", "should_trigger": false },
    { "query": "What should Gold sponsorship cost?", "should_trigger": false },
    { "query": "Plan the minute-by-minute run of show for conference day", "should_trigger": false },
    { "query": "What camera and audio setup do we need to record all the talks?", "should_trigger": false },
    { "query": "Turn this year's talk recordings into a content calendar", "should_trigger": false },
    { "query": "Plan the official after-party and evening social activities", "should_trigger": false },
    { "query": "Draft the code of conduct and incident response process", "should_trigger": false },
    { "query": "Build the 9-month planning timeline working back from the event date", "should_trigger": false },
    { "query": "Help me launch the first edition - team, go/no-go dates, minimum viable scope", "should_trigger": false },
    { "query": "How should we position our conference against the two competing ones?", "should_trigger": false },
    { "query": "Design the badge and check-in experience for attendees", "should_trigger": false },
    { "query": "Set up the speaker green room and the speaker dinner", "should_trigger": false },
    { "query": "Write a cold-outreach email to invite speakers we admire", "should_trigger": false },
    { "query": "How many volunteers do we need and how do we run them on the day?", "should_trigger": false },
    { "query": "Score and judge our startup pitch competition", "should_trigger": false },
    { "query": "What event schema format should our Kafka topics use?", "should_trigger": false },
    { "query": "Choose a date format for the events table in our API", "should_trigger": false },
    { "query": "Best file format for exporting calendar events from our app", "should_trigger": false },
    { "query": "What format should our team's sprint retro sessions take?", "should_trigger": false },
    { "query": "Design the expo floor layout and booth traffic pattern", "should_trigger": false },
    { "query": "Should our meetup group also start a podcast or a newsletter?", "should_trigger": false },
    { "query": "How do we keep the community active between conference editions?", "should_trigger": false }
  ]
}

# Delivery-mode evidence: the post-2022 retreat from interactive hybrid

The financial and engagement record behind the delivery-mode menu in SKILL.md. The direction is consistent across sources - curated technical events reverted to in-person-first after 2022.

## ACM CHI's published finances

Regan Mandryk, ACM SIGCHI Steering Committee Chair Emeritus, "CHI Conference Finances and Format Part One" (ACM SIGCHI Medium, Nov 2023):

- "The hybrid conference platform was similar in price to a physical convention centre rental; the logistics support for the virtual conference was double that for the physical conference; the AV support for the hybrid conference more than double the cost of a physical-only conference."
- "The low registration fee for virtual attendees in 2022 in no way covered the expense of their inclusion, and was subsidized by the in-person conference fees."
- CHI 2022 "experienced a loss of $484,886, largely due to increased costs related to a fully hybrid conference experience." CHI 2023, a scaled-back hybrid, still closed at a loss of approximately $132K (per SIGCHI's Neha Kumar), with online participants reporting it less engaging.
- CHI 2026 now states plainly: "no hybrid or remote attendance" - authors who cannot travel submit a pre-recorded video played to the in-person audience. (SIGCHI Medium, chi2026.acm.org.)

## Corroborating evidence

- **ACM SIGMETRICS** stopped hosting hybrid conferences "due to lack of attendee participation"; the same governing-board minutes (April 2024) note SIGIR'22 had no-shows for its remote presentations.
- Academic organizers quoted by Times Higher Education: when most panelists stay home, "we risk going there… 'you are the audience - we are the speakers'" (Mark Carden, Researcher to Reader); "Hybrid is definitely more expensive and requires additional staff resources" (Mary Beth Barilla, Society for Scholarly Publishing, who asked all speakers to appear in person).
- Free livestreams draw "well below 10% of sign-ups" - Simon Usherwood, March 2023: "Livestreaming is really expensive… you need people to monitor and manage the equipment… Even a simple set-up… might be doubling your event costs." **Flag: this source is political-science conferencing, not tech - treat the sub-10% figure as indicative, not tech-specific.**

## MLH's anti-hybrid position (hackathon-specific)

Major League Hacking's organizer guide supports exactly two formats: in-person (judging, food, venue on-site; digital tools allowed as support) and digital (fully remote, global reach, video or virtual-room judging). They state directly: "We will not be working with hybrid events… we have seen historically that hybrid events are worse for both organizers and hackers." Their reasoning: organizers end up coordinating two events simultaneously ("a well run digital hackathon is more than just a Discord"), and digital participants consistently report feeling like second-class attendees.

Their named failure-mode list, verbatim in substance:

- in-person workshops run late with no notice to virtual attendees, or are in-person-only due to AV limits
- check-in communication to virtual attendees lags while the team handles physical check-in
- digital engagement drops because side activities skew physical
- virtual attendees get fewer sponsor interactions since sponsors work their booth
- judging reads as inconsistent when remote teams cannot present science-fair style
- swag and prize fulfilment skews to in-person attendees
- cross-format team collaboration is harder in practice

MLH also models how to state a format preference honestly: they prioritize in-person "to make sure we have the greatest impact possible with the resources we have available" - a constraint-driven preference, not a universal doctrine.

## What survived vs what retreated

- **Survived**: in-person events with talks recorded and posted afterward (or streamed one-feed, unmonitored); fully-virtual events where a specific community has cost or access reasons to stay all-remote.
- **Retreated**: interactive "true hybrid" - a paid, engaged, simultaneous remote audience alongside the room.

## Benchmarks that would revise the recommendation

- If remote registrations reliably exceed ~25-30% of paid attendance **and** cover their marginal cost, revisit interactive hybrid - with a dedicated production budget, expecting AV and logistics to roughly double per CHI's figures.

The cleanest cost data comes from academic CS/CHI organizers; commercial developer conferences rarely publish finances. When citing the CHI or SIGMETRICS numbers, never attribute them to a developer conference by name - reference them as the closest published record available.

# Sourced format precedents

Named events whose structural choices - and the organizers' own reasons for them - back the menus in SKILL.md. Cite these as per-event precedents, never as industry averages.

## Graduation trajectories: meetup → single-day → multi-day

All figures come from the organizers themselves unless noted.

- **DartUP** - local Dart meetup:
  - by 2017, grown enough to rent an external venue, drawing 250+ people with eight talks
  - over ~5 years, became an international event hosting 500 offline and 1,500 online participants

  (Organizer Anton Anokhin, Medium.)

- **GopherCon** - debuted 2014 with exactly 700 attendees (co-organizer Brian Ketelsen: "In the end, we had 700 attendees"):
  - 1,300+ in 2015, after doubling venue capacity
  - ~800 in 2024

  Attendance fluctuates by host city and year - treat any single figure as point-in-time, not steady state.

- **RailsConf** - inaugural 2006 Chicago edition at roughly 400-600 attendees, "then just kept doubling year over year… something like 1,800 attendees in 2008" (DHH). Successor **Rails World** sold out a 1,000-attendee Toronto edition in under twenty minutes; its 2023 Amsterdam debut sold 700+ tickets in under 40 minutes.
- **North Bay Python** - inaugural single-track regional conference "planned in under 6 months, ran on a $40,000 budget" (PyCon US talk abstract). The budget benchmark for a credible first single-day event.

**What actually gates each jump** (sourced synthesis, not headcount):

- a meetup consistently outgrowing its free or borrowed venue
- enough quality local speakers to fill a curated day
- an organizer team willing to carry financial risk - venue deposits, contracts booked up to three years ahead (Strange Loop's Alex Miller)

The single-day → multi-day jump is gated by content depth and travel justification, not attendance: Strange Loop's own page argues "2-3 days is the sweet spot… 1-day conferences are not worth the travel time."

**Caveat**: RailsConf's and Strange Loop's endings were deliberate organizer-sustainability decisions (per DHH and Alex Miller), not format failures. Never cite either ending as evidence against the structures they ran.

## Single-track manifestos: five independent organizers, same choice

- **Strange Loop** (Alex Miller): "No marketing. Keynotes are never sold to sponsors. The conference mailing lists are never sold or given to sponsors." "Every year we turn down hundreds of excellent talks by excellent speakers in the service of creating a balanced program." (thestrangeloop.com)
- **GOTO**: "All talks are in the same room the first two conference days. The audience has a shared context as the curated story arc unfolds… you will get to know each other and the speakers much better." "Every talk… is chosen by a program committee… not sold to us. No sales pitches from the stage. And the speakers stay. Around 75% of them hang around on the days they're not speaking, so the hallway conversations are as good as the program."
- **Monktoberfest** (Stephen O'Grady, RedMonk): "Believing that some of the best content at any conference is the hallway track, we optimized for that. Start time was 10 AM." "We worked backwards from the capacity of our venue… Some things just work better at a small scale."
- **Deconstruct** (Gary Bernhardt): billed by its organizer as "an unusually independent software development conference"; described by attendees as single-track, no sponsors, hand-selected speakers (that description comes from attendee posts).
- **SmashingConf**: "We believe in thoroughly curated speakers and talks… No fluff, no fillers, no multi-track experience and no large hotel halls."

Five recurring reasons across them:

- shared experience everyone can discuss
- curation as editorial responsibility rather than offloading choice onto attendees
- the hallway track as a deliberate design goal
- refusing sold slots (keynotes, mailing lists, stage pitches) to protect attendee trust
- better speaker experience because speakers stay for the whole event

This is independent convergence - treat multi-track as a scale and attendee-agency decision, never a quality upgrade.

## DevOpsDays day architecture: the single-track/content-mix coupling

From the DevOpsDays organizing guide. Recommended daily order:

1. ~15-minute organizer intro
2. curated ~30-minute talks in the morning ("about 30 minutes have the right balance for content" - a chosen balance point, not a scheduling default)
3. 1-minute Gold-sponsor slots between talks (doubling as presenter setup time)
4. breaks
5. Ignite block after lunch
6. open space all afternoon, scheduled live on the day

Typical volume: four 30-minute talks per day plus a set of Ignites, all attendees in one room for the curated portion.

Two governance rules protect the structure:

- first-time organizers must consult a core organizer before altering it
- no sponsor may ever buy a speaking slot

The content-mix rule is coupled to the track choice: tool- and product-specific talks are steered to open space ("for specific tools talk, there are open spaces, not the main conference talks"), reserving the curated track for conceptual and cultural content.

A second curated track would need its own balance policy - the single track is what makes the rule enforceable. Track count and content mix are one decision, not two.

## Workshop-day ratios: per-event, never an average

Hands-on content is packaged as optional add-on days, not a fixed percentage. Report the ratios below as named-event examples; never invent an industry average.

- **SmashingConf**: "4 days, with 2 workshop days with 8 practical workshops, and 2 conference days… single track with 12 speakers, 300-400 friendly attendees"; San Francisco edition: 2 days, single track, 14 speakers, 8 workshops.
- **PyCon US**: tutorials as separate 3-hour paid sessions (historically ~$150 each) on dedicated days before three days of talks.
- **GOTO**: separates conference days from a masterclass day and frames the choice for attendees: "If you already know which problem you're trying to solve, do the masterclass. If you're scanning the landscape, do the conference."
- **DevOpsDays**: roughly half curated content, half self-organized, plus an optional pre-event workshop day with 45-, 90-, 120-, or 180-minute slots.

The workshop-day-plus-talk-day model is the dominant low-risk pattern once an event outgrows one day: it adds hands-on depth without diluting the curated track, and workshop days are separately ticketable - a real revenue lever, not only a content decision.

## Community vs vendor conferences at the session-selection level

- Community events (CNCF/Linux Foundation, DevOpsDays, NorthSec) run open CFPs and ban sales content explicitly: "Reminder: This is a community conference - so no product and/or vendor sales pitches"; NorthSec: "we do not accept sponsored talks." Blind CFP review is valued but not the norm - swyx (Netlify): "blind CFP review is important for some level of equity… In my experience, most CFP's are NOT blind."
- Vendor/user conferences run more invited content organized around the vendor's architecture, with sponsored keynotes; swyx: "Company sponsored conferences are often around a certain architecture… Scope is a little narrower and more 'vertical.'" (swyx.io)
- CFP economics benchmark (swyx, "CFP Advice", 2020, verbatim): "A rule of thumb is 8-12 speakers per day, per track… So a 3 day single track conference has a max of 36 talks." Applicant pools range "from an average 200 to something like 800-1200 for a JSConf" - an 8-30x oversubscription at a popular single-track conference is normal, not a broken CFP.

# Session format catalog

The building blocks the session-mix menu in SKILL.md composes. Each entry: what it is, what it costs the organizer, when it earns its slot, and its known failure modes - drawn from the format owners' own documentation.

## Curated talk (~25-30 minutes)

The program backbone. DevOpsDays' guide states ~30 minutes is a deliberately chosen balance point for content, not a scheduling default.

Costs a full CFP-or-invitation cycle per slot; produces the event's durable recorded assets. Community-event guardrail (CNCF, DevOpsDays, NorthSec): ban sales pitches from the curated track explicitly, in writing.

## News recap block

A segment opening a recurring meetup with field news since the last edition.

- **Why it earns a slot:** in a fast-moving field, many attendees value it highly, and some come for it alone.
- **Trade-off:** those who came only for it leave right after, and others find it too long. A long recap taxes everyone who came for the main session.
- **Cost:** real preparation every edition: collecting, filtering and ranking the news. It is not free filler.
- **Rules:** cap it (set the cap yourself; the report's 30 minutes drew "too long" complaints), name one owner per edition, and place it so leavers do not walk out across a speaker. Track departures after it as a session-mix signal.

## Ignite talk (5 minutes, 20 slides, auto-advancing)

A named format from igniteshow.com, adopted as-is by DevOpsDays. Slides advance on a fixed timer - the presenter cannot control pacing; the mechanic, not organizer discipline, is what enforces the length.

That is the transferable lesson for any short format: build the constraint into the mechanics. One rule: no straight sales pitch - socially enforced, not policed.

Why it earns a slot: a lower-commitment, higher-volume speaking format that gets first-time and non-headline voices on stage in a way a full-talk-only program cannot.

Sourced operational failure modes:

- presenters submit slides late or misunderstand auto-advance - collect slides in advance (PDF travels best) and remind presenters same-day that they cannot advance slides and have no notes
- run the whole block from one dedicated laptop, never presenters' own machines

A filler variant exists (Ignite Karaoke: 1 minute, 4 absurd slides at 15 seconds) for padding a light schedule with levity.

## Open space (Open Space Technology)

Self-organized sessions with no pre-set agenda, documented by DevOpsDays citing Harrison Owen. The design contract an organizer accepts when choosing it: the Law of Two Feet (anyone neither contributing nor learning moves elsewhere) and its four principles:

- whoever comes is the right people
- whatever happens is the only thing that could have
- whenever it starts is the right time
- when it's over, it's over

Four-phase ceremony:

1. Opening - show the day's timeline; 1-2 minute topic intros maximum, longer drains energy.
2. Marketplace of ideas - topics on stickies claim timeslots on an agenda wall.
3. Breakout sessions - facilitators handle logistics, never content; capture outcomes on a shared wiki or paper forms.
4. Closing circle - a talking stick, one brief feeling each.

Expect bumblebees (flit between sessions, cross-pollinating) and butterflies (stay put; their quiet conversations are often the most significant).

### Small-group mechanics

Figures are that report's, not a published standard.

- **Cap each discussion group at about 10.** One round of speaking above 10 people takes an hour. A group of 13 was reported unworkable: split it.
- **One convener per group** - naturally the person who proposed the topic. They want to discuss it and need not be an expert. Their job is balancing speaking time, not answering.
- **Rotate after about 20 minutes**, so people meet more than one group.
- **Capture by voice note per group**, then a short plenary synthesis. Cheaper than paper forms at a meetup, and the convener owns it.
- **Quiet attendees benefit most.** People who spoke in a small group interacted more with others for the rest of the evening.

Treat open space as a distinct structural option, not a lesser fixed-agenda track: it trades program control for self-selected relevance. DevOpsDays also uses it as the pressure valve for its content-mix rule - tool- and vendor-specific depth goes here, keeping the curated track conceptual.

## Lean Coffee (single-table unconference)

From leancoffee.org, the creators' own site (Jim Benson and Jeremy Lightsmith, Seattle 2009). Designed for zero organizational overhead: a three-column personal kanban (to discuss / discussing / discussed), everyone writes topics, 1-2 sentence pitches, two dot-votes each, highest-voted topics first. Its power is a topic list the whole table is already motivated to discuss.

Versus full Open Space: no opening/marketplace/closing ceremony, no real facilitator role, vote-based prioritization instead of self-selection-by-attendance. Fits a single-room, single-timeslot slice - a breakfast session, a track filler - where Open Space's multi-room, half-day ceremony would be oversized.

## Keynote, fireside chat, panel

Decision guidance:

- **Keynote** - a single sequenced argument by a strong speaker who controls the narrative. Best when you have that speaker.
- **Fireside chat / moderated interview** - extracts value from a high-profile guest who is not a polished presenter; multiple sources note it "has replaced solo keynotes at many conferences" and makes it "easier to get a 'yes' from business leaders" (Slido, BigSpeak). Known trap, flagged even by proponents: sliding into celebrity-interview mode where the interviewer merely feeds a monologue - prepared, willing-to-challenge questions are the fix.
- **Panel** - the most-criticized format in the sourced record, by name:
  - Fred Wilson's flat "no panels rule"
  - Brad Feld: "panels are awful and should be eliminated from planet earth… consider eliminating the panels altogether"
  - Scott Berkun ("Why Panel Sessions Suck"): the moderator is passive, speakers state the obvious, and organizer-moderators "are afraid to challenge the panelists since the panelists are their guests"
  - Duncan Green (LSE): "coma-inducing panels" and "people (usually men) asking 'questions' that are really comments"

  Structural critique across sources: four panelists × 5-minute introductions burns 20 minutes before any substance.

A panel is worth running only with a strong, prepared, willing-to-interrupt moderator and pre-briefed provocative questions - and it is the hardest format for a first-time organizer to execute, which is why the staged ladder cuts it entirely from a first event.

## Workshop day (bracketing model)

Not an in-program session type but a program-structure move: one or two optional, separately ticketed hands-on days before or after the talk days (SmashingConf, PyCon US tutorials, GOTO masterclasses, DevOpsDays pre-event day). Adds depth without diluting the curated track, and the separate ticket makes it a budget lever. Never express workshop share as an industry-average percentage; none is published.

## Hackathon judging/demo formats

| Format      | Mechanics                                          | Scales to many teams? | Winner narrative        |
| ----------- | -------------------------------------------------- | --------------------- | ----------------------- |
| Expo table  | Judges rotate through team tables, 3-5 min each    | Yes (parallel)        | Weak - no shared moment |
| Stage pitch | Teams pitch a panel, 2-5 min + Q&A                 | No (serial)           | Strong                  |
| Video only  | Async judging from submitted video + write-up      | Best                  | Weakest                 |
| Two-stage   | Expo round narrows to finalists who pitch on stage | Moderate              | Strongest               |

Judge composition shapes the fit:

- technical judges want to touch a live demo (expo)
- business judges want a deliberate narrative (stage)
- domain experts and sponsor reps work in any format, but need explicit rubric prompts to surface their priority in a time-boxed slot

The scoring rubric and weights belong to `samber/dev-event-organizer-skills@hackathon-judging` - this catalog only covers which demo structure to run.

## Recurring meetup variants

The variants SKILL.md lists under the recurring-meetup rung. Figures are absent on purpose: set your own.

### No-prerequisite discussion café

- **What it is:** a monthly open roundtable. No talks, no expert framing. Pitch: "come with your questions and worries; people who know a bit will talk with you."
- **Why:** meetups drift toward insiders, and a talk program assumes a baseline. The café is the on-ramp before deeper sessions.
- **Cost:** a room and someone to host the table; no speakers.
- **Failure modes:** experts take over and it becomes a talk; regulars treat it as their club. Brief the host to redirect to newcomers' questions.
- **Mechanics:** reuse the small-group mechanics under § Open space once the table passes about 10.

### Host-company breakfast

- **What it is:** a weekday morning, roughly 8:00 to 10:30, at a host company that pays the room and coffee. Zero organizer cost. Hosts rotate among large local actors.
- **Program shapes seen:** a news review then a round-table; an expert panel (see § Keynote, fireside chat, panel for the moderator condition); a beginner-friendly session.
- **Side effect:** business introductions between attendees and hosts - a draw for managers and business roles, a cost for a purely technical crowd.
- **Failure modes:** the host's calendar decides the dates, and the host's brand dominates the room. Fix: rotate hosts, keep program control, write down what the host gets.
- **Slot effect:** a morning slot reaches people an evening excludes; see `samber/dev-event-organizer-skills@event-date-selection` § Time of day.

### Bar-hosted after-work

- **What it is:** an evening in a bar, with a sponsor paying drinks.
- **Strength:** lowest setup cost, social by default.
- **Failure modes:** noise kills any talk; the sponsor's role drifts into the program. Keep content to a short intro at most.

### Rotating format

- **What it is:** a series that cycles formats (dinner, lunch, after-work, talk, open session) and never reuses the same weekday and hour twice in a row.
- **Why:** a fixed slot excludes the same people every time. One series reported stable attendance over years this way.
- **Cost:** each edition needs its own announcement; regulars cannot rely on habit.

### Cross-community joint evening

- **What it is:** many local meetup groups (one report: around twenty) each run a stand or session in one venue on one night.
- **Cost:** light coordination - one coordinator, a coworking host - but a real energy cost spread across every participating group.
- **Why:** cross-pollination between communities that rarely meet. Occasional, never the cadence. Partner mechanics belong to `samber/dev-event-organizer-skills@cross-event-promotion`.

### Street-level outreach

- **What it is:** vox-pop video capsules, a stand at a seasonal market.
- **Why:** general-public acculturation on the topic, reaching people who would never open a meetup page.
- **Counting:** report it as outreach, never as meetup attendance.

---
name: event-format-selection
description: Choose a technical event's structure before anything is scheduled - the event shape (recurring meetup, hackathon, unconference day, single-day or multi-day conference), one program or several (single versus multi-track), workshop-day ratios, the session-format mix (curated talks, workshops, open space, ignite, fireside chats, panels), delivery mode (in-person, virtual, hybrid), and hackathon demo/judging structure. Use whenever asked to pick an event format or concept, decide single-track versus multi-track, weigh hybrid or virtual delivery, compose a session mix, or graduate a meetup into a conference. Structural choice only. Do NOT use for schedule grids, clash avoidance or room-capacity matching - use samber/dev-event-organizer-skills@event-schedule-design.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.2.0"
---

# Event Format Selection

You are a format strategist for technical events. You own:

- whether the event is one program or several
- which shape it takes: meetup, hackathon, unconference, single-day or multi-day conference
- how workshops relate to talks
- which session formats fill the day
- whether delivery is in-person, virtual, or hybrid

You do not build the schedule - grid layout, clash avoidance, and room-capacity matching belong to `samber/dev-event-organizer-skills@event-schedule-design`. You decide single vs multi-track here, because it follows from size, audience, and content-mix strategy; `event-schedule-design` places sessions into that structure there.

Every recommendation below is a default, not a law - it shifts with context and with who executes it. After the interview, re-rank every menu against what you know about this organizer: an owned venue, an in-house AV team, a distributed community, a vendor's existing customer base can each 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 of the payoff, and effort - the default rankings cannot be picked for the user.

1. Which decision is on the table: the full structure from scratch, or one axis (track count, delivery mode, session mix, hackathon demo format)? Skip the menus already settled.
2. Who owns the event and why does it exist: community conference (independent, CFP-driven, volunteer-run, sponsors as cost recovery) or user/vendor conference (vendor-run, keynote-driven, marketing budget, sponsors as pipeline)?
3. What is the audience evidence today: recurring meetup attendance, community size, a past edition's registrations? Numbers, not impressions.
4. Is there a hard date or season the event must land in, or is timing free? (A hard deadline promotes low-runway shapes and invited content over long CFP cycles.)
5. Is this a one-off bet or a compounding annual asset? (A compounding mandate promotes the slower, trust-building structures: open CFP, unsold keynotes, single-track curation.)
6. What is the effort ceiling: organizer hours alongside day jobs, headcount, budget appetite, and appetite for venue-deposit risk?
7. What is the content supply: how many quality speakers or submissions are realistically available? If a CFP has run before, what was the applicant-to-slot ratio?
8. Is there evidence a remote audience would pay - past livestream engagement, a genuinely distributed community, virtual-ticket sales anywhere in this space? (Gates the hybrid promotion condition; "people asked for a stream" is not evidence.)
9. Which assets already exist that should re-rank the menus: a venue through an employer or sponsor, in-house production/AV skill, a recording pipeline, an existing workshop instructor pool?
10. Is there a moderator able and willing to interrupt and steer a panel?
11. Does press or sponsor reporting require a legible on-stage finale for the hackathon demo?
12. Recurring meetup only: who is the audience today - practitioners, or mostly people who do not yet practice the topic? Does the meetup read as an insiders' club to newcomers? (Gates the discussion-café variant.)
13. Recurring meetup only: does a local company offer a room and coffee for free, a bar offer space with a sponsor paying drinks, or a coworking host offer a venue for a multi-community evening? (Gates the cost-free variants.)
14. Which shapes, session formats and side activities do the local alternatives already run? (Gates the copied-recipe check in workflow step 3; a saturated city makes it decisive.)
15. Conference only: does the positioning name one target audience or several? If several, which content serves each? (Gates the multi-target rule under track count.)

## Community vs vendor conference

The split that changes format choice is who owns the event and what it is for (same split `samber/dev-event-organizer-skills@event-first-edition` argues):

- **Community conference** - open CFP, explicit sales-pitch bans ("no product and/or vendor sales pitches" - CNCF's wording), sponsors bought expo and side-event inventory but never program slots, credibility from neutrality. Everything sourced in this skill's menus (DevOpsDays, Strange Loop, GOTO, MLH) comes from this pole.
- **User/vendor conference** - invited content organized around the vendor's architecture, sponsored keynotes, narrower "vertical" scope (swyx). The format question shifts from curation policy to program-marketing balance. This skill covers where the structural menus differ; the vendor-side format family in depth (product-launch keynotes, executive summits, trade-show floors) belongs to `samber/dev-event-organizer-skills@business-event-formats`, as does the sponsor-facing activity layer a conference of either pole runs beside its program.

Say which pole each recommendation assumes when they differ. The single-track evidence, the CFP economics, and the sales-pitch bans are community-pole facts; the delivery-mode cost evidence applies to both.

## Workflow

1. Run the interview; skip menus the user has already settled (Q1).
2. Fix the ownership pole (Q2) - it changes defaults in every menu below.
3. Pick the **event shape** from the staged ladder. Check the graduation trigger honestly against Q3 and Q7 evidence - content depth and risk tolerance gate the jumps, never headcount alone. Then check the candidate structure against what local alternatives already run (Q14): a shape and session mix that reproduce the nearby standard recipe give attendees no reason to choose this event. Innovate on at least one format or activity rather than copy; the differentiation claim itself belongs to `samber/dev-event-organizer-skills@event-positioning`. The check re-ranks nothing: it picks among rungs the ranking already allows.
4. Decide **track count** with its content-mix consequence - one coupled decision, not two.
5. Compose the **session-format mix** for the chosen shape; load [references/session-format-catalog.md](references/session-format-catalog.md) for the mechanics, failure modes, and the keynote/fireside/panel decision guidance.
6. Choose the **delivery mode**; load [references/delivery-mode-evidence.md](references/delivery-mode-evidence.md) before recommending anything hybrid.
7. Hackathon only: choose the **demo/judging structure**; hand the scoring rubric to `samber/dev-event-organizer-skills@hackathon-judging`.
8. Present 2-3 candidate structures with trade-offs and one recommendation; validate section by section with the user, never as one block. This is a strategy deliverable - get explicit approval before finalizing.
9. Hand off the approved structure:
   - to `samber/dev-event-organizer-skills@event-schedule-design` for the grid
   - to `samber/dev-event-organizer-skills@event-positioning` when the chosen format carries identity implications (a single-track curated event and a multi-track expo say different things about what the event is)

If your harness has persistent memory, record the chosen shape, track count, session mix, delivery mode, and - most importantly - the sourced trigger that would revise each choice. Next edition's format review starts from those triggers instead of re-arguing the defaults.

## Event-shape ladder

Ranking (default, not a law - re-rank against Q4-Q6, Q9):

- effort (runway + day-of operations + financial risk): `multi-day conference > single-day conference == hackathon > unconference day > recurring meetup`
- value (credibility + depth + connection per edition): `multi-day conference > single-day conference > hackathon > unconference day > recurring meetup`
- efficiency: `recurring meetup > unconference day > single-day conference > hackathon > multi-day conference`

The `==` is argued: a single-day conference and a hackathon carry comparable total effort spent in different places. The conference spends its longer runway on a CFP and curation cycle, while the hackathon compresses the runway (4-9 months in the sourced hackathon timeline) but pays it back in continuous day-of operations, judging logistics, and prize fulfilment. Neither is the cheap option.

- **Recurring meetup** - the default rung until its graduation trigger fires, and the demand engine for everything above it. Stay here while the venue still fits and the speaker pipeline is thin.
  - A recurring meetup is not one format. Read § Recurring meetup variants before fixing it as "talks in the evening".
- **Unconference day** (open space or Lean Coffee at full-day scale) - a curation-free step up: a real venue and a real day without a CFP cycle. Fits a community that generates its own topics; see the catalog reference for the ceremony this actually commits you to.
- **Hackathon** - a different value proposition (building, not talks), not a rung above or below the conference; choose it when the goal is artifacts and team formation, not shared learning.
- **Single-day single-track conference** - the graduation target. Trigger (published): meetup consistently at 100-150+, enough quality local speakers for one curated day, and a team willing to carry venue risk. North Bay Python ran a credible inaugural on a $40,000 budget, planned in under 6 months. Not gated by a fixed headcount - DartUP jumped at 250+, GopherCon debuted at 700; the gate is content depth plus risk tolerance.
- **Multi-day conference** - the starved option: highest value, loses every efficiency round. Promote it on content depth and travel justification, never attendance alone - Strange Loop's own benchmark: "2-3 days is the sweet spot… 1-day conferences are not worth the travel time". The standard low-risk structure at this rung is the workshop-day bracketing model (SmashingConf, PyCon, GOTO): optional, separately ticketed hands-on days around the talk days - added depth, no dilution of the curated track, and a real revenue lever. Cite the per-event ratios in [references/format-precedents.md](references/format-precedents.md) rather than averaging them into a single industry figure.

If this is a first edition, size and launch it with `samber/dev-event-organizer-skills@event-first-edition` - its single-focus scope tier deliberately cuts from this catalog, and its ladder-jumping gates (team, budget tiers) are stricter than this menu's.

## Recurring meetup variants

Variants of the recurring-meetup rung, not extra rungs: they share its effort, value and efficiency position on the ladder above, and change who comes and what it costs. Mechanics, costs and failure modes per variant sit in [references/session-format-catalog.md](references/session-format-catalog.md) § Recurring meetup variants.

- **Talk evening** - the default variant: one or two curated talks, then drinks.
- **No-prerequisite discussion café** - a monthly open roundtable, no talks, no expert framing, pitched as "come with your questions and worries; people who know a bit will talk with you". Meetups drift toward insiders; this is the on-ramp before deeper sessions. **Promotion condition, keyed to Q12**: a mostly non-practitioner audience, or a meetup perceived as an insiders' club.
- **Host-company breakfast** - a weekday morning at a host company that pays the room and coffee, zero organizer cost, hosts rotating among large local actors. Promote when Q13 names willing hosts and the audience includes managers and business roles. Watch host calendar control and brand dominance.
- **Bar-hosted after-work** - an evening in a bar, a sponsor paying the drinks. Lowest setup cost, weakest content.
- **Rotating format** - the series cycles dinner, lunch, after-work, talk, open session, and never reuses the same weekday and hour twice in a row. Pairs with `samber/dev-event-organizer-skills@event-date-selection` § Recurring series.
- **Cross-community joint evening** - many local meetup groups each run a stand or session in one venue on one night. Light coordination (one coordinator, a coworking host) but a real energy cost on every participating group. Occasional, never the cadence.
- **Street-level outreach** - vox-pop video capsules, a stand at a seasonal market. General-public acculturation, not a meetup edition; count it as outreach, never as attendance.

Topic-domain alternation across editions (technical, marketing, HR, human topics) is a renewal lever on newcomer share, owned by `samber/dev-event-organizer-skills@event-community-building`. Settle the topic boundary here when a series adopts it.

## Track count - and the content-mix rule it enables

Ranking (default, not a law):

- effort (curation + coordination): `multi-track > single track + open-space afternoon > single track`
- value, content capacity + attendee agency: `multi-track > single track + open-space afternoon > single track`
- value, shared experience + curation control: `single track > single track + open-space afternoon > multi-track`
- efficiency: `single track > single track + open-space afternoon > multi-track`

**Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass.** One mechanism blocks all three: the two value axes are exact reverses, so whichever rung buys more content capacity gives up shared experience, and no rung is at least equal on both.

Effort is never reached in any pair, and no third axis is printed. The check finds nothing; the ordering rests on the argument that follows.

The two value axes genuinely disagree - that disagreement is the decision. Multi-track buys content volume by selling off the shared story arc and the organizer's editorial control.

- **Single track** - the default, on independent convergence: Strange Loop, GOTO, Monktoberfest, Deconstruct, and SmashingConf all chose it deliberately and give overlapping reasons (shared context, curation as editorial responsibility, the hallway track as a design goal, no sold slots, speakers who stay). Quotes and sources in [references/format-precedents.md](references/format-precedents.md). Treat multi-track as a scale decision, never a quality upgrade.
- **Single track + open-space afternoon** - the DevOpsDays architecture: curated 30-minute talks in the morning, an Ignite block, open space all afternoon. Its quiet advantage: the content-mix rule it enables - tool- and vendor-specific talks are steered to open space, keeping the curated track conceptual. Track count and content policy are one coupled decision; a second curated track would need its own balance policy.
- **Multi-track** - the starved option. Promotion condition (published): a CFP pool oversubscribed ~8-10x beyond slots (swyx's benchmark: 8-12 speakers per day per track; 200-1,200 applicants for a JSConf-tier event), so that multi-track reduces rejection of genuinely strong content. Promote it only alongside added plenary moments (opening keynote, shared lunch, closing) that preserve some shared experience.
  - A second, distinct promotion condition, self-set rather than published: two genuinely different audiences who share the same underlying problem stated at different depths - decision-makers wanting the why, practitioners wanting the how - run as two tracks under one banner rather than as two separate events. Where this fires, tag each session with a maturity level so both a beginner-heavy and an expert-heavy track can carry sessions at the depth its own audience actually wants, rather than one flat difficulty band.

**Multi-target rule** (conferences of one or several days only, keyed to Q15): `samber/dev-event-organizer-skills@event-positioning` prefers one target audience. When it names several, every target needs sessions of its own at every edition, or it leaves and the promise breaks. Single track carries this through dedicated slots for each target; multi-track carries it through one track per target. Either way, check the session mix per target before the grid goes to `samber/dev-event-organizer-skills@event-schedule-design`. This changes no ranking: it is a coverage constraint on whichever rung is picked.

Community-pole guardrail regardless of track count: no sponsor ever buys a program slot; sponsor inventory is expo, side events, and the DevOpsDays-style 1-minute inter-talk slot - never the stage. Sponsor-facing activities (hiring corner, hands-on product feedback session, opt-in demo space, matchmaking) run beside the program, never in the CFP; their shapes belong to `samber/dev-event-organizer-skills@business-event-formats`.

## Session-format mix

Compose the day from the catalog; mechanics and failure modes per format live in [references/session-format-catalog.md](references/session-format-catalog.md). Ranking for the marginal program hour (default, not a law):

- effort (organizer hours per program hour delivered well): `panel > workshop day > curated talks > fireside chat > ignite block > open space`
- value (learning + connection + durable assets per hour): `curated talks > workshop day > open space > fireside chat > ignite block > panel`
- efficiency: `open space > ignite block > curated talks > fireside chat > workshop day > panel`

- Default backbone: curated ~25-30 minute talks - the sourced balance point for content, and the event's recorded assets.
- Ignite blocks and open space are the efficiency leaders: near-zero content-curation cost, and they solve real program problems (first-time speaker volume; self-selected relevance and a pressure valve for tool-specific content).
- Fireside chat over keynote for a high-profile guest who is not a polished presenter - the sourced substitution.
- **The workshop day is what this order starves**: second on value, second on effort, so it never wins a marginal program hour. Promotion condition: it stops competing for program hours once it moves out of the program - a separately ticketed bracketing day (see the shape ladder), where it also becomes a revenue lever.
- **Panels sit last on every axis, and for a first event they are deleted, not demoted** (the sourced ladder cuts them entirely - hardest format to execute, most-criticized: Fred Wilson, Brad Feld, Scott Berkun, Duncan Green, by name in the catalog reference). **Promotion condition for an established event, keyed to Q10**: a strong, prepared, willing-to-interrupt moderator with pre-briefed provocative questions, and no long self-introductions. Absent that moderator, the option stays off the menu.
- Protect the hallway track as a format choice, not leftover time: long breaks, good food, quiet rooms (Monktoberfest optimized its start time around it).

## Delivery mode

Ranking (default, not a law - Q8 evidence can promote the starved rung):

- effort: `interactive hybrid > fully virtual == in-person with record-and-post`
- value (engagement depth + reach): `interactive hybrid > in-person with record-and-post > fully virtual`
- efficiency: `in-person with record-and-post > fully virtual > interactive hybrid`

The `==` is argued: each single mode is one full production, and the cost centers substitute for each other. CHI's published figures price the hybrid platform "similar… to a physical convention centre rental," and MLH warns "a well run digital hackathon is more than just a Discord."

CHI's other figure - virtual logistics support at double the physical event's - prices the virtual layer of a hybrid run, not a standalone virtual production, so it does not break the tie. Hybrid is not a third production of the same size; it is both at once.

- **In-person with record-and-post** - the default and the pattern that survived the post-2022 shake-out: full room, talks recorded and posted (or streamed one-feed, unmonitored) afterward. The remote audience gets the content asynchronously without a second live production.
- **Fully virtual** - legitimate when the community itself has cost or access reasons to stay all-remote (MLH's digital format is global by design). A deliberate single-mode choice, not a downgrade.
- **Interactive hybrid** - the starved option for conferences, argued on the published record: hybrid roughly doubled AV and logistics cost, virtual fees did not cover virtual costs, CHI 2022 lost $484,886, and free livestreams draw well under 10% of sign-ups (figures and caveats in [references/delivery-mode-evidence.md](references/delivery-mode-evidence.md)). Promotion condition: remote registrations reliably above ~25-30% of paid attendance **and** covering their marginal cost, plus a dedicated production budget sized for roughly double AV/logistics. For **hackathons, hybrid is deleted, not starved**: MLH refuses hybrid outright ("worse for both organizers and hackers") with a named failure-mode list - pick in-person or digital and commit.

## Hackathon demo/judging structure

Structural choice only - rubric, weights, and jury mechanics belong to `samber/dev-event-organizer-skills@hackathon-judging`. Ranking (default, not a law; borrowed from adjacent practice - see the catalog reference):

- effort (judge-hours + staging per team): `two-stage expo-then-finals > stage pitch > expo table > video only`
- value (judge interaction depth + winner-narrative legibility): `two-stage expo-then-finals > stage pitch > expo table > video only`
- efficiency at scale: `video only > expo table > two-stage expo-then-finals > stage pitch`

**Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations - clean only by construction, and that is not a pass.** Value and effort are the same list, so one mechanism blocks every pair: the structure that buys deeper judge interaction costs strictly more judge-hours and staging.

Nothing else is printed that could block or rescue a pair. The check catches no misordering; what follows is argument, not verification.

- **Expo table** - the default: real judge-demo interaction, parallel so it scales.
- **Two-stage** - the starved option: top of both value axes, top of effort, so efficiency never picks it; **promotion condition, keyed to Q11**: press or sponsor reporting needs a legible on-stage finale.
- **Video only** - the digital-format default and the only structure that scales past what judge-hours allow.

Match format to jury composition: technical judges need to touch the demo; business judges need the narrative slot.

## Failure modes

- **Hybrid chosen as the safe compromise.** It is the maximum-cost, maximum-risk option, not the middle: two simultaneous productions, doubled AV/logistics, and a remote audience that reports feeling second-class. Weigh the sourced cost list; don't split the difference.
- **Multi-track read as a quality upgrade.** Five independent single-track manifestos say otherwise; multi-track is a scale and agency decision with a sourced promotion trigger. Reaching for it below ~8-10x CFP oversubscription buys empty rooms and a fragmented event.
- **Graduating the ladder on headcount alone.** The sourced gates are content depth, venue-risk tolerance, and speaker supply. GopherCon debuting at 700 does not make 700 a threshold; DartUP jumped at 250.
- **Inventing an industry-average workshop percentage.** Cite the named-event ratios and let the spread between them stand; collapsing them into one number invents a norm the events themselves do not share.
- **A panel scheduled to flatter sponsors or fill a slot.** The sourced consensus is brutal; without the prepared-moderator promotion condition, replace it with a fireside chat or one more curated talk.
- **Track count and content policy decided separately.** The single curated track is what makes a "conceptual talks on stage, tool talks in open space" rule enforceable - decide them together or the rule dies in track two.
- **Copying a named event's structure without its constraints.** Monktoberfest's smallness and Strange Loop's curation are worked-backward-from-venue, turn-down-hundreds choices. Import the reasoning, not the surface shape.
- **Copying the local recipe.** A structure identical to what nearby events already run competes on date and price alone, a losing frame in a saturated city. Fix: run the workflow step-3 check against Q14 and innovate on one format or activity.
- **A second audience with no sessions of its own.** A multi-target conference programmed for its main target loses the other within an edition. Fix: the multi-target rule under track count, or drop the target in `samber/dev-event-organizer-skills@event-positioning`.
- **A recurring meetup frozen as one format and one slot.** It keeps the regulars and quietly stops the on-ramp. Fix: pick a variant on purpose (§ Recurring meetup variants), and rotate format and slot when newcomer share drops.
- **A host-company breakfast the host owns.** Free rooms come with the host's calendar and logo. Fix: rotate hosts, keep the program yours, and write down what the host gets (visibility, introductions) before the first edition.
- **Selling program slots to cover the format's cost.** Every sourced community event refuses stage inventory to sponsors; funding structure belongs to `samber/dev-event-organizer-skills@event-budget`, not to the program.

## Measurement

Format choices are testable edition over edition. Each measure below is marked published or self-set; adapt the self-set gates per event.

- **Delivery-mode check** (published figures): if a stream or virtual tier ran, compare engaged remote attendance to the sub-10%-of-sign-ups livestream benchmark (indicative only - the figure comes from academic conferencing, not tech; see the reference) and the ~25-30% promotion threshold. Below them, the hybrid spend fails its own test next edition.
- **CFP pressure** (published figures): applicant-to-slot ratio against the ~8-10x multi-track trigger - the only published trigger for adding a track. Read it as the floor where the conversation opens, not as evidence the CFP is broken: swyx's own figures make 8-30x oversubscription normal at a popular single-track event.
- **Meetup variant signals** (self-set, recurring meetup only): newcomer share and returning share per variant (definitions in `samber/dev-event-organizer-skills@event-community-building`), and for the discussion café, how many attendees go on to a deeper session.
- **Workshop sell-through** (self-set): separately ticketed workshop days that don't sell to a threshold you fix in advance (e.g. 60% of capacity) argue for fewer next edition; the bracketing model makes this reversible.
- **Session-mix signals** (self-set): open-space marketplace filling its wall, ignite-slot application volume, room walkouts during panels, departures right after a news recap block. Pick 2-3, decide the revision they would trigger, and write both down before the event.
- Sellout speed, attendee retention, and sponsor renewal read on the whole event, not the format - they belong to `samber/dev-event-organizer-skills@event-market-fit`.

## Invocation examples

- "Our Rust meetup pulls 120 people every month. Should we run a conference, and what shape?"
- "We're debating adding a second track next year - the CFP had 90 submissions for 24 slots."
- "The CEO wants our user conference hybrid so remote customers can join live. Talk me through it."
- "Design the day: one day, 200 attendees, community-run, more first-time speakers on stage."
- "Our AI meetup only attracts people who already build with it. How do we reach the people who are curious but scared?"
- "A big local company offered to host us for free every month at 8am. Should we take it?"

Expected output: a format brief with (1) the chosen shape and the graduation evidence behind it, (2) track count with the content-mix rule it enables, (3) the session-format mix as a day architecture, (4) delivery mode with its promotion/deletion reasoning, (5) for each choice, the sourced trigger that would revise it next edition. Presented section by section for validation, with 2-3 candidate structures and one recommendation up front.

## References

- [references/format-precedents.md](references/format-precedents.md) - graduation trajectories (DartUP, GopherCon, RailsConf/Rails World, North Bay Python), the five single-track manifestos with quotes, the DevOpsDays day architecture, per-event workshop ratios, community-vs-vendor session-selection evidence.
- [references/session-format-catalog.md](references/session-format-catalog.md) - mechanics, costs, and failure modes per session format: curated talks, news recap block, Ignite, open space with small-group mechanics, Lean Coffee, keynote/fireside/panel guidance with the named critics, workshop-day model, hackathon judging-format table, recurring meetup variants.
- [references/delivery-mode-evidence.md](references/delivery-mode-evidence.md) - CHI's published hybrid finances, SIGMETRICS retreat, the sub-10% livestream figure, MLH's anti-hybrid failure-mode list, and the benchmarks that would revise the default.

See also, same collection:

- `samber/dev-event-organizer-skills@event-cfp-design` and `samber/dev-event-organizer-skills@event-talk-selection` - the CFP process and talk selection feeding whatever track structure is chosen here.
- `samber/dev-event-organizer-skills@event-venue-sourcing` - venue requirements the chosen structure creates, including hybrid/virtual infrastructure.
- `samber/dev-event-organizer-skills@event-cultural-identity` - turns the shape chosen here into a register, traditions and rituals; a single-track curated day and a multi-track expo carry different cultures and it owns that consequence.
- `samber/dev-event-organizer-skills@workshop-program-design` - runs the workshop day this skill decided to bracket: capacity, facilitator coverage, participant prerequisites and environment setup, and the network posture a room of laptops needs. It never re-argues whether the day exists or how it is ticketed.
- `samber/dev-event-organizer-skills@hackathon-brief-design` - writes the challenge document against the demo and judging structure chosen here. Note the word collision: a _track_ here is a parallel session stream, while a _challenge track_ there is a thematic category a team enters.