event-continuous-improvement

Event Continuous Improvement

You own everything that crosses editions of a recurring technical event:

• Detect a trend across two or more dated debrief logs.
• Separate the findings that are noise from the ones that are signal.
• Persist the aggregate learning log.
• Audit that log so it stays trustworthy.
• Close the loop back to whoever owns the change.

One edition is not yours. samber/dev-event-organizer-skills@event-debrief runs the retrospective on one finished edition and hands you its dated log. Its own upstream boundary refuses cross-edition trending, because comparing one edition to the last two duplicates a sibling's whole reason to exist. Never re-run its analysis, re-open a single edition's findings, or produce the artifact it produces.

More scope arrives already owned. Read each sibling below, route to it, and never decide for it:

Sibling	Owns	You do
event-market-fit	Demand-signal trends: sellout speed, sales-pace, return rate, sponsor renewal	Your trends are operational (desk overflowing again, same vendor failing twice) - state the split out loud on handover
event-growth-strategy	Whether and how to scale	"Bottlenecks past 300 attendees" is evidence you hand it, never a recommendation
event-team-structure	Succession, bus-factor, burnout	Notice the same structural finding recurs across editions - the persisted log is itself a bus-factor mitigation
event-planning-timeline	When the work happens	You decide what changes and why
event-vendor-sourcing	One vendor's own performance record	Route a rebook-or-not verdict there once it recurs; it is evidence for that vendor's file, not a general theme

Participant feedback never reaches you directly: event-feedback collects it, event-debrief reconciles it, and you only see what came through that log.

What organizer guides cover, and where they stop

Say this out loud to the user, because it bounds every claim below.

• One organizer guide covers the first handover, and the gap is narrower than it looks. MLH's Organizer-Resources/keeping-records.md gives a cadence, an audience, two artifacts and a worked example, all of it edition-one-to-edition-two. DevOpsDays' organizing.md carries only one code-of-conduct line on the subject. Neither follows a finding from edition one to edition three or four. Full quotes and the worked example: references/log-format-and-audit.md.
• The one real structural proof is a git history. DevOpsDays' organizing.md is a single shared guidance document that survived repeated, complete organizer turnover through small targeted edits rather than periodic rewrites. That proves a persisted, collectively-edited document survives turnover; it is not a template for a trend log's format, since it carries no dated per-edition entries and no trend annotations at all.
• Two fragments carry over from software improvement practice, labelled as borrowed wherever they appear. The loops themselves do not: a SaaS improvement loop assumes a per-run or per-quarter cadence, while an event improves once a year with a partly-turned-over team. What survives is printing-press-retro's filing gate (references/filing-gate-and-trend-evidence.md) and ce-compound-refresh's Keep/Update/Consolidate/Replace/Delete classification (references/log-format-and-audit.md).
• One conference-management report names the practice itself, not its mechanics. Fraser and Mancl's 2023 report on the future of conferences calls a retrospective "an essential management practice for conference stakeholders to drive ongoing improvements to a conference," run as an organizer meeting after the event and paired with a post-event survey to "identify trends (year over year)," explicitly framed for "a conference series." That backs holding the practice across editions at all. It supplies no cadence beyond "after the event," no per-edition log format, and no occurrence bar.

Naming the practice this way is sourced. The log format, the occurrence bar, the menus below and every template in references/ are this skill's own construction. Do not present any of it as established organizer practice.

Interview

Ask one question at a time, multiple-choice where possible. Questions 5 to 7 exist because the menus below diverge sharply on time-to-effect, durability, and effort; the default ordering cannot be picked for the user without them.

1. How many editions has this event run, and for how many of them do you hold a written record? The second number is the only one that bounds a trend claim.
2. What form do those records take today - nothing written, a chat thread, one document per edition, or a structured record with fields?
3. How much of the organizing team has turned over since the earliest record you hold - nobody, some, most, or a full rotation to a different team - and is a handover to different people planned for this cycle?
4. Are the entries in samber/dev-event-organizer-skills@event-debrief's three-part form with an owner and a date, or looser? Do comparable numbers exist across editions, or only prose findings? And has any past edition changed something deliberately because of a logged finding?
5. When does next edition's planning start, or when is the go/no-go decided? That date is this skill's deadline; a trend that lands after the plan is written changes nothing.
6. Is this a one-off or closing edition, or a compounding one meant to run for years - and roughly how many more?
7. What is the effort ceiling between editions: hours available, and does anyone own a between-edition job today at all?
8. Where does the log live, and who is expected to open it before planning starts? Name a person. "The team" is the answer that produces a log nobody re-reads.

Continuity or rotation

The filing gate, recurrence counting, theme grouping, the audit classification and the routing rules are byte-for-byte identical whether the event serves enterprise buyers or weekend hobbyists.

The axis that genuinely changes the output is how much of the team is the same team next edition, because it decides what the log has to carry:

• Continuous team - the same people run consecutive editions. Memory partly substitutes for the log, and that is the trap: the log stays thin precisely because nobody needs it yet. The gap surfaces only in the year someone leaves. Write for the successor who is not in the room.
• Partial turnover - the common case. Some findings live in the log, some live in one person's head, and nobody can tell which is which. Theme grouping earns its cost here: a returning organizer and a new one describe the same recurring failure in different words.
• Full rotation - a franchise, a rotating-city model, or an incoming team inheriting the event. The log is the entire transmission mechanism, not a convenience. DjangoCon Europe bolted on a support working group of previous organizers plus a standing events-support function for exactly this case, since the written record alone could not carry it.

Workflow

1. Run the interview. If the answer to Q1 is one edition of records, stop the trend work and say so: file this edition, start the log, and come back next year. Half of this skill is unavailable and pretending otherwise manufactures a pattern.
2. Receive the log, do not re-run it. Take samber/dev-event-organizer-skills@event-debrief's dated log per edition as given. If an entry is thin or unclear, note the gap; never reconstruct the edition it came from.
3. File every entry through the signal gate. Borrowed from the printing-press-retro filing gate: an entry becomes a candidate only when it is reproducible in the event's own conditions and generalizes beyond one occurrence. A one-time failure that was handled and cost nothing is expected work, not a finding. De-personalise as you file: samber/dev-event-organizer-skills@event-debrief's blameless frame has to survive into a document that outlives the people in it. Gate criteria, worked positive and negative filings, and the de-personalisation rule: references/filing-gate-and-trend-evidence.md.
4. Group before you count. Cluster differently-worded entries into themes, then count the theme's recurrence rather than the entry's. Two occurrences make a candidate; three make a pattern. Say which of the two you are holding every time you state a trend.
5. Decide what changes, one deliberate change at a time. Resist bundling: a plan carrying four simultaneous changes cannot attribute any outcome to any of them. Write every change in three parts:
   • What you are changing.
   • Why the evidence justifies it.
   • How you will know next edition whether it worked.
6. Route each change to its owner.
   • Operational change: samber/dev-event-organizer-skills@event-planning-timeline, as a real task on next edition's plan.
   • Anything shaped like demand: samber/dev-event-organizer-skills@event-market-fit.
   • Anything shaped like size: samber/dev-event-organizer-skills@event-growth-strategy.
   • Anything structural and recurring: samber/dev-event-organizer-skills@event-team-structure, carrying the recurrence count as the evidence a single debrief could not produce.
   • Anything naming one supplier's own performance, such as rebook or not, a brief to rewrite, a quantity to change: samber/dev-event-organizer-skills@event-vendor-sourcing, filed on that vendor's own record rather than left in the general log where next edition's buyer will not think to look for it.
7. Persist the log at the rung chosen from the first menu below, and name it to the team as the bus-factor mitigation it is.
8. Audit the accumulated log at the cadence chosen from the third menu. Classify every entry as Keep, Update, Consolidate, Replace or Delete, borrowed from ce-compound-refresh with one honest amendment: its ground truth is a codebase that can be checked at any time, while yours is next edition's own outcome, which only exists after the fact. The audit is therefore retrospective, never continuous. Format, classification rules and the handover packet: references/log-format-and-audit.md.
9. Close the loop. Before the planning cycle ends, state which of last cycle's deliberate changes shipped and what happened. An improvement loop that never checks its own output is a filing system.

If your harness has persistent memory, record the log itself: every filed entry with its theme, first-seen edition and occurrence count; every deliberate change with its justification and check; every routing hand-off. This is the one skill in the collection whose value depends entirely on the record surviving between runs a year apart, readable by someone who was not there when it was written.

Every ranking below is a default, not a law. Where a constraint deletes a rung, strike it from that menu's axis lines too: a rung left in the ordering survives in the reader's head and returns as scope. Re-rank all three menus against what you already know about this team.

• A shared version-controlled document already buys the persistence rungs cheaply.
• One person running every edition has no theme-grouping problem yet, and a worse turnover one.
• A team that never shipped a deliberate change has nothing to audit or close.

Log persistence posture

Ranked menu - cross-edition trends that hold up and survive turnover, bought per unit of standing upkeep. The rungs and the orderings are this skill's own construction, not a published standard: organizer guides offer timeless how-to guidance, not a dated learning log to copy.

• effort (setup, per-edition upkeep, retrofitting what already exists): structured entry record > numeric series > appended document > carry-forward only
• value (patterns detectable at all, and readable by someone who was not there): structured entry record > appended document > numeric series > carry-forward only
• efficiency: appended document > structured entry record > numeric series > carry-forward only

Value and effort differ in the middle, which is the point of splitting them. The numeric series costs more than the appended document, because the numbers must be measured the same way every edition or someone reconstructs them. It also buys less: operational trends are prose ("the desk overflowed again"), and numbers mostly answer the demand question owned by samber/dev-event-organizer-skills@event-market-fit. Carry-forward sits last on efficiency despite costing almost nothing, because it buys nothing that crosses editions, and zero over zero never wins a ratio.

• Carry-forward only - re-read the most recent edition's debrief log when planning opens. Nothing is aggregated; recurrence lives in whoever happens to remember it.
• Appended document - one running dated document; each edition appends its filed findings under a dated heading. Real structural evidence backs this rung: DevOpsDays' organizing guide survived eleven years and 20+ contributors as exactly this kind of document. Borrow only its survival property, never its timeless-guidance format.
• Numeric series - a small table of the same handful of numbers per edition, drawn from the goals each debrief measured itself against.
• Structured entry record - every filed finding carries fields: theme, first-seen edition, occurrence count, status, disposition, owner. Recurrence becomes countable instead of remembered. Describe it as a record, whatever the team already uses; never prescribe a tool.

Default rung: the appended document, from the second edition of records onward. Starved option: the structured entry record - first on value, first on effort, so efficiency never picks it. Promotion conditions, and which rungs to delete outright on a thin or inconsistent record: references/reranking-by-interview-answers.md.

Trend-detection depth

Ranked menu - defe

...