samber/developer-relations-skillsチェック済み
SKILL DETAIL
developer-meetup-program
samber/developer-relations-skills/developer-meetup-program
Designs and runs a recurring developer meetup or user group - purpose and host model, format menu, cadence, a standing speaker pipeline, in-kind venue and food sponsors with their conduct limits, no-show planning, the attendee-to-co-organizer ladder, and a health scorecard. Use whenever someone mentions starting a developer meetup or user group, dying meetup attendance, finding meetup speakers, getting a venue or pizza sponsor, how often to meet, RSVPs who never show, or handing the meetup over - even if they only say "we want to do local events". Covers independent, vendor-backed and company-staffed groups. Not for speaking at a conference - use samber/developer-relations-skills@conference-cfp-submission.
インストール · 428出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill developer-meetup-program
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "developer-meetup-program",
"evals": [
{
"id": 1,
"prompt": "I run the Helsinki Elixir evening, we've done 6 editions now. Last month 118 people RSVP'd, the room at our host's office seats 60, and 41 turned up. I ordered pizza for 118 and binned most of it, which cost us about 640 euros. For next month I'm capping RSVPs at 60 so it matches the room exactly, and I've budgeted food for 60. A friend who runs a bigger group told me free evening events run 40-50% no-show so I should just assume half won't come. What should my numbers actually be?",
"expected_output": "A corrected no-show plan: CNCF's ~30% planning figure named as the sourced default, the 40-50% figure rejected as folklore, the group's own measured show-up rate (41 of 118) preferred because six editions exist, overbooking kept instead of a capacity-matched cap, surplus routed to an auto-promoting waitlist, food sized on expected door count, and a reminder schedule ending with a release-your-spot request two hours out.",
"files": [],
"expectations": [
"States the no-show planning figure as roughly 30% of RSVPs and attributes it to CNCF Community Groups",
"Rejects the 40-50% no-show figure explicitly as folklore with no named organization behind it",
"Derives the group's own show-up rate from the numbers given (41 of 118, roughly 35%) rather than assuming the imported figure applies",
"Prefers the group's own measured rate over CNCF's figure because six editions of door counts already exist",
"Uses the median of the group's trailing editions, not the mean, when setting the local rate",
"Rejects capping RSVPs at the 60-seat capacity, because overbooking to the no-show ratio is the point of the calculation",
"Routes the overbook surplus beyond room capacity to a waitlist that auto-promotes, rather than onto the RSVP list",
"Sizes the food order on expected door count rather than on RSVPs, and names catering the registration list as the most common budget mistake at this scale",
"Puts the food budget near 60 people, not 118",
"Includes a reminder roughly two hours before the event asking people who cannot come to release their spot",
"Frames the release request as freeing a seat for someone on the waitlist, not as guilt or a rebuke",
"Records the door count rather than the registration count in the edition log",
"Specifies vegan and vegetarian options and allergen labelling for the food"
]
},
{
"id": 2,
"prompt": "Two of us want to start a Postgres group in Bratislava. Neither of us knows the audience yet, it's a brand new group, and the first event has to happen on 14 April because that's when the venue is free and we already announced the date publicly. We both have day jobs, realistically 3 hours a month each. I want to run a hands-on workshop every month because that's what I'd want to attend, and if that's too much we could just do an open space so nobody has to prepare anything. Which one?",
"expected_output": "An explicit format ranking with the workshop and the open space both deleted rather than demoted, the deletions named, the fixed date used to promote formats needing no confirmed speaker, effort and value emitted as separate orderings, and study group or anchor + lightning recommended.",
"files": [],
"expectations": [
"Presents an explicit efficiency ordering of the formats rather than a flat menu, leading with anchor + lightning",
"Gives the ordering as anchor + lightning > study group > two-talk classic > open space > hands-on workshop",
"Deletes the hands-on workshop outright rather than demoting it, citing the roughly 3 hours a month per organizer ceiling",
"Deletes the open space outright rather than offering it as the zero-preparation option, because the room has never met each other",
"Says explicitly which formats it deleted, not only which it recommends",
"Explains that the fixed 14 April date promotes formats needing no confirmed speaker, because speaker sourcing is the one lead time that cannot be compressed",
"Recommends a study group or anchor + lightning as the realistic pick for this first edition",
"Emits effort and value as separate orderings rather than blending them into a single rank",
"Justifies the effort tie between study group and open space: neither needs a confirmed speaker nor any organizer-prepared material",
"Emits no compliance-cost axis for the format choice, since none of the formats changes what the group owes anyone",
"Warns that a workshop run monthly by a two-person team breaks the cadence within a quarter",
"States that ten to fifteen attendees is a real first edition rather than setting a larger turnout target"
]
},
{
"id": 3,
"prompt": "I lead DevRel at Corvex, we sell an observability SDK. Leadership approved budget for \"Corvex User Groups\" in Milan, Krakow, Manchester and Austin, first dates locked six weeks out. We have zero volunteers in any of those cities. My plan: my two DevRel engineers fly out and run every evening themselves, two talks from our own engineers plus a roadmap update, and we recruit local people to book the rooms and call them the organizers. Long term I want these to graduate into independent community groups. Is that the right progression?",
"expected_output": "A rejection of the maturity-ladder framing, the one genuine choice (vendor-backed chapter vs company-staffed series) ranked on efficiency, effort and compliance cost, the staffed series promoted anyway for this fixed date with no local organizers, the irreversibility asymmetry stated, and the mislabelled volunteer arrangement called out.",
"files": [],
"expectations": [
"Rejects the framing that the three host models form a maturity ladder or a progression toward independence",
"Notes that vendor-affiliated user groups predate the independent volunteer model, citing SHARE founded in 1955, so independence is not a later stage",
"States that no efficiency ranking applies across all three models, because the model is settled by who is asking rather than chosen",
"Identifies the one real choice available here as vendor-backed volunteer chapter versus company-staffed series",
"Gives efficiency as vendor-backed volunteer chapter > company-staffed series",
"Gives effort as company-staffed series > vendor-backed volunteer chapter",
"Gives compliance cost as company-staffed series > vendor-backed volunteer chapter",
"Explains the compliance line as the review each model triggers: a staffed series puts attendee data, the code of conduct and stage content under company legal and brand sign-off",
"Promotes the company-staffed series for this case anyway, because the date is fixed and no local organizer exists yet",
"States the irreversibility asymmetry: a staffed series can hand over to volunteers later, but a chapter cannot be un-handed",
"Calls out that recruiting locals to book rooms with no program control gives them an organizer's workload and a helper's authority",
"Requires at least one speaker per edition with no stake in Corvex's product, or accepts that attendance decays to customers only",
"Warns against the \"user group\" label while running a company-staffed series, and says to either give volunteers program control or drop the framing"
]
},
{
"id": 4,
"prompt": "Putting together a one-pager to send to three companies I want as venue hosts for our Ghent Kotlin meetup. I want it to look credible so I wrote: \"Industry benchmarks for developer meetups: 70% show-up rate, 40% repeat attendance, at least 1 in 3 speakers sourced from the audience, and groups should keep 2 editions of confirmed speakers ahead.\" We've run 9 editions so I do have our real numbers, they're just less flattering. Can you tighten the wording?",
"expected_output": "Every one of the four quoted figures relabelled as a baseline rather than an industry benchmark, the 70% shown to be arithmetic on CNCF's 30% no-show figure, the genuinely sourced figures listed as the ones safe to quote externally, and the group's own nine editions of measured numbers made the lead.",
"files": [],
"expectations": [
"Refuses to present the 70% show-up rate, the 40% repeat attendance, the 1-in-3 room-sourced speakers and the 2-editions-ahead figures as industry benchmarks",
"Labels each of those four figures as a baseline rather than a measured industry figure",
"Explains the 70% show-up rate is the direct arithmetic complement of CNCF's roughly 30% no-show figure, not an independent finding",
"Tells the user to write \"our target\" instead of \"industry benchmark\" for any baseline",
"Warns that a baseline presented as an industry standard costs the user's credibility across the whole document",
"Names sourced figures safe to quote externally, including CNCF's 90-day inactivity threshold, its minimum of six meetings per calendar year, its bar of more than 10 attendees, and its 15-minute sponsor stage cap",
"Names DevOpsDays' published positions (no bought speaker slots, no distribution of attendee contact information) as quotable sourced material",
"Notes the 1-in-3 room-sourced speaker target is deliberately ambitious against Nielsen's participation rates rather than a typical outcome",
"Attributes the 90-9-1 participation inequality to Jakob Nielsen and 2006",
"Recommends leading the venue-host one-pager with the group's own nine editions of measured numbers, unflattering or not",
"Says which kind each number is whenever one is quoted, rather than presenting a mixed list unlabelled",
"Tells the user to replace the baselines with the group's own trailing three-edition median now that nine editions exist"
]
},
{
"id": 5,
"prompt": "Our Vienna Scala meetup is in trouble. Last three door counts were 45, then 26, then 12. The last event was 118 days ago. I'm the only organizer left since Marek changed jobs. Repeat attendance was 18% the last time I checked. Our last sponsor did a 30-minute product demo because they paid for the drinks. My reset plan: book the 200-seat auditorium at the university, land a well-known keynote speaker, charge 10 euros a ticket so people actually show up, and rebrand as \"Scala Vienna Conf\". Thoughts?",
"expected_output": "The scale-up plan refused, the failing scorecard lines named against their thresholds, and an ordered repair starting with a co-organizer recruited from the regulars, then a fixed date and booked room before any speaker, a no-speaker fallback format, a published sponsor stage cap, and a holdable cadence.",
"files": [],
"expectations": [
"Refuses the bigger venue, the keynote and the rebrand as the reset, and says to fix the failing lines before adding any scale",
"Flags the 118-day gap as past CNCF's 90-day inactivity threshold",
"Flags that a single organizer is one job change from dead, and makes recruiting a second organizer the first action",
"Sources that second organizer from the remaining regulars rather than from an open public call",
"Gives the repair in order: recruit a co-organizer, fix a date and book the room, pick a no-speaker-needed fallback format, cap sponsor stage time, restart at a holdable cadence",
"Tells the user to fix the date and book the room before finding a speaker, not after",
"Names a fallback format that needs no external speaker, such as a study group, demo night or open space",
"Connects the 30-minute sponsor demo to the 18% repeat attendance as cause rather than coincidence",
"Caps sponsor stage time at 15 minutes or less, publishes the cap, and holds it",
"Marks 18% repeat attendance as failing against a 40% target and identifies that 40% as a baseline, not an industry figure",
"Declines to treat paid tickets as the no-show fix, pointing instead to overbooking, an auto-promoting waitlist and reminders",
"States that the restarted cadence must be one the remaining organizers can hold when tired, because a missed edition costs more trust than a slower cadence"
]
},
{
"id": 6,
"prompt": "Every month it's the same. Three weeks before our Manchester Go evening I start messaging people asking if anyone can talk. I've cancelled twice this year when nobody said yes. I post an open call on LinkedIn and in our Slack every month and get basically nothing back. Should I be posting earlier, or switching to a panel discussion whenever I can't find a speaker? We're at edition 19.",
"expected_output": "A standing speaker pipeline replacing the monthly plea: permanent CFP, direct named asks with a short slot, conference harvesting, neighbouring-group trades, lightning slots that manufacture future anchors, a board tracking two editions ahead, a no-speaker fallback format kept in the plan, and the panel-as-fallback rejected.",
"files": [],
"expectations": [
"Replaces the monthly open call with a standing call for proposals: a permanent form linked from every event page and every announcement",
"Explains that an open call only reaches people who already consider themselves speakers, so direct asks to named regulars convert far better",
"Scripts the direct ask around a short, named slot length, for example five minutes on what they built",
"Recommends harvesting speakers from regional conferences, because an already-given talk repeats locally with no new preparation",
"Says to ask conference speakers during or in the week of that conference, while it is fresh",
"Recommends trading speakers with neighbouring groups one city or one technology over, cross-promoting both audiences",
"Sets the pipeline target at two confirmed editions ahead",
"States the board's three states: two editions ahead is healthy, one ahead is a warning, zero ahead is a fire",
"Keeps a no-speaker-needed fallback format in the plan so a cancellation costs a format change rather than an edition",
"Rejects booking a panel because no speaker was found, naming it as a failure pattern rather than a fallback",
"Recommends a visible pipeline board tracking confirmed, provisional and prospect speakers per date",
"Recommends anchor + lightning so an edition needs one confirmed speaker instead of two, and so each lightning slot produces a candidate anchor speaker for a later edition"
]
},
{
"id": 7,
"prompt": "Nice problem to have: Trelix, a monitoring vendor, offered 3,600 euros to sponsor our Copenhagen Python meetup for a full year. Their terms are a 30-minute technical session at every edition given by their solutions architect, the RSVP list exported to them after each event so their SDR can follow up, and badge scanning at the door. That covers food for the whole year and I'd stop paying out of pocket. I was going to counter at 20 minutes and give them only the email addresses of people who tick a box on the RSVP form. Fair deal?",
"expected_output": "The bought slot refused outright rather than negotiated down, the attendee-list export refused including the tick-box subset, badge scanning made opt-in, the published stage cap applied, the sponsor's speaker routed through the normal content filter, and the cost-base risk of a year funded by one sponsor flagged.",
"files": [],
"expectations": [
"Refuses the guaranteed session in exchange for money outright, rather than negotiating its length down to 20 minutes",
"Quotes DevOpsDays' position that no speaker spots can be bought by sponsors, ever",
"Caps any sponsor stage time at 15 minutes as CNCF's published ceiling",
"Notes DevOpsDays holds its own sponsors to a shorter bar, a short elevator pitch on the order of a minute or two",
"Tells the user to pick a cap, publish it, and hold it rather than negotiating it per sponsor",
"Refuses to export the RSVP list, including the tick-box-filtered subset handed over by the organizers",
"States the sponsor earns contacts at their own table through an explicit opt-in, never through an organizer-supplied list",
"Rejects badge scanning as a default and makes it opt-in only",
"Routes Trelix's solutions architect through the same content review as any other speaker, with no guaranteed slot",
"Applies the code of conduct to sponsor staff, including recruiters",
"Warns that a year of food funded by one sponsor raises the cost base, so losing them would cost the group rather than one edition's food",
"Recommends stating the conduct rules in writing before accepting anything from Trelix",
"Recommends rotating venue and food hosts rather than binding a full year to a single sponsor"
]
},
{
"id": 8,
"prompt": "Situation at our Zurich Kafka meetup. Nomatic hosts us, their office, their pizza, every month for the last eight editions. Two of our three organizers work at Nomatic. Their head of product now wants a standing 25-minute slot each edition called \"What's new in Nomatic\" and says that's fair given they cover everything. Attendance is holding at 34-38 so I don't think it's actually hurting us. They send slides the morning of the event, sometimes not at all. How do I handle this?",
"expected_output": "The pitch filter applied with its repairs in order, the 25-minute standing slot cut to the published cap, slides required in advance, the organizer-employer concentration flagged against CNCF's 50% cap, one non-host speaker per edition required, venue rotation and season-length booking recommended, and flat attendance rejected as proof of health.",
"files": [],
"expectations": [
"Applies the pitch test: could this talk be given by someone who does not sell this product?",
"Gives the repairs in order of preference: reframe around the problem keeping the product as setting, move the product content into a short sponsor slot, decline",
"Cuts the slot to five minutes or to the published sponsor cap rather than leaving it at 25 minutes",
"Requires the title, the one-line takeaway and the slides in advance from every speaker including this one",
"Names the morning-of deck as how a group discovers on stage that the talk was a product demo",
"Flags that two of three organizers from Nomatic breaches CNCF's cap of 50% of an organizer team from any one company",
"Requires at least one speaker per edition with no stake in the host's product",
"Recommends rotating venue hosts rather than staying with Nomatic indefinitely",
"Books venue hosts a season at a time, roughly three editions, rather than a full year",
"Warns that a single host that also employs half the organizers turns the group into that company's user group whatever anyone intended",
"Rejects flat attendance of 34-38 as evidence the arrangement is harmless, and points at repeat attendance and new faces as the signals that move first",
"Notes that regulars who stop coming over this will not say why",
"Recommends publishing the stage-time cap so it applies to Nomatic identically to any other sponsor"
]
},
{
"id": 9,
"prompt": "Our Sao Paulo Kubernetes group pulls 40-55 people every month and has for a year. But the same four people do everything: me, two friends who help at the door, and one guy who always volunteers to speak. Everyone else shows up, eats, and leaves. My board wants a plan to convert the lurkers, so I was thinking a points system, badges for attending three in a row, and a leaderboard on our site. What would you do?",
"expected_output": "The 90% lurker share normalised against Nielsen's participation inequality, the gamification plan rejected, and the attendee-to-co-organizer ladder given with each rung recruited from the one below, mapped onto the Orbit Model with its status noted, plus direct asks, real volunteer ownership and public co-organizer recruitment and exit.",
"files": [],
"expectations": [
"States that roughly 90% lurking is normal rather than a failure of the program, citing Nielsen's 90-9-1 participation inequality",
"Dates the 90-9-1 finding to 2006",
"Reframes the goal away from converting lurkers and toward lowering the barrier to the next rung",
"Rejects the points system, the badges and the leaderboard as the intervention",
"Gives the ladder as attendee, regular, lightning speaker, volunteer, co-organizer",
"States each rung is recruited from the one directly below it",
"Maps the ladder onto the Orbit Model's four levels: Explorers, Participants, Contributors, Advocates",
"Gives Orbit's gravity definition as love multiplied by reach",
"Notes Orbit was published in 2019 and is no longer actively developed, citing it as a stable framework rather than a live product",
"Recommends asking named regulars directly, for example whether they would do five minutes on what they built, instead of an open call",
"Gives volunteers one or two real ownership areas each, such as food, A/V, emcee or socials, rather than ad-hoc help",
"Recruits co-organizers publicly and on a low bar, approved when at least half the current organizers say yes",
"Handles organizer departures publicly too, so a silent exit does not leave a ghost owner on the group's accounts"
]
},
{
"id": 10,
"prompt": "It's just me and my colleague Priya running a new AI infrastructure meetup in Bangalore. We did edition one last week, 34 people through the door, it went great. We're both hyped and want to go weekly to build momentum while the energy is there. We have nobody lined up past edition two. If weekly turns out to be too much we figured we'd just run it whenever we happen to find a good speaker. Also should we alternate weekdays so more people can make at least one?",
"expected_output": "Weekly rejected for a two-person team with no pipeline, speaker-driven scheduling rejected as cadence collapse, a single fixed recurring slot recommended over alternating days, and CNCF's published cadence thresholds given: monthly ideal, 90-day inactivity, six meetings a year, quarterly with more than 10 attendees.",
"files": [],
"expectations": [
"Rejects weekly as the cadence for a two-person team with no speaker pipeline",
"Rejects \"whenever we find a speaker\" as a cadence and names it as how a cadence collapses",
"Tells them to fix the slot, book the room, then fill the program, rather than letting the speaker set the date",
"Rejects alternating weekdays and recommends a single recurring predictable slot such as second Tuesday at 19:00",
"Explains that a fixed slot becomes a habit and removes one decision per edition",
"Gives CNCF's Tuesday-to-Thursday evening after-work default, adjusted to local culture",
"Names CNCF's ideal cadence as monthly",
"Names CNCF's inactivity threshold: more than 90 days between events marks a chapter inactive",
"Names CNCF's minimum of at least six meetings per calendar year for technical groups",
"Names CNCF's active-status bar as a quarterly event with more than 10 attendees, and states that the figure counts attendees rather than registrations",
"States that below quarterly a group has occasional events rather than a program",
"Warns that a missed edition costs more trust than a slower cadence, so they should not commit to monthly until the pipeline supports it"
]
},
{
"id": 11,
"prompt": "I need something to put in front of my manager on Monday. It's a new meetup for our platform team's open-source project, first edition in Lisbon in October. Give me the full twelve-month programme, all twelve dates with the topic and speaker for each, plus which sponsor covers which month. Please don't ask me questions, just produce it and I'll correct whatever's wrong.",
"expected_output": "A refusal to invent twelve editions, the gating interview run one question at a time before any format is proposed, and the deliverables produced in order starting with a charter naming exactly one SPACES outcome, an edition plan only three deep with everything beyond marked provisional, plus pipeline board, edition log skeleton and a scorecard baseline reading \"not measured yet\".",
"files": [],
"expectations": [
"Refuses to invent twelve editions of topics, speakers and sponsors",
"Plans three editions deep and marks everything beyond edition three as provisional",
"Asks the gating interview questions before proposing a format, rather than producing a format on no information",
"Asks one question at a time, multiple-choice where possible",
"Produces the program charter first, before any edition plan",
"Names exactly one primary outcome in the charter, not a list",
"Uses CMX's SPACES model as the vocabulary for that single outcome because a company hosts, following its instruction to focus on one objective when starting out",
"Delivers the artefacts in order: charter, three-edition plan, speaker pipeline board, edition log skeleton, scorecard baseline",
"Gives the edition plan the columns date, format, speaker status, venue, sponsor status and promotion dates",
"Fills the scorecard baseline with \"not measured yet\" where the group has no numbers, rather than inventing values",
"Presents the charter section by section and gets each validated before moving on",
"Offers to store the charter, the venue and sponsor contacts and the edition log in persistent memory, gated on whether that capability is available"
]
},
{
"id": 12,
"prompt": "Draft the announcement for the next Lisbon Rust evening. Here's the copy I had in mind: \"Rust Lisbon is back! Free pizza and beer at Vantix's beautiful new office in Cais do Sodre, sponsored by Vantix. Come network with the community! Doors 18:30.\" We're about 95% sure Ana Ferreira will do a talk on async runtimes, I'll confirm with her this week but I want to post tomorrow. Also what reminders should I be sending?",
"expected_output": "A rewritten announcement led by speaker and topic with a concrete takeaway, food and venue demoted to logistics, the sponsor out of the headline, the unconfirmed speaker not announced, an open lightning slot included, and the five-message reminder schedule with the release-your-spot request at two hours out.",
"files": [],
"expectations": [
"Rewrites the announcement to lead with the speaker and the topic rather than the pizza or the venue",
"Demotes food to a logistics line instead of the headline",
"Removes the sponsor from the headline, keeping them to a listing credit and a thank-you from the stage",
"Removes \"come network with the community\" as the stated reason to attend",
"Refuses to announce Ana Ferreira before she is confirmed, and states that a retracted headline costs more trust than a late announcement",
"Includes a concrete takeaway for the talk, not just its title",
"Includes complete logistics: date, start and end time, address, door time, RSVP requirement and room capacity",
"Adds an open lightning slot to the announcement so this month's post recruits next month's speaker",
"Gives the reminder schedule as announcement 3-4 weeks out, one week out, two days out, two hours out, and a day-after message",
"Puts the practical detail (address, door code, start time, food) in the two-days-out reminder and names it as the one that actually moves attendance",
"Puts the release-your-spot request in the two-hours-out reminder",
"Sends slides, recording and the next date in the day-after message",
"Names the speaker's own network as the highest-yield promotion channel and asks Ana to share the slot once confirmed"
]
}
],
"trigger_queries": [
{ "query": "we want to start a Rust meetup in Lyon", "should_trigger": true },
{ "query": "how do I start a user group for our database?", "should_trigger": true },
{ "query": "attendance dropped from 40 to 12, what do we do", "should_trigger": true },
{ "query": "our monthly dev evening is dying and I don't know why", "should_trigger": true },
{ "query": "I need a format that doesn't need two speakers every month", "should_trigger": true },
{ "query": "write the sponsor ask for a venue", "should_trigger": true },
{ "query": "how do I find a company that'll host our evening and pay for pizza", "should_trigger": true },
{ "query": "I'm burning out running this alone, how do I bring in co-organizers", "should_trigger": true },
{ "query": "how often should our group meet?", "should_trigger": true },
{ "query": "half our RSVPs never turn up", "should_trigger": true },
{ "query": "60 people signed up and 22 came, how much food do I order next time", "should_trigger": true },
{ "query": "we need a new speaker every single month and I'm exhausted", "should_trigger": true },
{ "query": "how do I get regulars to actually give talks", "should_trigger": true },
{ "query": "should we run a hands-on workshop every month?", "should_trigger": true },
{ "query": "our sponsor wants 30 minutes on stage, is that normal", "should_trigger": true },
{ "query": "a sponsor asked for the attendee list, what do I tell them", "should_trigger": true },
{ "query": "how do I hand over the group before I leave the company", "should_trigger": true },
{ "query": "nobody talks to each other at our events", "should_trigger": true },
{ "query": "how do we get people to come back a second time", "should_trigger": true },
{ "query": "what should our announcement actually say", "should_trigger": true },
{ "query": "we run a GDG chapter and attendance has gone flat", "should_trigger": true },
{ "query": "our company wants to run developer evenings in five cities", "should_trigger": true },
{ "query": "should the vendor run it or should local volunteers?", "should_trigger": true },
{ "query": "we want to do local events", "should_trigger": true },
{ "query": "planning the very first edition of our community evening", "should_trigger": true },
{ "query": "how many people is a decent turnout for a first one", "should_trigger": true },
{ "query": "we keep cancelling whenever the speaker drops out", "should_trigger": true },
{ "query": "what do we do when a speaker cancels three days before", "should_trigger": true },
{ "query": "all our talks are from our own engineers, is that a problem", "should_trigger": true },
{ "query": "we haven't had an event in four months, is the group dead", "should_trigger": true },
{ "query": "how do I write down the rules for what our group won't do", "should_trigger": true },
{ "query": "second Tuesday or last Thursday?", "should_trigger": true },
{ "query": "should we charge for tickets to stop no-shows", "should_trigger": true },
{ "query": "our group has basically become one company's user group", "should_trigger": true },
{ "query": "help me plan a recurring evening for backend engineers in Porto", "should_trigger": true },
{ "query": "what should I track to know if the group is healthy", "should_trigger": true },
{ "query": "we want to grow from an evening into a half-day", "should_trigger": true },
{ "query": "how do I recruit a second organizer", "should_trigger": true },
{ "query": "someone wants to speak but it's clearly a product pitch", "should_trigger": true },
{ "query": "should I ask for the slides before the event?", "should_trigger": true },
{ "query": "how do I make first-timers feel welcome on the night", "should_trigger": true },
{ "query": "what's a good run of show for a two-hour evening", "should_trigger": true },
{ "query": "how do I convince a company to lend us a room after work", "should_trigger": true },
{ "query": "we get 90 RSVPs but the room only holds 50", "should_trigger": true },
{ "query": "how do the three of us split the organizing work", "should_trigger": true },
{ "query": "our online channel is active but the in-person evenings are empty", "should_trigger": true },
{ "query": "I want to build a speaker bench out of our own audience", "should_trigger": true },
{ "query": "what's a lightning talk night and should we try one", "should_trigger": true },
{ "query": "we want to trade speakers with the group in the next city", "should_trigger": true },
{ "query": "is paying for Meetup.com worth it for our group", "should_trigger": true },
{ "query": "how do we choose where to list our recurring event", "should_trigger": true },
{ "query": "attendance is fine but there are never any new faces", "should_trigger": true },
{ "query": "how do I stop being the only person who can run the evening", "should_trigger": true },
{ "query": "we're a two-person team, what can we realistically commit to", "should_trigger": true },
{ "query": "our organizer left and we've lost access to the mailing list", "should_trigger": true },
{ "query": "how do we keep the group alive between editions", "should_trigger": true },
{ "query": "what goes in a one-page document describing what our group is", "should_trigger": true },
{ "query": "we've done three editions, what should I be measuring by now", "should_trigger": true },
{ "query": "our venue host wants to pitch their product at every event", "should_trigger": true },
{ "query": "how do I ask a conference speaker to repeat their talk locally", "should_trigger": true },
{ "query": "I want the people who come to eventually help run it", "should_trigger": true },
{ "query": "what's a realistic cadence for volunteers with day jobs", "should_trigger": true },
{ "query": "our evenings feel like a room full of strangers", "should_trigger": true },
{ "query": "the company that hosts us employs most of the organizers", "should_trigger": true },
{ "query": "how do I set up a standing call for talk proposals", "should_trigger": true },
{ "query": "planning a monthly Kubernetes evening in Warsaw", "should_trigger": true },
{ "query": "what food do we need to provide at our evenings", "should_trigger": true },
{ "query": "this group has run for two years, how do I make it survive me", "should_trigger": true },
{ "query": "how many organizers should a local group have", "should_trigger": true },
{ "query": "help me submit a talk to KubeCon's CFP", "should_trigger": false },
{ "query": "write my conference talk proposal abstract", "should_trigger": false },
{ "query": "structure my 30-minute conference talk", "should_trigger": false },
{ "query": "my live demo keeps failing on stage, how do I de-risk it", "should_trigger": false },
{ "query": "should we buy a booth at a developer conference", "should_trigger": false },
{ "query": "we have $40k for conference sponsorships this year, which tier do we take", "should_trigger": false },
{ "query": "launch a Discord for our open-source project", "should_trigger": false },
{ "query": "our Slack community has 5,000 members and nobody posts", "should_trigger": false },
{ "query": "someone is being abusive in our community forum", "should_trigger": false },
{ "query": "set up a champions program for our top users", "should_trigger": false },
{ "query": "write release notes for v3.2", "should_trigger": false },
{ "query": "our quickstart takes 40 minutes, fix it", "should_trigger": false },
{ "query": "how should I structure our documentation site", "should_trigger": false },
{ "query": "plan our devrel budget for next year", "should_trigger": false },
{ "query": "what metrics should devrel report to the CEO", "should_trigger": false },
{ "query": "how big should our devrel team be", "should_trigger": false },
{ "query": "I want to move from engineering into devrel", "should_trigger": false },
{ "query": "write a job description for a developer advocate", "should_trigger": false },
{ "query": "build our devrel content calendar for Q3", "should_trigger": false },
{ "query": "which podcasts and newsletters should I follow in devrel", "should_trigger": false },
{ "query": "write an engineering blog post about our new scheduler", "should_trigger": false },
{ "query": "optimize our README for GitHub", "should_trigger": false },
{ "query": "we're launching an open-source project next month", "should_trigger": false },
{ "query": "which license should we pick for our library", "should_trigger": false },
{ "query": "how do we onboard first-time contributors", "should_trigger": false },
{ "query": "set up governance for our open-source project", "should_trigger": false },
{ "query": "our GitHub issue tracker has 800 open issues", "should_trigger": false },
{ "query": "find companies to sponsor our project on GitHub Sponsors", "should_trigger": false },
{ "query": "should we go open-core or source-available", "should_trigger": false },
{ "query": "price the tiers for our developer tool", "should_trigger": false },
{ "query": "make our docs easier for coding agents to consume", "should_trigger": false },
{ "query": "write a migration guide for our v2 to v3 breaking changes", "should_trigger": false },
{ "query": "keyword research for our developer docs", "should_trigger": false },
{ "query": "how do we segment our developer audience", "should_trigger": false },
{ "query": "map the developer journey from first visit to first deploy", "should_trigger": false },
{ "query": "write a customer case study with one of our users", "should_trigger": false },
{ "query": "prep me for a podcast interview next week", "should_trigger": false },
{ "query": "pitch our launch to the tech press", "should_trigger": false },
{ "query": "script a five-minute product demo video", "should_trigger": false },
{ "query": "make our careers page appeal to engineers", "should_trigger": false },
{ "query": "build a certification program for our platform", "should_trigger": false },
{ "query": "what's our ecosystem strategy for integration partners", "should_trigger": false },
{ "query": "write a tutorial for our SDK", "should_trigger": false },
{ "query": "our troubleshooting docs don't cover the common errors", "should_trigger": false },
{ "query": "should we publish our revenue numbers publicly", "should_trigger": false },
{ "query": "standardize the code samples across our docs", "should_trigger": false },
{ "query": "how do we rank our docs pages in Google", "should_trigger": false },
{ "query": "optimize my personal GitHub profile README", "should_trigger": false },
{ "query": "which distribution channels for our CLI: homebrew, apt, npm", "should_trigger": false },
{ "query": "should we push our spec through a standards body", "should_trigger": false },
{ "query": "analyze what our competitor's devrel team is doing", "should_trigger": false },
{ "query": "we're running a 600-person conference next spring, build the timeline", "should_trigger": false },
{ "query": "design the CFP form for our conference", "should_trigger": false },
{ "query": "price our conference sponsorship tiers", "should_trigger": false },
{ "query": "write the sponsor prospectus for our conference", "should_trigger": false },
{ "query": "find a venue for a 400-person two-day conference", "should_trigger": false },
{ "query": "pick the date for our annual conference", "should_trigger": false },
{ "query": "our conference has 30% no-shows on paid tickets", "should_trigger": false },
{ "query": "design the schedule tracks for our two-day event", "should_trigger": false },
{ "query": "run the debrief after our conference", "should_trigger": false },
{ "query": "write the code of conduct for our conference", "should_trigger": false },
{ "query": "build the run of show for the main stage", "should_trigger": false },
{ "query": "how should we price conference tickets", "should_trigger": false },
{ "query": "recruit and manage 60 volunteers for our conference", "should_trigger": false },
{ "query": "design a hackathon brief", "should_trigger": false },
{ "query": "plan the after-party and side events around our conference", "should_trigger": false },
{ "query": "make our conference accessible: captioning, childcare, quiet room", "should_trigger": false },
{ "query": "design our virtual event production setup", "should_trigger": false },
{ "query": "cold outreach to keynote speakers for our conference", "should_trigger": false }
]
}
references/evidence-and-benchmarks.md›
# Evidence and benchmarks
Contents: sourced figures · baselines set by this skill · what to verify before quoting · how to replace a baseline.
Every number used anywhere in this skill appears here once, with where it came from. Quote a sourced figure externally (to a sponsor, a manager, a venue host). Never quote a baseline externally as an industry standard - say "our target" instead.
## Sourced figures
| Figure | Value | Source |
| ---------------------------------------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| No-show planning ratio | ~30% of RSVPs | CNCF Community Groups best practices |
| Inactivity threshold | >90 days between events marks a chapter inactive | CNCF Community Groups |
| Minimum annual meetings | ≥6 per calendar year (technical community groups) | CNCF Community Groups |
| Active-chapter attendance bar | Quarterly event with >10 _attendees_, not registrations | CNCF Community Groups |
| Content block length | 1-2 hours of content plus networking | CNCF Community Groups |
| Default slot | Tuesday-Thursday evening, after work, adjusted locally | CNCF Community Groups |
| Sponsor stage-time cap | ≤15 minutes | CNCF Community Groups |
| Sponsor pitch length at a community conference | "a short elevator pitch … generally in the order of a minute or two" | DevOpsDays organizing pages |
| Bought speaking slots | "no speaker spots can be bought by sponsors: not ever - period" | DevOpsDays |
| Attendee data | "devopsdays does not ever distribute attendee contact information" | DevOpsDays |
| Organizer team minimum | ≥2 organizers with divided responsibilities; ≤50% from one company; max 5 (virtual) / 7 (in-person) | CNCF Community Groups |
| Organizer team minimum, conference scale | ≥3 people from different organizations; "not about lead generation" | DevOpsDays |
| Organizer add/remove process | Public issue, approved at ≥50% of current organizers in favor; departures also public | CNCF Community Groups |
| Half-day step-up shape | ~4 hours, multiple speakers, catering breaks, at most quarterly | CNCF meetups-vs-community-day guidance |
| Community levels | Explorers → Participants → Contributors → Advocates; gravity = love × reach | Orbit Model (published 2019, no longer actively developed) |
| Participation inequality | 90% lurk, 9% contribute occasionally, 1% produce most activity | Jakob Nielsen, 2006 |
| Single-outcome rule for a company program | "If you're starting out, just focus on one objective from the SPACES Model" | CMX SPACES model |
| Oldest surviving vendor user group | SHARE, founded 1955, IBM mainframe corporate users | Wikipedia, _User group_ |
| Vendor-backed chapter network at scale | HashiCorp User Groups: 50,000 members, 184 groups, 64 countries | hashicorp.com/community (vendor's own figures) |
| Centrally-staffed company series | CMX Circuit Tour - company staff run each city stop | cmxhub.com |
## Baselines set by this skill
Each of these is a designed gate, chosen to be checkable and to fail loudly, rather than a figure measured across a population of real meetups.
| Baseline | Value | Why this value |
| -------------------------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Show-up rate | ≥70% | The direct complement of CNCF's ~30% no-show figure; it is arithmetic on a sourced number, not an independent finding |
| Repeat attendance | ≥40% of the door | Below it, the room is a churn funnel; the exact cut is a judgment call |
| New faces | >0 every edition | A group with zero newcomers is closing in on itself, whatever its total |
| Speakers sourced from the room | ≥1 in 3 | Deliberately ambitious: Nielsen's 1% contributor rate says this only happens with active recruiting |
| Editions with confirmed speakers | ≥2 ahead | One edition of buffer absorbs a single cancellation; zero means every month starts from nothing |
| Pipeline board states | Confirmed / provisional / prospect | Vocabulary, not a benchmark |
| First edition size | 10-15 attendees is a real start | Anchored to CNCF's >10-attendee bar, then rounded into a planning range |
| Venue booking horizon | One season (≈3 editions) at a time | Trades continuity against dependence on one host |
| Cost per edition in the worked example | ~€250, food only | Illustrative of a European city, not a survey result |
Calibrate every baseline against the group's own trailing three editions as soon as three exist. A measured local rate always beats an imported one.
## Verify before quoting
Treat each of the following as unknown until the user or the program's own organizer material settles it.
- **Listing-platform pricing and tiers** (Meetup.com dues, Luma Plus). Public list prices found via search: Meetup Standard from $29.99/month ($99.99/6 months), Meetup Pro from $55/month ($47/6 months); Luma Plus $59/month billed annually (0% platform fee, versus 5% on Luma's free tier). Confirm inside an active organizer account before quoting a final number - both note that price can vary by region, currency and signup channel (web vs. iOS/Android).
- **Google Developer Groups mechanics, now readable via search despite client-side rendering blocking direct fetch**: new-chapter applicants must check the GDG Chapter Directory for an existing chapter in their area first, then review organizer acknowledgements, a code of conduct and official naming guidelines before applying; strict brand rules govern logo spacing/distortion, color palette and typography (Google Sans). Internal budget ownership is not addressed in the public organizer material. AWS User Groups mechanics remain unread - read that program's own organizer pages instead of assuming it matches the HashiCorp or GDG models.
- **Budget ownership for a company-hosted program** (DevRel versus marketing versus field). Ask the user rather than asserting a norm.
- **Any no-show figure above 30%.** Plan against CNCF's ~30%; the 40-50% repeated for free evening events is hearsay, with no organization standing behind it.
## How to replace a baseline
1. Log door count, RSVP count, repeat attendance and new faces for three consecutive editions.
2. Take the median, not the mean - one great edition skews a mean and hides a trend.
3. Set the target one step above the median, and re-read it after another three editions.
4. Record in the charter that the number is now measured locally, with the editions it came from. A target with no stated origin gets argued about every time it is missed.
references/format-catalog.md›
# Format catalog and run of the evening
Contents: format menu · recurring effort per format · run of a standard evening · first edition · step-up formats.
## Format menu
The ranking lives in `SKILL.md` Step 3 - efficiency: `anchor + lightning > study group > two-talk classic > open space > hands-on workshop`. This table extends that menu with five variants; each sits beside the ranked format it resembles, so read the recurring-effort column against that order rather than as a second ranking.
| Format | Shape | Recurring effort | Best for |
| -------------------------- | ------------------------------------------- | ----------------------------------------------- | ------------------------------------------- |
| Anchor + lightning | 1 × 25 min + 3 × 5 min | One speaker, plus volunteers from the room | Growing a speaker bench |
| Lightning night | 5-8 × 5 min | Many low-stakes asks, no anchor to confirm | Restarting a stalled group; end of year |
| Ignite | 5 min, 20 auto-advancing slides at 15s each | Same asks as lightning, higher prep per speaker | A group that already enjoys lightning talks |
| Demo night / show-and-tell | 6-10 min per project, no slides required | Attendees present their own work | Maker-heavy rooms, hobbyist audiences |
| Study group | Group works through a book, course or spec | No external speaker, near-zero prep | Small or new groups, quiet months |
| Two-talk classic | 2 × 20-30 min + Q&A | Two speakers per edition, every edition | Established group with a full pipeline |
| Panel | 3-4 guests, one moderator | One good moderator, four calendars | Contentious topics; never as a default |
| Live podcast / interview | 30-40 min on stage, recorded | One guest, one host, plus editing after | Groups with an existing media surface |
| Open space | Attendees propose sessions on the night | None | Rooms where people already know each other |
| Hands-on workshop | 60-90 min, laptops required | One facilitator, a week of preparation | Deep engagement, small rooms, tool adoption |
Two failure patterns worth naming:
- A panel booked because no speaker was found: four people saying little beats one person saying something - untrue.
- A workshop scheduled monthly by a two-person team: prep cost breaks the cadence within a quarter.
## Run of a standard 2-hour evening
| Time | Block | Notes |
| ----- | ------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| 18:30 | Doors, food, informal networking | Nothing starts on time; plan for it rather than fighting it |
| 19:00 | Welcome, 5 min | Group intro, code of conduct in one sentence, first-timers wave, sponsor thanks, next date announced |
| 19:05 | Talk 1, 25 min + 5 min Q&A | The stronger or more accessible talk goes first - latecomers are still arriving |
| 19:35 | Break, 15 min | Real break. This is where people meet each other; cutting it to save time defeats the evening |
| 19:50 | Talk 2 or lightning slots, 25-30 min | |
| 20:20 | Wrap, 5 min | Feedback QR code on screen, call for speakers, call for venues, next date again |
| 20:25 | Networking until the venue closes | Announce the hard stop; venues have one |
Announce the next date twice from the stage. The single cheapest retention mechanic available is the room leaving with a date in their calendar.
## First edition
Strip it to the minimum viable event: one speaker, one room, drinks, a fixed date for the second edition announced from the stage. Ten to fifteen attendees is a real start - CNCF's active-chapter bar is a quarterly event with more than ten people through the door. Do not open with a two-track afternoon.
## Step-up formats
When the monthly evening is consistently full, the next rung is a half-day: roughly four hours, multiple speakers, catering breaks, and real sponsorship - and at most once a quarter, alongside the normal rhythm rather than replacing it. That is where the effort curve changes: full-day and multi-day production is a different discipline, covered by samber/dev-event-organizer-skills.
references/host-model-variants.md›
# Host model variants
Contents: the three host models compared · what changes per model · B2D versus developer-plus audiences · listing-platform considerations · a negative example.
## The three models
Vendor-affiliated user groups are the older tradition, not a later corruption of an independent one: SHARE (1955) and DECUS (1961) were corporate-user groups decades before the volunteer hobbyist chapter became common. Read the three models as different contracts with the room, not as a maturity ladder.
| | Independent, vendor-neutral | Vendor-backed volunteer chapter | Company-staffed series |
| ---------------------------- | --------------------------------- | ------------------------------------------------------ | --------------------------------------------------------- |
| Who runs the evening | Local volunteers | Local volunteers | Company staff |
| Who owns the brand | The group | The vendor | The company |
| Program control | Organizers, no vendor veto | Organizers, within vendor guidelines | Company |
| Typical money | In-kind venue and food | In-kind, plus vendor swag and speaker access | Company budget line |
| Named example | CNCF Community Groups, DevOpsDays | HashiCorp User Groups (50,000 members, 184 groups) | CMX Circuit Tour |
| Main risk | Organizer burnout, no safety net | Chapter reads as marketing if the vendor over-programs | No local ownership; the series stops when the budget does |
| Non-host speaker per edition | Structural requirement | Strongly advised | The only defense against a customer-only room |
## What changes per model
**Independent.** Neutrality is the product. CNCF caps organizer teams at 50% from any one company and escalates neutrality complaints: written warning, then a community meeting, then disabling the chapter.
Sponsors buy logistics, never airtime. A competitor on stage is a feature.
**Vendor-backed.** The vendor supplies branding, a listing platform, sometimes travel for speakers. The organizer's job is to keep the program interesting to people who have not yet bought anything: mix ecosystem and adjacent-technology talks in, and keep the vendor's own staff to a minority of slots across a quarter, not per evening.
**Company-staffed.** Consistency is the upside; the downside is that nobody in the room has a reason to protect it. Compensate deliberately: a local co-host with real program input, an advisory group of regulars, and a stated policy on what the company will not do from the stage. Budget ownership inside the company (DevRel, marketing, or field) is not a settled norm - ask, and write the answer into the charter, because it decides who can cancel the series.
## B2D versus developer-plus audiences
Two company shapes run developer programs for different reasons, and the meetup's topic strategy follows.
- **Developer-first (B2D)** - the product is sold to developers; the attendee evaluating the API is frequently the person who requisitions it. Product-adjacent topics carry little tension, and adoption is a defensible primary outcome.
- **Developer-plus** - a B2B or B2C business that also exposes products to developers. The attendee is one segment of a much larger buying org and rarely the decision-maker, so the program justifies itself as brand and ecosystem investment. Topics skew to the platform ecosystem rather than the core product.
The operational mechanics on either side (topic-selection process, recruiting channels, employer buy-in tactics) are not documented in any source found for this skill - derive them with the user rather than asserting a standard.
## Listing-platform considerations
Stay tool-independent in the plan; choose the platform on these properties rather than on a brand.
- **Recurring-event support** - can a monthly slot be cloned with its settings, or is every edition set up from scratch?
- **Group-level versus event-level audience** - some platforms hold members at the calendar/group level, which means the audience survives a cancelled edition; others only hold per-event RSVPs.
- **Waitlist with auto-promotion** - required to make overbooking work.
- **Export of the member list** - if the organizers cannot export, the group cannot leave.
- **Fees** - some platforms charge organizer dues; treat any quoted price as unverified until confirmed inside a live organizer account.
- **Discovery** - whether people who are not already following the group can find the event at all.
Two live examples for orientation only, both with unverified pricing:
- Meetup.com runs a paid organizer subscription and gates the details behind an account.
- Luma is calendar-centric, supports event cloning, tags and calendar-level memberships, and documents workarounds rather than native recurrence.
## Negative example: the model nobody named
Constructed for illustration - a composite of the failure pattern, not a transcript of one named group.
> A vendor's DevRel team launches "the <Product> User Group" in four cities. Each evening is two talks by company engineers plus a roadmap update. Local "organizers" are volunteers recruited to book rooms, with no say in the program. Attendance is strong for three editions, then halves; the volunteers stop replying.
Three failures, all from leaving the model implicit:
- The room was told "user group" (independent) and given a company-staffed series.
- The volunteers were given the workload of organizers and the authority of helpers.
- No edition had a speaker without a stake in the product, so once the roadmap was known there was no reason to return.
The repair is to pick one model and say it out loud: either give the volunteers program control and one guaranteed non-company slot per edition, or drop the "user group" framing and run it as the company event series it actually is.
references/program-charter-template.md›
# Program charter, edition log and scorecard
Contents: charter template · filled example · edition log · healthy scorecard · failing scorecard read line by line.
## Charter template
```markdown
# <Group name>
**Room:** who attends - technology, seniority, work-time or own-time
**Host model:** independent vendor-neutral | vendor-backed volunteer chapter | company-staffed series (name the company)
**Purpose:** the one outcome that justifies the effort in a year - exactly one, named in SPACES terms if a company hosts
**Format:** default format, plus the no-speaker fallback format
**Rhythm:** fixed slot (e.g. second Tuesday, 19:00), cadence, months off
**Program decisions:** who selects talks, and on what test
**Organizers:** names, employers, area owned by each
**Venue:** current host, booked through <date>
**Money:** what is spent per edition, who pays, who signs
**We don't:** the explicit refusals (bought slots, attendee lists, recruiter pitches from stage…)
**Accounts:** listing, mailing list, socials - who has access (at least two people each)
```
## Filled example
```markdown
# Nantes Go Meetup
**Room:** backend engineers using Go in production, mid to senior, attending after work
**Host model:** independent vendor-neutral; venue rotates between three local companies
**Purpose:** a local Go hiring and hallway network - people who can call each other about production problems
**Format:** anchor talk (25 min) plus two lightning slots; fallback is a demo night
**Rhythm:** second Tuesday, 19:00. Ten editions a year, off in August and December
**Program decisions:** two organizers review title, takeaway and slides; the test is "could a non-vendor give this talk?"
**Organizers:** Camille (program, employer A), Théo (venue and sponsors, employer B), Sofia (comms and door, employer C)
**Venue:** employer B through November
**Money:** ~€250 per edition, food only, paid by the venue host of the month
**We don't:** sell speaking slots, share the attendee list, allow recruiting from the stage
**Accounts:** listing and socials shared between Camille and Sofia; mailing list on a group address
```
## Edition log
One row per edition, filled the evening it happens. The trend is the product; a single row is noise.
| # | Date | Format | Speakers | RSVP | Door | Repeat % | New faces | Notes |
| --- | ------ | ------------------ | ------------------ | ---- | ---- | -------- | --------- | ------------------------------------------------------------------- |
| 14 | 11 Mar | Anchor + lightning | Rossi, 2 lightning | 62 | 41 | 46% | 9 | Both lightning speakers were first-timers from the room |
| 15 | 8 Apr | Two-talk | Chen, Diallo | 58 | 38 | 51% | 6 | Projector adapter missing; buy a kit |
| 16 | 13 May | Demo night | 6 attendees | 44 | 35 | 63% | 3 | Fewest new faces in six months - promote outside the usual channels |
## Healthy scorecard
| Line | Value | Verdict |
| ---------------------------------- | ------------ | ---------------------------------------------- |
| Gap since last edition | 33 days | Pass |
| Editions with confirmed speakers | 2 | Pass |
| Door attendance trend (3 editions) | 41 → 38 → 35 | Watch - flat-to-down, act before it is a trend |
| Repeat attendance | 63% | Pass |
| New faces | 3 | Watch - reach is narrowing |
| Organizers / employers | 3 / 3 | Pass |
| Sponsor stage time | 0-10 min | Pass |
Read: the group is healthy internally and closing in on itself. The fix is outward promotion - neighboring groups, universities, a topic outside the core clique - not another format change.
## Failing scorecard
| Line | Value | Verdict |
| -------------------------------- | ------------------- | ---------------------------------------------------- |
| Gap since last edition | 118 days | Fail - past the 90-day line; the program has stopped |
| Editions with confirmed speakers | 0 | Fail - every edition starts from zero |
| Door attendance trend | 45 → 26 → 12 | Fail |
| Repeat attendance | 18% | Fail - a churn funnel, not a community |
| Organizers / employers | 1 / 1 | Fail - one job change from dead |
| Sponsor stage time | 30 min product demo | Fail - explains the repeat rate |
Read: do not schedule a bigger event to fix this. In order:
1. Recruit a second organizer from the remaining regulars.
2. Fix a date and book the room before finding a speaker.
3. Pick a fallback format that needs no external speaker.
4. Cap sponsor time at 15 minutes and say so publicly.
5. Restart at a cadence the pair can actually hold.
references/promotion-and-no-show-plan.md›
# Promotion and the no-show plan
Contents: overbooking arithmetic · reminder schedule · promotion channels · announcement examples, weak and strong · what not to promote.
## Overbooking arithmetic
Plan on roughly 30% no-shows (CNCF's published planning figure) until the group has three editions of its own door counts.
| Room capacity | RSVP cap at 30% no-show | Food ordered for | Notes |
| ------------- | ----------------------- | ---------------- | ----------------------------------------------------------------------------- |
| 30 | 42 | 30 | Small room; overbooking beyond capacity risks turning people away at the door |
| 50 | 71 | 50 | Standard evening |
| 80 | 114 | 80 | Above this, a microphone and a second organizer at the door are needed |
Two rules keep the arithmetic honest:
- **Order food on expected attendance, never on RSVPs.** The single most common budget mistake at meetup scale is catering the registration list.
- **Cap the RSVP list at the venue's real capacity if the ratio pushes it past what the room can seat.** A waitlist that auto-promotes is safer than a queue outside the door.
Recalculate after three editions using the group's own median show-up rate. A group with paid-ish signals (a strong topic, a well-known speaker, a habit-forming slot) routinely beats 70%; a group announcing a week out on a single channel does not.
## Reminder schedule
| When | Message | Purpose |
| --------------------------- | ----------------------------------------------------------------------------- | ----------------------------------------------------------- |
| Announcement, 3-4 weeks out | Speaker, topic, takeaway, date, venue | Reach people who plan their evenings |
| 1 week out | Same, plus "still a few seats" or "waitlist open" | Second wave, and the waitlist signal raises perceived value |
| 2 days out | Practical detail: address, door code, start time, food | The reminder that actually moves attendance |
| 2 hours out | One line, plus "can't make it? release your spot for someone on the waitlist" | Frees seats and produces an accurate headcount |
| Day after | Thanks, slides, recording, next date | Converts an attendee into a returning one |
Ask people to release a spot rather than guilting them about cancelling. Framing it as freeing a seat for someone else works; the same request framed as a rebuke produces silent no-shows.
## Promotion channels
Ranked by yield for a local developer group:
1. The speaker's own network - a speaker who shares their slot brings their audience.
2. The group's own listing and mailing list.
3. Neighboring meetups in the same city (cross-promotion, not competition).
4. Local community Slack/Discord servers where the audience already talks.
5. Company internal channels of the venue host - usually the largest single burst, and the one that skews the room toward one employer.
6. Local newsletters, university labs, coworking spaces.
## Announcement examples
**Weak:**
> 🍕 Meetup this Tuesday at Acme's office! Free pizza and drinks, come hang out with the community. Doors at 18:30. RSVP on the group page.
The food and the venue are the headline; there is no reason to attend that is specific to this edition. It attracts people who want free pizza and teaches regulars that the program is interchangeable month to month.
**Strong:**
> **Zero-downtime Postgres major upgrades** - Ana Rossi (platform engineer, Acme) on how they moved 4 TB across three major versions with no maintenance window: the replication setup, the two rollbacks that happened, and what they would do differently.
>
> Tuesday 12 May, 19:00-21:00. Acme, 12 rue de la Paix (Part-Dieu). Doors and food from 18:30, talk at 19:00, networking after.
> Plus two 5-minute lightning slots - one still open, reply if you want it.
> Free, RSVP required (the room seats 40 and we run a waitlist).
The talk is the headline, the takeaway is concrete, the logistics are complete, and the open lightning slot recruits next month's speaker inside this month's announcement.
## What not to promote
- **The venue as the draw.** It matters for logistics, not for attendance.
- **The sponsor.** Thank them from the stage and on the listing; leading with them reads as an ad and depresses turnout.
- **"Networking"** as the only content. It attracts recruiters and repels the engineers they came for.
- **A speaker who is not confirmed.** A retracted headline costs more trust than a late announcement.
references/speaker-pipeline.md›
# Speaker pipeline
Contents: sourcing channels · pipeline board · invitation examples · first-time speaker support · the pitch filter · speaker care.
## Sourcing channels, ranked by yield
1. **The room itself.** Regulars who built something. Ask directly and name the slot length - an open call reaches only people who already identify as speakers.
2. **Standing call for proposals.** A permanent form linked from every announcement and every event page. Fields: name, title, one-paragraph summary, format, takeaway, months available. Keep it under two minutes to fill.
3. **Regional conference speakers.** A talk given at a conference can be repeated locally with no new preparation. Ask during or right after the conference.
4. **Neighboring groups.** Trade speakers with the group one city or one technology over; cross-promote both audiences.
5. **Open-source maintainers of tools the room uses.** Remote slot if travel is impossible - a 20-minute video talk with live Q&A beats a cancelled edition.
6. **Local companies solving the group's problem.** The engineer who ran the migration, not the person who owns the product.
7. **Sponsors** - only through the same filter as anyone else, and never as a condition of sponsorship.
## Pipeline board
Keep one visible table.
- Two confirmed editions ahead is the health line.
- One confirmed edition ahead is a warning.
- Zero confirmed editions ahead is a fire.
| Date | Format | Speaker 1 | Speaker 2 | Status | Slides received |
| ------ | ------------------ | ---------------------------------------------------------- | ----------------------------- | --------------------------- | --------------- |
| 12 May | Anchor + lightning | Confirmed - A. Rossi, "Postgres upgrades without downtime" | 2 lightning slots open | Venue confirmed | Yes |
| 9 Jun | Two-talk | Provisional - M. Chen | Prospect - maintainer, remote | Venue confirmed | No |
| 14 Jul | Study group | n/a | n/a | Fallback, no speaker needed | n/a |
Keeping one no-speaker-needed format in the plan (study group, demo night, open space) means a cancellation costs a format change, not an edition.
## Invitation examples
**Weak:**
> Hi! We run a monthly meetup and we'd love to have you speak sometime. Let me know if you're interested!
No date, no slot length, no audience, no reason it is this person. It asks the recipient to design the offer.
**Strong:**
> Hi Ana - I organize the Lyon Postgres meetup, around 40 backend engineers, mostly working on production databases. I saw your PGConf talk on zero-downtime major upgrades. Would you give a shortened version, 25 minutes plus questions, on Tuesday 12 May at 19:00? Venue is Acme's office near Part-Dieu, we cover dinner, and we record if you're comfortable with it. If 12 May doesn't work, 9 June is open.
Specific date, slot, audience, effort ("shortened version" - no new preparation), what is offered, one alternative date.
## First-time speaker support
Most of a healthy group's future speakers are sitting in the room, convinced they have nothing to say. Lower the barrier deliberately:
- Offer a 5-minute lightning slot rather than a full talk.
- Say explicitly that slides are optional and a terminal is fine.
- Offer a rehearsal with an organizer a week before, and offer to co-present the first time.
- Let them opt out of recording without explaining why.
- Tell them what the audience already knows, so they neither over-explain nor lose the room.
- Send a short written thank-you and the recording link afterwards - it is their portfolio piece, and it is what makes them say yes again.
## The pitch filter
Ask every speaker for the title, the one-line takeaway and the slides in advance. Review the slides against one test: **could this talk be given by someone who does not sell this product?** If not, it is a pitch.
Repairs, in order of preference:
1. Reframe around the problem and keep the product as the setting.
2. Move the product part into a 5-minute sponsor slot.
3. Decline.
Declining is cheaper than losing the regulars, who will not tell you why they stopped coming.
## Speaker care
- Confirm logistics in writing a week before: address, door code, arrival time, adapter, projector resolution, who meets them.
- Feed them.
- Introduce them to two people before the talk so they are not the stranger in the room.
- Send the recording and photos afterwards, and ask them who else should speak. The best sourcing channel is the speaker who just enjoyed the evening.
references/sponsor-and-venue-playbook.md›
# Sponsor and venue playbook
Contents: venue requirements · cost lines · what to ask a sponsor for · what a sponsor gets · conduct rules · the ask, weak and strong · rotation and renewal.
## Venue requirements checklist
- Capacity for the **expected door count**, not the RSVP count, with room to stand at the back.
- Public-transit access and a central location; a suburban campus halves attendance regardless of how good the room is.
- Building access that does not require registering every attendee individually with security, or a plan for it if it does.
- WiFi that survives a full room, and a projector or screen with a known connector - plus an adapter kit the group owns.
- A microphone if the room seats more than about forty.
- Step-free access, an accessible toilet, and a clear statement of both on the event page.
- Space to stand and talk that is not the talk room - networking dies when the only option is rows of chairs.
- A stated closing time, and permission for food and drink.
- A named contact who will actually be in the building that evening.
## Cost lines for one edition
- Food and drinks: the largest line, scale on expected attendance, not RSVPs.
- Name tags and printing.
- An adapter and clicker kit, bought once.
- Optional recording.
- Occasional speaker travel.
- Platform or listing fees.
Everything else at meetup scale should be borrowed or free. Keep the base low enough that losing a sponsor costs one edition's food, not the group.
## What to ask a sponsor for
At this scale the ask is in kind:
| Ask | Typical giver | Notes |
| --------------------- | ----------------------------------------------- | -------------------------------------------------------- |
| Room after work hours | Local tech company, coworking space, university | The highest-value sponsorship; rotate hosts |
| Food and drinks | Any company with a marketing budget | Include vegan and vegetarian options and label allergens |
| Recording or A/V help | Company with an in-house studio | Optional, high leverage for reach |
| Prizes or swag | Vendor with a community program | Small and occasional; not a substitute for content |
| Cash | Only for step-up half-day editions | Needs an invoice path and someone accountable for it |
## What a sponsor gets
- Logo on the event listing and a thank-you from the stage.
- A small table, if they want one.
- An introduction to the organizers.
- At most 15 minutes of stage time - CNCF's published ceiling.
- DevOpsDays holds its own sponsors to a shorter bar: "a short elevator pitch … generally in the order of a minute or two".
Beyond that the evening becomes a vendor session, and the regulars are the first to leave.
## Conduct rules to state up front
State these in writing before accepting anything. Sponsors who find them acceptable renew; those who do not were going to cost the group its room anyway.
- **No bought speaking slots, ever.** The community-event norm is absolute. Sponsors go through the same content filter as any other speaker.
- **No attendee list.** The group does not hand over or sell attendee contact data. If the sponsor wants leads, they earn them at their table with an opt-in.
- **No badge scanning by default**, and no photographs of attendees who declined.
- **The code of conduct applies to sponsor staff**, including recruiters.
- The group can decline a sponsor whose presence conflicts with the room's trust, and says so early rather than after the money moves.
## The ask, weak and strong
**Weak:**
> Hi, we're looking for sponsors for our meetup. Would your company be interested in supporting us? We have various packages available.
Nothing concrete, an unnamed benefit, and "packages" implies a price list the group does not have.
**Strong:**
> Hi Julien - I organize the Nantes Go meetup: monthly, around 35 backend engineers through the door, mostly senior, from about twenty local companies. We're looking for a venue host for the autumn editions: a room for 40 from 18:30 to 21:00 on the second Tuesday, and pizza for the room (about €250 an edition). In exchange: your logo on the event page, a thank-you from the stage, and up to 15 minutes if one of your engineers wants to present something technical - through the same review as any other talk, so no product pitch. We don't share the attendee list with anyone. Interested in September and October to start?
Real audience data, a bounded ask with a real number, a bounded return, and the conduct rules stated before they become an argument.
## Rotation and renewal
Book venue hosts a season at a time - three editions, not twelve - so the group is never one relationship away from homeless, and so no single company's logo defines it. Send each host a short after-report: attendance, talks given, photos, and thanks by name to the person who stayed late to lock up. That person is the reason the next season gets a yes.
SKILL.md›
---
name: developer-meetup-program
description: Designs and runs a recurring developer meetup or user group - purpose and host model, format menu, cadence, a standing speaker pipeline, in-kind venue and food sponsors with their conduct limits, no-show planning, the attendee-to-co-organizer ladder, and a health scorecard. Use whenever someone mentions starting a developer meetup or user group, dying meetup attendance, finding meetup speakers, getting a venue or pizza sponsor, how often to meet, RSVPs who never show, or handing the meetup over - even if they only say "we want to do local events". Covers independent, vendor-backed and company-staffed groups. Not for speaking at a conference - use samber/developer-relations-skills@conference-cfp-submission.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Developer Meetup Program
You are an experienced user-group organizer. The user wants a developer meetup that still happens in eighteen months, with a room that keeps coming back - not a single great evening.
A meetup is a subscription, not an event. Optimize everything for the twentieth edition, not the first: a cadence the team can hold when tired, a speaker pipeline that fills itself, a cost base that survives a lost sponsor, and enough shared ownership that the founder can miss a month.
Scope is the recurring program. These sibling skills cover adjacent tasks:
- Submitting a talk to someone else's event: samber/developer-relations-skills@conference-cfp-submission
- Structuring a talk: samber/developer-relations-skills@tech-talk-outline
- De-risking a demo: samber/developer-relations-skills@developer-live-demo-design
- Buying a sponsor slot at another organizer's event: samber/developer-relations-skills@developer-event-sponsorship
- An online community space: samber/developer-relations-skills@developer-community-launch
- Recurring online Q&A sessions with the team: samber/developer-relations-skills@developer-office-hours-program
- Full-scale conference production, once the program outgrows an evening: samber/dev-event-organizer-skills
Typical invocations:
- "we want to start a Rust meetup in Lyon"
- "attendance dropped from 40 to 12, what do we do"
- "I need a format that doesn't need two speakers every month"
- "write the sponsor ask for a venue"
- "I'm burning out, how do I bring in co-organizers"
## How to read the numbers
Every figure in this skill is one of two kinds:
- **Sourced** - published by a named organizer program, marked inline with its source (CNCF Community Groups, DevOpsDays, the Orbit Model, Nielsen).
- **Baseline** - set by this skill, marked "baseline".
Say which kind a number is whenever you quote one: a baseline presented as an industry standard costs the user's trust in the whole plan. Replace each baseline with the group's own trailing median after three editions. Where every figure comes from: [./references/evidence-and-benchmarks.md](./references/evidence-and-benchmarks.md).
## Interview
Ask one question at a time, multiple-choice where possible, and skip whatever the user has already answered. Questions 1-7 gate the design: do not propose a format before they are answered.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. Is this a new group or an existing one? If existing: how many editions so far, and what is the attendance trend?
2. Who is the room - technology, seniority, and whether they attend on work time or their own time?
3. Who hosts: an independent community group, a vendor-backed chapter, or a company running the series itself?
4. What does success look like in a year - a live local ecosystem, hiring, product feedback, adoption, your own reputation? Name the first one.
5. By what date must the next edition happen - a fixed date you are already committed to, or an open horizon?
6. Do you want one good evening, or a program still running in two years?
7. How many organizers are there today, and what is the standing effort ceiling - hours a month each can hold on a tired month, not in the launch burst?
8. City, expected headcount for edition one, and do you already have access to a room?
9. What budget exists, if any, and who signs for it?
10. Which channels already reach these developers - an existing Slack/Discord, a company list, a neighboring meetup, a university?
11. Do you have two speakers you could ask today? Names, not categories.
12. Anything fixed you must design around - a language, a sponsor commitment, a venue's closing time, a company mandate?
If the answer to 7 is "just me", say so plainly: a solo group is one job change from dead.
- CNCF Community Groups: minimum two organizers, divided responsibilities.
- DevOpsDays: at least three organizers, from different organizations.
Recruit the second organizer within the first three editions, not "later".
Carry questions 5, 6 and 7 into the Step 3 ranking, and say which answer moved which format:
- A fixed near date (Q5) promotes the formats needing no confirmed speaker - study group, open space - because sourcing is the one lead time you cannot compress.
- A two-year mandate (Q6) promotes anchor + lightning, the only format that manufactures the speakers later editions run on.
- A low standing ceiling (Q7) deletes the hands-on workshop outright, and rules out the two-talk classic until the pipeline board holds two editions ahead, whichever the room would prefer.
## Step 1 - Write the charter before booking anything
Write a one-page charter. It settles the arguments that otherwise resurface every edition:
- Who the room is for.
- What happens in a typical evening.
- How often it happens.
- Who decides the program.
- What the group refuses to do.
Name exactly one primary outcome, not a list. For a company-hosted program, use CMX's SPACES model as the vocabulary: support, product feedback, acquisition and advocacy, content and contribution, engagement, or customer success, following its own instruction to "just focus on one objective" when starting out.
That single named outcome is also what gets the program funded internally. For an independent group, apply the same discipline without the business framing: one reason the evening exists, agreed by the organizers.
Present the charter in sections and get each validated before moving on. See [./references/program-charter-template.md](./references/program-charter-template.md) for the exact shape and a filled example.
If your environment has persistent memory, store the charter, the venue and sponsor contacts, and the running edition log. Start the next edition from that file, not from the organizer's memory of what worked.
## Step 2 - Host model and audience
Two axes change almost every downstream decision. Name both out loud rather than leaving them implicit.
**Name who runs the room.** Three models exist, and they are traditions rather than rungs of a ladder: vendor-affiliated user groups (SHARE, 1955) predate the independent volunteer model by two decades.
No efficiency ranking applies across the three. The model is settled by who is asking, at interview question 3, before any effort or value gets weighed: an independent group cannot decide to be vendor-backed, and a vendor cannot decide to be neutral, so ranking a choice nobody makes would be false precision.
Pick the one that already describes you; each is a different contract with the room:
- _Independent, vendor-neutral group_ - sponsors buy logistics, never airtime; competitors are welcome on stage. CNCF caps organizer teams at 50% from any one company to protect exactly this.
- _Vendor-backed volunteer chapter_ - local volunteers run the room; the vendor supplies branding, platform and speaker access but does not staff it (HashiCorp User Groups: 50,000 members across 184 groups - HashiCorp's own figures).
- _Company-staffed series_ - company staff run every stop, no local volunteer organizer (CMX's Circuit Tour). This buys consistency and loses the local ownership that makes volunteers stay.
One real choice sits inside this, and only for a company that has already decided to fund a series: back local volunteers, or staff every stop itself. Effort here is the standing hours company staff must hold for every edition in every city, and how reversible the model is once the room depends on it.
- efficiency: `vendor-backed volunteer chapter > company-staffed series`
- effort: `company-staffed series > vendor-backed volunteer chapter`
- compliance cost: `company-staffed series > vendor-backed volunteer chapter`
- The chapter costs a quarter of recruiting local organizers, then near-zero standing hours; the series is a standing job for staff at every stop, forever, and it stops the month the budget does. Local ownership is also the thing that makes volunteers stay, and a staffed series buys that out without getting it back.
- What this order starves: the company-staffed series - the only model that delivers a consistent evening in a city with no volunteers to recruit. Promote it when the date is fixed and no local organizer exists yet, then convert to a chapter later; a staffed series can hand over to volunteers, but a chapter cannot be un-handed.
- Read the compliance line as the review each triggers: a staffed series runs on company systems, so attendee data, the code of conduct and anything said from the stage carry company legal and brand sign-off; a chapter inherits the vendor's neutrality rules - CNCF's 50%-per-company organizer cap and its escalation path - and the organizers apply them themselves.
Whichever model applies, keep at least one slot per edition for a speaker with no stake in the host's product, or accept that attendance decays to customers only. The full comparison table, per-model risks, and CNCF's escalation path for neutrality violations: [./references/host-model-variants.md](./references/host-model-variants.md).
**Name the audience.**
- B2B/enterprise room: attendance is a work decision. Schedule inside or adjacent to work hours, expect employer-provided venues, and make the topic defensible on a timesheet.
- Individual-adoption audience (hobbyists, students, indie developers): evenings and weekends work, travel budget is zero, food matters more, and the hook is the technology itself.
Format mechanics, speaker sourcing, no-show handling and the participation ladder work identically for both.
A sharper cut applies when a company hosts:
- Developer-first (B2D) business: the attendee is frequently the buyer, so product-adjacent topics carry no tension.
- Developer-plus business: the attendee is one segment of a much larger buying org, so justify the program as brand and ecosystem investment, not pipeline.
The operational mechanics per side are not documented in any source found for this skill - derive them with the user rather than asserting a standard.
## Step 3 - Format and rhythm
Offer the top two or three of the ranking below with their trade-offs and a recommendation, then let the user choose. The right pick is the one the team can repeat when tired, not the most ambitious one. The ordering is this skill's judgement, not a sourced finding.
- **Effort** - what recurs every edition: speakers to source and confirm, and organizer preparation hours. Never the cash cost, which is pizza in every format.
- **Value** - a room that comes back, plus the speakers a format creates for later editions.
- efficiency: `anchor + lightning > study group > two-talk classic > open space > hands-on workshop`
- value: `anchor + lightning > two-talk classic > hands-on workshop > study group > open space`
- effort: `two-talk classic > hands-on workshop > anchor + lightning > study group == open space`
- **Anchor + lightning** - one 25-minute speaker plus 5-minute slots. Leads both lines: one confirmed speaker per edition instead of two, and every lightning slot is a candidate anchor speaker for a later edition, so the format pays back into Step 4's pipeline. Effort: one confirmed speaker, plus an hour recruiting and reassuring first-timers.
- **Study group** - the group works through a book, course or spec together (CNCF lists study groups as a valid meetup style). Ranks second on efficiency purely on its denominator: near-zero recurring effort, and it holds a small room together while the group grows. Caps out - it will not grow a room past the people already committed.
- **Two-talk classic** - 20-30 minutes each. Highest-drawing format for a general audience, and the only one that puts two speakers' networks behind one announcement. Effort: two confirmed speakers every edition, forever - a standing sourcing job, and the single most common way a cadence collapses.
- **Open space / unconference** - attendees propose the agenda on the night. Near-zero preparation, but it needs a room already used to each other, so its value is close to zero until then.
- **Hands-on workshop** - 60-90 minutes, laptops required. Deepest engagement of the five and the best format for tool adoption, but it costs a week of preparation and a facilitator per edition, which is why the ratio puts it last.
- Justify the effort tie: a study group and an open space both need no speaker confirmed in advance and no material the organizers prepare - each costs the room booking and the announcement, nothing more. They differ sharply on value, not on effort.
- Default to anchor + lightning for a new or rebuilding group.
- What this order starves: the two-talk classic, the strongest draw of the five, which the ratio never picks because its sourcing load recurs every edition. Promote it once the pipeline board holds two editions ahead (Step 4) - that is the moment its worst axis collapses, not a matter of taste.
- Delete rather than demote, and say which you deleted: the open space for edition one and for any group whose room has not met before, and the hands-on workshop wherever the answer to interview question 7 was under a day a month per organizer.
- No compliance-cost line: none of the five changes what the group owes anyone. Code of conduct, sponsor stage-time caps and the attendee-list rule apply identically to every format and are handled in Step 5.
- Treat this ordering as a default, not a law: it shifts with the room and with who runs it. Re-rank against what you already know - a room that already knows each other promotes the open space to first, a group with a standing internal speaker bench cancels the two-talk classic's only weakness, and a facilitator who teaches for a living makes the workshop cheap.
Then fix the rhythm. A recurring, predictable slot ("second Tuesday, 19:00") beats date-shopping each month: it becomes a habit and removes one decision per edition. Tuesday-to-Thursday evenings after work is CNCF's stated default for working developers, adjusted to local culture.
Set cadence on CNCF's published thresholds:
- Ideal cadence: monthly.
- Inactivity: **more than 90 days between events marks a chapter inactive**.
- Minimum meetings: technical groups must meet **at least six times a calendar year**.
- Active status: a quarterly event with **more than 10 attendees - attendees, not registrations**.
Below quarterly, a group has occasional events rather than a program. Do not commit to monthly with two organizers and no speaker pipeline - a missed edition costs more trust than a slower cadence.
See [./references/format-catalog.md](./references/format-catalog.md) for the full format menu, per-format time budgets, and a minute-by-minute run of the evening.
## Step 4 - Build a speaker pipeline, not a monthly panic
The recurring failure of meetups is sourcing a speaker three weeks out, every month, forever. Build a pipeline that runs two editions ahead (baseline).
1. Open a **standing call for proposals** - a permanent form linked from every event page and announcement, not a monthly plea (CNCF best practice).
2. **Harvest conferences**: someone who gave a talk at a regional conference can repeat it locally with zero new preparation. Ask them the week of the conference, while it is fresh.
3. **Manufacture speakers from the room**: lightning slots, then a full talk.
4. **Trade with neighboring groups**: their speakers, your speakers, cross-promoted audiences.
5. **Vet the content, not the person.** Ask for the title, the takeaway and the slides in advance - CNCF names slide pre-review as the defense against a talk that turns out to be a pitch. A deck arriving the night of the event is how a group discovers on stage that the talk was a product demo.
Keep a visible pipeline board with confirmed, provisional and prospect speakers per date.
See [./references/speaker-pipeline.md](./references/speaker-pipeline.md) for sourcing channels, an invitation message with a weak and a strong version, first-time-speaker support, and the pitch filter.
## Step 5 - Venue, food and sponsors
At meetup scale sponsorship is usually in kind, not cash: a company lends a room after work and pays for food. Keep the cost base low enough that losing a sponsor costs an edition's pizza, not the group.
Offer the sponsor:
- Recognition on the listing.
- A thank-you from the stage.
- A small table, if they want to talk to people who approach them.
- **At most 15 minutes of stage time** (CNCF best practice).
DevOpsDays is stricter at its own scale: "a short elevator pitch … generally in the order of a minute or two". Pick a cap, publish it, and hold it.
Two limits are absolute, whatever the model:
- **Never a speaking slot in exchange for money.** DevOpsDays states it flatly: "no speaker spots can be bought by sponsors: not ever - period."
- **Never the attendee list.** DevOpsDays: "devopsdays does not ever distribute attendee contact information." People opt in to a badge scan if the sponsor offers something, and not by default.
On food: provide vegan and vegetarian options and label allergens (CNCF).
Rotate venue hosts where possible. A single host that also employs half the organizers turns the group into that company's user group whether or not anyone intended it.
See [./references/sponsor-and-venue-playbook.md](./references/sponsor-and-venue-playbook.md) for the venue requirements checklist, the in-kind ask template, cost lines, and the conduct rules to state up front.
## Step 6 - Promotion and the no-show plan
Free RSVPs are cheap, so a share of them will not turn up. Plan on roughly **30% no-shows** - CNCF's published planning figure, and the only no-show number with a named organization behind it; the 40-50% often repeated for free evening events is folklore. Calibrate on your own door count after three editions rather than trusting any benchmark, including CNCF's.
- **Overbook** to the no-show ratio and run a waitlist that auto-promotes.
- **Remind** two days and two hours before, and explicitly ask people who cannot make it to release their spot. Frame it as freeing a seat for someone else, not as guilt.
- **Count heads at the door.** Attendance, not registrations, goes in the log - every threshold and trend in this skill depends on the real number, and CNCF's own activity bar is written in attendees for the same reason.
- **Promote the speaker and the topic**, not the venue or the food (CNCF marketing guidance). The talk is the reason people come; the pizza is the reason they stay.
- **Announce early**, across the group listing, adjacent meetups, community channels, local newsletters, and the speaker's own network - a speaker who shares their slot brings their audience.
See [./references/promotion-and-no-show-plan.md](./references/promotion-and-no-show-plan.md) for the reminder schedule, the overbooking arithmetic worked through, and a weak-versus-strong announcement pair.
## Step 7 - Retention, the ladder, and succession
Attendance retention is not a marketing problem. People come back to a room where they know someone and where there is a path upward.
Move people up this ladder: **attendee → regular → lightning speaker → volunteer → co-organizer**, each rung recruited from the one below. The ladder is this skill's mapping of the Orbit Model's four community levels - Explorers → Participants → Contributors → Advocates, with gravity defined as love × reach. Orbit was published in 2019 and is no longer actively developed; cite it as a stable framework, not a live product.
- Make first-timers visible and welcomed - a raised hand at the start, an organizer who introduces them to one person, name tags.
- Ask regulars directly. "Would you do five minutes on what you built?" converts far better than an open call, which only reaches people who already consider themselves speakers.
- Give volunteers real ownership (food, A/V, emcee, socials), one or two areas each.
- Recruit co-organizers publicly and on a low bar. CNCF does this through a public issue - nomination or self-nomination, approved when at least 50% of current organizers comment in favor - and handles departures the same way, which is what stops silent exits leaving ghost owners on accounts.
Calibrate expectations with Nielsen's participation inequality (90-9-1, published 2006): about 90% of any community lurks, 9% contribute occasionally, 1% produce most of the activity. A room where only a handful of people ever step up is normal, not a failure of your program; the lever is lowering the barrier to the next rung, not "converting the lurkers".
Design succession from day one, not as an emergency response:
- Shared ownership of the listing, mailing list, socials and any payment account.
- A written run-of-show anyone can follow.
- A public, unembarrassing exit path so a departing organizer says so instead of quietly going silent.
Between editions, keep one channel alive and run a 15-minute co-organizer debrief after every event, feeding the next edition's plan.
## Deliverable
Produce, in this order:
1. **Program charter** - one page, the template in [./references/program-charter-template.md](./references/program-charter-template.md).
2. **Edition plan, three editions deep** - a table with date, format, speaker status, venue, sponsor status, promotion dates.
3. **Speaker pipeline board** - confirmed, provisional and prospect per date; the board shape is in [./references/speaker-pipeline.md](./references/speaker-pipeline.md).
4. **Edition log skeleton** - the empty table the organizer fills the night of each event; columns and filled rows in [./references/program-charter-template.md](./references/program-charter-template.md).
5. **Scorecard baseline** - the Measurement table below with the group's current values or "not measured yet"; a healthy and a failing example, read line by line, are in [./references/program-charter-template.md](./references/program-charter-template.md).
Mark anything beyond edition three as provisional - say so rather than inventing a year of programming nobody has committed to.
## Measurement
Track these per edition in one running log. The trend across editions is the signal; a single edition tells you about the weather.
| Signal | Target | Basis |
| ----------------------------------- | ----------------------------------- | -------------------------------------------------------------------- |
| Attendance at the door | Stable or rising over 3 editions | Baseline (this skill); CNCF counts attendees, not registrations |
| Show-up rate (attended ÷ RSVP) | ≈ 70% | Arithmetic on CNCF's ~30% no-show figure, not an independent finding |
| Repeat attendance | ≥ 40% of attendees have been before | Baseline (this skill) |
| New faces per edition | > 0, every edition | Baseline (this skill) |
| Speakers sourced from the room | ≥ 1 in 3 | Baseline (this skill) - ambitious against Nielsen's 90-9-1 |
| Editions confirmed ahead | ≥ 2 | Baseline (this skill) |
| Organizer count and employer spread | ≥ 2 people, ≥ 2 employers | CNCF (min 2, ≤50% one company); DevOpsDays (≥3, different orgs) |
| Gap since last edition | ≤ 90 days | CNCF inactivity threshold |
| Attendees per edition | > 10 | CNCF active-chapter bar |
## Pass threshold
A program is healthy when all six hold. Fix the failing line before adding scale, a bigger venue, or a second format.
1. No gap longer than 90 days, and at least six editions planned or held per year (both CNCF).
2. At least two editions have confirmed speakers (baseline).
3. Door attendance is stable or rising across the last three editions, and above 10 per edition (CNCF bar).
4. Repeat attendance is at least 40%, with new faces every edition (baseline).
5. At least two organizers, from at least two different employers, with shared account access (CNCF).
6. No edition where a sponsor exceeded the published stage-time cap or the room got a pitch it did not sign up for (CNCF/DevOpsDays).
See [./references/program-charter-template.md](./references/program-charter-template.md) for a filled scorecard, including a failing one read line by line.
## Failure modes
| Failure | What it looks like | Fix |
| ---------------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Founder-shaped group | One person owns the listing, the room and every decision | Recruit a co-organizer from the regulars in the first three editions |
| Monthly speaker panic | Sourcing starts three weeks out, every time | Standing CFP plus a two-edition pipeline board |
| Vendor capture | Host company fills every slot; competitors stop coming | One non-host speaker per edition, minimum |
| Pizza-first promotion | Announcements lead with food and venue | Lead with speaker and topic; food is a footnote |
| RSVP theater | Planning on registrations, ordering food for 60, feeding 25 | Plan on ~30% no-shows, then use your own measured rate |
| Format overreach | A workshop every month with two organizers | Downgrade to a repeatable format; ambition costs cadence |
| Room full of strangers | High attendance, no repeat, nobody talks | Structured welcome, name tags, deliberate introductions, protected networking time |
| Cadence collapse | "We'll do the next one when we find a speaker" | Fix the slot, book the room, then fill the program |
| Silent decline | Attendance halves and nobody names it | Log the door count every edition and read the trend out loud at the debrief |
| Quiet handover failure | Departing organizer stops answering; accounts locked | Shared ownership from day one, plus a stated exit path |
| Borrowed benchmark | An organizer quotes this skill's 40% repeat-attendance baseline to a sponsor as an industry figure | Quote only sourced numbers externally; call every baseline "our target" |
## References
- See [./references/format-catalog.md](./references/format-catalog.md) for formats, time budgets and the run of the evening.
- See [./references/speaker-pipeline.md](./references/speaker-pipeline.md) for sourcing, invitation examples and the pitch filter.
- See [./references/sponsor-and-venue-playbook.md](./references/sponsor-and-venue-playbook.md) for venue requirements, in-kind asks and sponsor conduct rules.
- See [./references/promotion-and-no-show-plan.md](./references/promotion-and-no-show-plan.md) for reminders, overbooking arithmetic and announcement examples.
- See [./references/host-model-variants.md](./references/host-model-variants.md) for the three host models, the B2D/developer-plus split and listing-platform considerations.
- See [./references/program-charter-template.md](./references/program-charter-template.md) for the charter, the edition log and a worked scorecard.
- See [./references/evidence-and-benchmarks.md](./references/evidence-and-benchmarks.md) for every figure in this skill with its source or its baseline label.