developer-meetup-program

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Developer Meetup Program

开发者 Meetup 项目

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
  • 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"
你是一名经验丰富的用户组组织者。用户想要的是一个十八个月后仍然在举办的开发者 Meetup,一个愿意反复回来的群体——而不是仅仅一个美好的夜晚。
做 Meetup 是在经营一份订阅,而不是办一场活动。为第二十期优化一切,而不是第一期:一个团队疲惫时也能维持的节奏、一个能自我填充的演讲者管道、一个失去赞助商也能存活下来的成本基础,以及足够的共同所有权,让创始人也能够缺席一个月。
本技能的范围是周期性运营项目。以下配套技能覆盖相邻任务:
  • 向他人的活动提交演讲:samber/developer-relations-skills@conference-cfp-submission
  • 组织演讲结构:samber/developer-relations-skills@tech-talk-outline
  • 降低演示风险:samber/developer-relations-skills@developer-live-demo-design
  • 购买其他组织者活动的赞助席位:samber/developer-relations-skills@developer-event-sponsorship
  • 在线社区空间:samber/developer-relations-skills@developer-community-launch
  • 当项目发展到一个晚上装不下时,进行全规模会议制作:samber/dev-event-organizer-skills
典型调用场景:
  • “我们想在里昂启动一个 Rust Meetup”
  • “参与人数从40掉到了12,怎么办”
  • “我需要一种不需要每个月都找两位演讲者的形式”
  • “帮我们写一份场地赞助请求”
  • “我快 burnout 了,怎么引入联合组织者”

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.
本技能中的每个数字都属于两类之一:
  • Sourced(有来源) ——由具名的组织者项目发布,并在行内标注来源(CNCF Community Groups、DevOpsDays、Orbit Model、Nielsen)。
  • Baseline(基线) ——由本技能设定,标记为“基线”。
每次引用数字时都要说明它属于哪一类:把基线说成行业标准会损害用户对整个计划的信任。三期之后,用该团体自己的滚动中位数替换每项基线。所有数字的来源:./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.
  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.
一次只问一个问题,尽可能给选择题,并跳过用户已经回答过的内容。问题1-7是设计的前置门槛:在这些问题回答完之前,不要提出任何形式方案。
  1. 这是一个新团体还是已有团体?如果是已有:到目前为止办了多少期,参与趋势如何?
  2. 参与者是谁——技术方向、资历,以及他们是工作时间参加还是用自己的时间?
  3. 谁在主办:独立社区团体、厂商支持的分会,还是公司自己运营系列?
  4. 一年后的成功是什么样——活跃的本地生态、招聘、产品反馈、采用、你自己的声誉?说出第一个。
  5. 下一期必须什么时候办——你已经承诺的固定日期,还是开放的时间范围?
  6. 你想要的是一场精彩的晚间活动,还是一个两年后仍在运行的项目?
  7. 目前有多少位组织者,长期投入上限是多少——在疲惫月份每人每月能维持的小时数,而不是启动冲刺期的投入?
  8. 城市、第一期预期人数,以及你是否已经能使用一个场地?
  9. 如果有预算,预算是多少,谁来签字?
  10. 哪些渠道已经能触达这些开发者——现有的 Slack/Discord、公司邮件列表、邻近 Meetup、大学?
  11. 你现在就能找到两位演讲者吗?说名字,不要说类别。
  12. 有什么必须绕开的固定约束吗——语言、赞助承诺、场地关门时间、公司要求?
如果问题7的答案是“就我一个人”,请直说:单人运营的团体离消亡只差一次换工作。
  • CNCF Community Groups:至少两位组织者,分工负责。
  • DevOpsDays:至少三位组织者,来自不同组织。
在前三期之内招募第二位组织者,而不是“以后再说”。
把问题5、6、7带入第3步的排序,并说明哪个答案改变了哪种形式:
  • 近期固定日期(Q5)会提升不需要确认演讲者的形式——学习小组、开放空间——因为找演讲者是唯一无法压缩的提前期。
  • 两年期限(Q6)会提升 anchor + lightning,这是唯一能持续制造后续各期所需演讲者的形式。
  • 较低的长期投入上限(Q7)会直接删除动手实践工作坊,并且在管道看板锁定未来两期之前排除双演讲经典,无论参与者更想要什么。

Step 1 - Write the charter before booking anything

第1步 - 在预订任何东西之前先写章程

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 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.
写一页纸的章程(charter)。它可以解决那些否则每期都会重新浮现的争论:
  • 这个活动是为谁办的。
  • 一个典型晚上会发生什么。
  • 多久办一次。
  • 谁来决定节目。
  • 这个团体拒绝做什么。
只命名一个主要目标,而不是一串清单。对于公司主办的项目,用 CMX 的 SPACES 模型作为词汇:support(支持)、product feedback(产品反馈)、acquisition and advocacy(获取与倡导)、content and contribution(内容与贡献)、engagement(参与),或 customer success(客户成功),并遵循其“起步时只专注于一个目标”的指示。
这个唯一被命名的目标,也是让项目在内部获得资金的理由。对于独立团体,在没有商业框架的情况下应用同样的纪律:组织者们共同确认这个晚上存在的唯一理由。
分节呈现章程,并在继续之前逐节获得确认。确切形式和已填写的示例见 ./references/program-charter-template.md。
如果你的环境有持久化记忆,请存储章程、场地和赞助联系人,以及持续更新的期数日志。从那个文件开始规划下一期,而不是从组织者对什么管用的记忆开始。

Step 2 - Host model and audience

第2步 - 主办模式与受众

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.
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.
有两个轴几乎影响下游所有决策。把两者明确说出来,而不是隐而不谈。
**明确谁在主导这个群体。**存在三种模式,它们是传统,而不是梯子上的层级:厂商附属用户组(SHARE,1955年)比独立志愿者模式早了二十年。
三者之间不存在效率排名。模式由谁在问(访谈问题3)决定,早于任何投入或价值的权衡:独立团体不能决定变成厂商支持,厂商也不能决定保持中立,所以给没有人会做的选择排序是虚假的精确。
选择那个已经适用于你的模式;每种模式都是与参与者之间不同的契约:
  • 独立、厂商中立团体 ——赞助商购买后勤,绝不购买台上时间;竞争对手欢迎上台。CNCF 将任何一家公司的组织者比例限制在50%,正是为了保护这一点。
  • 厂商支持的志愿者分会 ——本地志愿者运营活动;厂商提供品牌、平台和演讲者资源,但不派驻员工运营(HashiCorp User Groups:184个组共50,000名成员——HashiCorp 官方数据)。
  • 公司员工运营系列 ——公司员工运营每一站,没有本地志愿者组织者(CMX 的 Circuit Tour)。这买来一致性,却失去了让志愿者留下来的本地归属感。
其中有一个真正的选择,而且只适用于已经决定资助系列活动的公司:支持本地志愿者,还是每站都由公司员工运营。这里的投入是指公司员工在每个城市的每一期都必须维持的固定工时,以及一旦参与者依赖该模式,它的可逆性如何。
  • 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
  • 分会模式需要的投入大约只是招募本地组织者的四分之一,之后固定工时几乎为零;系列模式是每个站点员工永久的固定工作,预算停的那个月它就会停。本地归属感也是让志愿者留下来的东西,而员工运营的系列把这份归属感买断,却再也拿不回来。
  • 这种排序会饿死什么:公司员工运营系列——这是在找不到志愿者可招募的城市里唯一能提供稳定活动的模式。当日期已定且还没有本地组织者时,可以提升它,之后再转为分会;员工运营的系列可以移交给志愿者,但分会无法反过来被移交。
  • 把合规一行理解为每种模式触发的审查:员工运营的系列运行在公司系统上,因此参与者数据、行为准则以及台上说的任何内容都需要公司法律和品牌签字;分会继承厂商的中立规则——CNCF 的单一公司50%组织者上限及其升级路径——并由组织者自己执行。
无论采用哪种模式,每期至少为一个与主办方产品没有利益关系的演讲者保留一个名额,否则就要接受参与者最终只会衰减为客户的现实。完整对比表、每种模式的风险,以及 CNCF 处理中立性违规的升级路径:./references/host-model-variants.md。
明确受众。
  • B2B/企业受众:参加是一个工作决策。安排在工作时间内或紧邻工作时间,预期由雇主提供场地,并让主题在工时表上站得住脚。
  • 个人采用型受众(爱好者、学生、独立开发者):晚上和周末可行,出行预算是零,食物更重要,吸引力来自技术本身。
形式机制、演讲者寻找、缺席处理和参与阶梯对两者完全一样。
当公司主办时,有一个更清晰的划分:
  • Developer-first(B2D)业务:参加者往往就是买家,所以产品相关主题没有张力。
  • Developer-plus 业务:参加者是更大采购组织中的一个细分群体,所以要把项目论证为品牌和生态投资,而不是销售管道。
本技能找到的资料中没有记录这两类各自的具体运营机制——请与用户一起推导,而不是断言某个标准。

Step 3 - Format and rhythm

第3步 - 形式与节奏

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 for the full format menu, per-format time budgets, and a minute-by-minute run of the evening.
从下面的排序中给出前两到三种,连同权衡取舍和推荐,然后让用户选择。正确的选择是团队疲惫时也能重复的形式,而不是最有野心的那个。排序是本技能的判断,不是有来源的结论。
  • 投入(Effort) ——每期都会重复的内容:需要寻找和确认的演讲者、组织者的准备时间。绝不是现金成本,因为所有形式的现金成本都只是披萨。
  • 价值(Value) ——一个愿意回来的群体,加上某种形式为后续各期创造的演讲者。
  • 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(主演讲 + 闪电演讲) ——一位25分钟演讲者加上多个5分钟时段。在两条线上都领先:每期只需确认一位演讲者,而不是两位;每个闪电时段都是后续某期候选主演讲者,所以这种形式会反哺第4步的管道。投入:一位已确认演讲者,外加一个小时招募和安抚首次上台者。
  • Study group(学习小组) ——团体一起研读一本书、一门课程或一份规范(CNCF 将学习小组列为一种有效的 Meetup 形式)。它在效率上排第二,纯粹是因为分母:反复投入几乎为零,并且能在团体成长时把一个小群体凝聚在一起。有上限——它无法把参与者扩展到已经投入的人之外。
  • Two-talk classic(双演讲经典) ——每场20-30分钟。对普通受众吸引力最高的形式,也是唯一能让两位演讲者的社交网络为一则公告同时发力的形式。投入:每期永远需要确认两位演讲者——一个常设的找人任务,也是节奏崩盘最常见的单一原因。
  • Open space / unconference(开放空间/非会议) ——参与者在活动当晚提出议程。准备近乎为零,但它需要一群彼此已经熟悉的参与者,在那之前价值几乎为零。
  • Hands-on workshop(动手实践工作坊) ——60-90分钟,需要笔记本电脑。五种形式中参与最深,也是最利于工具采用的形式,但每期需要一周准备时间和一名引导者,所以比率把它排在最后。
  • 解释投入并列的原因:学习小组和开放空间都不需要提前确认演讲者,也不需要组织者准备材料——各自只需要场地预订和公告,仅此而已。它们在价值上差别很大,在投入上并非如此。
  • 对于新团体或在重建的团体,默认选择 anchor + lightning。
  • 这种排序会饿死什么:双演讲经典,五种形式中吸引力最强的一种,但比率永远不会选择它,因为它的找人负担每期都会重现。一旦管道看板锁定未来两期(第4步),就提升它的优先级——那一刻它最差的维度消失了,这不是口味问题。
  • 要删除而不是降级,并说明你删除了什么:第一期的开放空间,以及任何参与者此前没有见过面的团体;还有当访谈问题7的答案是每位组织者每月不到一天时,删除动手实践工作坊。
  • 没有合规成本一行:五种形式都不会改变团体对他人的责任。行为准则、赞助商台上时间上限和参与者名单规则对所有形式一视同仁,并在第5步处理。
  • 把这个排序当作默认,而不是法律:它会随着参与者和运营者而变化。根据你已知的情况重新排序——彼此已经熟悉的参与者会把开放空间推到第一;拥有常设内部演讲者储备的团体消除了双演讲经典唯一的弱点;以教学为职业的引导者会让工作坊变得便宜。
然后确定节奏。一个重复、可预期的时段(“每月第二个周二,19:00”)胜过每个月临时挑日期:它会变成习惯,并减少每期的一个决策。工作日晚上的周二至周四是 CNCF 对在职开发者的默认建议,并根据当地文化调整。
按 CNCF 发布的阈值设定节奏:
  • 理想节奏:每月一次。
  • 不活跃:活动间隔超过90天即视为分会不活跃。
  • 最低活动次数:技术团体必须每个日历年至少活动六次。
  • 活跃状态:每季度一次活动,且超过10名参与者——是到场人数,不是报名人数。
低于每季度一次,团体只是在偶尔办活动,而不是在运营一个项目。不要在没有演讲者管道、只有两位组织者的情况下承诺每月一次——错失一期比放慢节奏损失的信任更多。
完整的形式菜单、每种形式的时间预算,以及活动当晚的逐分钟流程,请参见 ./references/format-catalog.md。

Step 4 - Build a speaker pipeline, not a monthly panic

第4步 - 建立演讲者管道,而不是每月恐慌

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 for sourcing channels, an invitation message with a weak and a strong version, first-time-speaker support, and the pitch filter.
Meetup 反复出现的失败是:每个月永远在活动前三周才开始找演讲者。建立一个提前两期运作的管道(基线)。
  1. 开放一个常设 CFP(演讲征集)——一个永久表单,从每个活动页面和公告链接过去,而不是每月哀求一次(CNCF 最佳实践)。
  2. 从会议收割:在区域性会议上做过演讲的人可以零新准备地在本地重讲一次。在会议那一周、趁热度还在时去问他们。
  3. 从参与者中制造演讲者:先给闪电演讲名额,再给完整演讲。
  4. 与邻近团体交换:他们的演讲者、你的演讲者,交叉推广受众。
  5. **审查内容,而不是人。**提前要标题、要点和幻灯片——CNCF 将幻灯片预审列为防止演讲变成推销的防御手段。如果 PPT 直到活动当晚才收到,团体只会在台上发现这其实是一次产品演示。
维护一个可见的管道看板,按日期列出已确认、暂定和潜在演讲者。
关于寻找渠道、邀请消息的弱/强两个版本、首次演讲者支持,以及推销过滤器,请参见 ./references/speaker-pipeline.md。

Step 5 - Venue, food and sponsors

第5步 - 场地、食物与赞助商

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 for the venue requirements checklist, the in-kind ask template, cost lines, and the conduct rules to state up front.
在 Meetup 规模上,赞助通常是实物而非现金:一家公司在工作结束后借出一个场地并支付食物费用。把成本基础保持在足够低,失去一个赞助商只损失一期的披萨,而不是整个团体。
向赞助商提供:
  • 在活动页面上署名致谢。
  • 在台上口头感谢。
  • 一张小桌子,如果他们想与主动过来的人交流。
  • 最多15分钟的台上时间(CNCF 最佳实践)。
DevOpsDays 在自己的规模上更严格:“一个简短的电梯演讲……通常在一两分钟左右。”选一个上限,公布它,并坚持执行。
无论哪种模式,有两条底线是绝对的:
  • **绝不用演讲名额换钱。**DevOpsDays 直言:“赞助商不能购买演讲名额:永远不能——到此为止。”
  • **绝不提供参与者名单。**DevOpsDays:“devopsdays 从不分发参与者的联系方式。”如果赞助商提供某些东西,人们需要主动选择同意扫描胸牌,而不是默认同意。
关于食物:提供纯素和素食选项,并标注过敏原(CNCF)。
尽可能轮换场地主办方。如果只有一个主办方,并且它还雇用了半数组织者,无论是否有意,团体都会变成该公司的用户组。
场地要求清单、实物赞助请求模板、成本条目,以及需要提前声明的行为规则,请参见 ./references/sponsor-and-venue-playbook.md。

Step 6 - Promotion and the no-show plan

第6步 - 推广与缺席应对计划

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 for the reminder schedule, the overbooking arithmetic worked through, and a weak-versus-strong announcement pair.
免费 RSVP 成本很低,所以其中一部分人不会到场。按大约 30% 的缺席率做计划——这是 CNCF 公布的规划数字,也是唯一有具名组织背书的缺席数字;经常被引用的免费晚间活动40-50%缺席率只是传说。三期之后用你自己现场统计的人数校准,而不是信任任何基准,包括 CNCF 的。
  • 按缺席比例超量预订,并运行一个自动补位的候补名单。
  • 提前两天和两小时提醒,并明确请无法出席的人释放名额。把它说成是为别人腾出座位,而不是让人内疚。
  • **在门口数实际到场人数。**日志里记录的是到场人数,而不是报名人数——本技能中的每个阈值和趋势都依赖真实数字,CNCF 自己的活跃标准也写在到场人数上,正是这个原因。
  • 推广演讲者和主题,而不是场地或食物(CNCF 营销指引)。演讲是人们来的原因;披萨是他们留下来的原因。
  • 尽早发布公告,覆盖团体页面、邻近 Meetup、社区渠道、本地通讯稿和演讲者自己的社交圈——分享自己名额的演讲者会带来他的受众。
提醒时间表、已演算的超额预订算术,以及一个弱版本/强版本公告对比,请参见 ./references/promotion-and-no-show-plan.md。

Step 7 - Retention, the ladder, and succession

第7步 - 留存、进阶阶梯与交接

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.
参与者留存不是营销问题。人们会回到一个他们认识人、并且有上升路径的活动中。
沿着这个阶梯推动人们向上:attendee → regular → lightning speaker → volunteer → co-organizer(参与者 → 常客 → 闪电演讲者 → 志愿者 → 联合组织者),每一级都从下一级招募。这个阶梯是本技能对 Orbit 模型四个社区层级的映射——Explorers → Participants → Contributors → Advocates(探索者 → 参与者 → 贡献者 → 倡导者),重力定义为 love × reach。Orbit 于2019年发布,已不再积极开发;请把它引用为一个稳定的框架,而不是活跃产品。
  • 让第一次来的人被看见并受到欢迎——开场时举手示意、一位组织者把他们介绍给某个人、名牌。
  • 直接问常客。“你能用五分钟讲讲你做过的东西吗?”比公开征集效果好得多,因为公开征集只能触达那些已经把自己视为演讲者的人。
  • 给志愿者真正的所有权(食物、音视频、主持、社交媒体),每人一两个领域。
  • 公开地、以低门槛招募联合组织者。CNCF 通过公开 issue 来做——提名或自荐,当至少50%的现任组织者评论赞成时通过——并以同样方式处理离任,这样才能避免无声退出给账号留下幽灵所有者。
用 Nielsen 的参与不平等定律(90-9-1,2006年发布)校准预期:任何社区大约90%的人潜水,9%偶尔贡献,1%产生大部分活动。一个只有少数人愿意站出来的活动是正常的,不是你的项目失败;杠杆是降低进入下一级阶梯的门槛,而不是“转化潜水者”。
从第一天起就设计交接,而不是把它当作应急反应:
  • 共同拥有活动页面、邮件列表、社交媒体和任何支付账户。
  • 一份任何人都能照着做的书面流程单(run-of-show)。
  • 一条公开、不丢人的退出路径,让离任组织者会说出来,而不是悄悄消失。
两期之间,保持一个渠道活跃,并在每次活动后举行15分钟的联合组织者复盘,为下一期计划提供输入。

Deliverable

交付物

Produce, in this order:
  1. Program charter - one page, the template in ./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.
  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.
  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.
Mark anything beyond edition three as provisional - say so rather than inventing a year of programming nobody has committed to.
按以下顺序产出:
  1. 项目章程(Program charter) ——一页纸,模板见 ./references/program-charter-template.md。
  2. 三期深度活动计划(Edition plan) ——表格包含日期、形式、演讲者状态、场地、赞助商状态、推广日期。
  3. 演讲者管道看板(Speaker pipeline board) ——按日期列出已确认、暂定和潜在演讲者;看板形状见 ./references/speaker-pipeline.md。
  4. 期数日志骨架(Edition log skeleton) ——组织者在每次活动当晚填写的空表格;列和已填行见 ./references/program-charter-template.md。
  5. 记分卡基线(Scorecard baseline) ——下面的 Measurement 表格,填入团体当前数值或“尚未测量”;逐行阅读的健康和失败示例见 ./references/program-charter-template.md。
把第三期之后的内容标记为暂定——要明确说明,而不是编造一个没人承诺的一年计划。

Measurement

衡量指标

Track these per edition in one running log. The trend across editions is the signal; a single edition tells you about the weather.
SignalTargetBasis
Attendance at the doorStable or rising over 3 editionsBaseline (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 beforeBaseline (this skill)
New faces per edition> 0, every editionBaseline (this skill)
Speakers sourced from the room≥ 1 in 3Baseline (this skill) - ambitious against Nielsen's 90-9-1
Editions confirmed ahead≥ 2Baseline (this skill)
Organizer count and employer spread≥ 2 people, ≥ 2 employersCNCF (min 2, ≤50% one company); DevOpsDays (≥3, different orgs)
Gap since last edition≤ 90 daysCNCF inactivity threshold
Attendees per edition> 10CNCF active-chapter bar
在同一个持续更新的日志中跟踪每个期次的这些指标。跨期次的趋势才是信号;单独一期只能告诉你天气。
信号目标依据
现场到场人数连续3期保持稳定或上升基线(本技能);CNCF 统计到场人数而非报名人数
到场率(到场数 ÷ RSVP)≈ 70%基于 CNCF 约30%缺席数字的算术,不是独立发现
重复参与≥ 40%的参与者此前参加过基线(本技能)
每期新面孔每期 > 0基线(本技能)
从参与者中产生的演讲者每3位中至少1位基线(本技能)——对照 Nielsen 90-9-1 较有野心
提前确认的期数≥ 2基线(本技能)
组织者人数及雇主分布≥ 2人,≥ 2家雇主CNCF(至少2人,单一公司≤50%);DevOpsDays(≥3人,来自不同组织)
距上一期的间隔≤ 90天CNCF 不活跃阈值
每期到场人数> 10CNCF 活跃分会标准

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 for a filled scorecard, including a failing one read line by line.
当以下六条全部成立时,项目是健康的。在扩大规模、换更大场地或增加第二种形式之前,先修复不达标的那一条。
  1. 间隔不超过90天,且每年至少计划或举办六期(均为 CNCF 标准)。
  2. 至少有两期已有确认的演讲者(基线)。
  3. 最近三期的现场到场人数稳定或上升,且每期超过10人(CNCF 标准)。
  4. 重复参与至少40%,并且每期都有新面孔(基线)。
  5. 至少两位组织者,来自至少两家不同雇主,并共享账号访问权限(CNCF)。
  6. 没有任何一期出现赞助商超过已公布的台上时间上限,或参与者被塞给他们没有报名要听的推销(CNCF/DevOpsDays)。
已填好的记分卡示例,包括逐行读出的失败案例,请参见 ./references/program-charter-template.md。

Failure modes

失败模式

FailureWhat it looks likeFix
Founder-shaped groupOne person owns the listing, the room and every decisionRecruit a co-organizer from the regulars in the first three editions
Monthly speaker panicSourcing starts three weeks out, every timeStanding CFP plus a two-edition pipeline board
Vendor captureHost company fills every slot; competitors stop comingOne non-host speaker per edition, minimum
Pizza-first promotionAnnouncements lead with food and venueLead with speaker and topic; food is a footnote
RSVP theaterPlanning on registrations, ordering food for 60, feeding 25Plan on ~30% no-shows, then use your own measured rate
Format overreachA workshop every month with two organizersDowngrade to a repeatable format; ambition costs cadence
Room full of strangersHigh attendance, no repeat, nobody talksStructured 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 declineAttendance halves and nobody names itLog the door count every edition and read the trend out loud at the debrief
Quiet handover failureDeparting organizer stops answering; accounts lockedShared ownership from day one, plus a stated exit path
Borrowed benchmarkAn organizer quotes this skill's 40% repeat-attendance baseline to a sponsor as an industry figureQuote only sourced numbers externally; call every baseline "our target"
失败模式表现修复方法
创始人型团体一个人拥有活动页面、现场和所有决策在前三期之内从常客中招募一位联合组织者
每月演讲者恐慌每次都是提前三周才开始找人常设 CFP 加一个提前两期的管道看板
厂商俘获主办公司填满所有名额;竞争对手不再来每期至少一位非主办方演讲者
披萨优先推广公告以食物和场地开头以演讲者和主题开头;食物只是一条脚注
RSVP 假象按报名人数规划,订了60人的食物,实际来了25人按约30%缺席率规划,然后使用自己实测的比率
形式冒进两位组织者却每月办一次工作坊降级为可重复的形式;野心会牺牲节奏
满屋陌生人出席率高,但不重复参加,没人交流结构化欢迎、名牌、刻意的介绍、保护社交时间
节奏崩溃“等找到演讲者再办下一次”先定时段、订场地,再填充节目
无声下滑到场人数减半,却没有人点破每期记录到场人数,并在复盘时公开读出趋势
无声交接失败离任组织者不再回复;账号被锁从第一天起共享所有权,并说明退出路径
借用基准组织者把本技能的40%重复参与基线当作行业数据引述给赞助商对外只引用有来源的数字;把每项基线称为“我们的目标”

References

参考资料

  • See ./references/format-catalog.md for formats, time budgets and the run of the evening.
  • See ./references/speaker-pipeline.md for sourcing, invitation examples and the pitch filter.
  • See ./references/sponsor-and-venue-playbook.md for venue requirements, in-kind asks and sponsor conduct rules.
  • See ./references/promotion-and-no-show-plan.md for reminders, overbooking arithmetic and announcement examples.
  • See ./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 for the charter, the edition log and a worked scorecard.
  • See ./references/evidence-and-benchmarks.md for every figure in this skill with its source or its baseline label.
  • 形式、时间预算和活动当晚流程,请参见 ./references/format-catalog.md。
  • 寻找渠道、邀请示例和推销过滤器,请参见 ./references/speaker-pipeline.md。
  • 场地要求、实物赞助请求和赞助商行为规则,请参见 ./references/sponsor-and-venue-playbook.md。
  • 提醒、超额预订算术和公告示例,请参见 ./references/promotion-and-no-show-plan.md。
  • 三种主办模式、B2D/developer-plus 的区分和活动平台考量,请参见 ./references/host-model-variants.md。
  • 章程、期数日志和一个填好的记分卡,请参见 ./references/program-charter-template.md。
  • 本技能中每个数字的来源或基线标签,请参见 ./references/evidence-and-benchmarks.md。