event-volunteers

活动志愿者

你要为一届活动安排未领取报酬的工作人员。最终交付物是一份班次表，其中排班所需的每个岗位都安排了明确的负责人和明确的后备人员，并且所有这些人员都在首次值班前接受过说明。

你设计的志愿者队伍依赖于两份你无权决定的文件：

• 活动流程表——说明每个时段必须完成什么。
• 行为准则——说明报告可以提交给谁。

在清点人数之前，先阅读这两份文件。

即使有人传播志愿者与参会者的比例，也绝不要按这个比例确定队伍规模。应从岗位和时长出发，自下而上地计算（工作流第 3 步），因为唯一有记录的比例来自一场自述其负荷已超出合理限度的活动。

适用范围上限：本技能不再适用的情况

在规模最大、采用专业运营方式的活动中，本技能设计的工作人员队伍会被资金取代。签到和注册服务台、安保及视听工作都由外包人员供应商承接，并且没有当天志愿者项目需要运营。如果活动有带薪的活动团队和人员预算，本技能就不适用：应改为采购劳动力，使用 samber/dev-event-organizer-skills@event-vendor-sourcing。

在更高一层，常设组织团队也有同样的上限，见 samber/dev-event-organizer-skills@event-team-structure 的带薪聘用门槛。两者描述的是大致处于同一规模时的同一转变。

访谈

一次只问一个问题；适合时使用选择题。设置问题 6—8，是因为下方的选项在见效速度、持久性和投入方面差异很大——不能替用户决定默认顺序。

1. 活动是什么形式、参会人数是多少、举办几天、同时开放多少个会场，以及是否有注册或徽章服务台？
2. 是否已有活动流程表或逐小时日程，其中是否列明需要有人值守的岗位？（如果没有，工作流第 1 步会建立一份临时岗位清单——这是唯一能得出有据可依的人数估算的输入。）
3. 常设团队中由谁负责志愿者：指定的负责人，还是谁有空谁负责？（常设职责本身定义于 samber/dev-event-organizer-skills@event-team-structure；本技能说明该负责人随后要如何开展工作。）
4. 活动是否有行为准则和指定的响应团队？志愿者目前是否处于报告流程中？
5. 哪些岗位会处理参会者个人数据、现金或付款，或徽章和注册记录？
6. 最迟何时必须确定人员名单？是什么因素决定了这个日期——T 恤订购、徽章印制、说明会，还是仅仅活动日期？（有明确的截止日期时，应优先选择见效快的渠道。）
7. 这是一次性活动，还是会定期举办、让本届志愿者成为下一届人员名单的一部分？（需要积累成果时，应优先选择更持久的做法：书面岗位目录、保留往届志愿者名单。）
8. 投入上限是多少：活动前协调员可投入多少小时、当天是否有人进行现场协调、T 恤和餐食预算是多少，以及两届活动之间是否会维护任何资料？
9. 默认排序假定不存在的东西中，现有哪些已经具备？
   • 上一届的志愿者名单。
   • 可以派出一批人员的本地用户组或学生分会。
   • 可以承载报名流程的注册系统。
   • 书面岗位目录。
   • 拥有自己的志愿者队伍的上级组织。

规模阶梯

规模及其带来的正式程度，会改变下文的每项机制。无论活动由社区还是公司举办，登记台都需要相同数量的工作人员——一场由公司举办、面向 200 人的活动，所需登记台工作人员的配置与社区活动完全相同。活动分为三个不同的阶梯。

• 非正式、依靠人脉招募（聚会，规模最多几百人）。志愿者是很晚才临时加入的事项：DevOpsDays 的指南在活动前一个月才提到志愿者，此时门票销售和赞助招募已完成；志愿者通过个人关系网招募，以参与活动作为回报。在这个阶梯的最低端，组织团队_本身就是全部志愿者_，对于首届活动来说，这是完全合理的选择——参见 samber/dev-event-organizer-skills@event-first-edition。
• 成熟的项目体系（约 1,000 名参会者起，多会场、多日）。有公开的岗位目录、报名系统、固定的轮班时长、专门的协调频道，以及以周为单位计算的提前期：
  • FOSDEM 会在活动前约 6 至 7 周开放报名。
  • PyCon US 通过大会个人资料系统管理班次认领。
• 专业配备人员（参见上文的范围上限）。不使用志愿者队伍。

如果某项建议在不同阶梯下有所不同，请说明它适用于哪个阶梯。大多数读者都处于中间阶梯，而且两个方向的失误都可能发生：

• 在大会规模的活动中采用 DevOpsDays 提前一个月、仅依靠人脉招募的方式，会导致岗位空缺。
• 为一场 150 人的活动搭建 FOSDEM 那样的志愿者网站，会把协调人员一周的时间花在本可用电子表格完成的工作上。

工作流

1. 列出岗位，而不是人员。 按小时梳理活动流程，记下每个必须有人到场值守的岗位：签到处、信息台、每个需要负责人的会场、衣帽间、机动人员、布置和撤场、视听支持。如果还没有活动流程，就根据日程先编一份临时岗位清单，并标记待 samber/dev-event-organizer-skills@event-run-of-show 生成正式流程后核对。凡是面向公众的闭幕环节，都要把入口单独列为一个岗位：否则迟到者的问题会落到离门最近的组织者身上，而不是排班表上的值守人员。也要把活动自身的情感高潮——如开幕主题演讲、闭幕仪式——列入岗位清单，不要想当然地认为组织者会非正式地照看；书面计划最实在的好处，就是让原本要负责会场的组织者也能坐下来观看。
2. 加入行为准则要求的岗位。 其响应团队需要由活动期间可联系到的明确人员组成。将这项名册要求视为来自 samber/dev-event-organizer-skills@event-code-of-conduct 的既定要求；本技能负责招募并排班，不负责重新设计团队。
3. 自下而上计算所需人数。 对每个岗位：同时所需人数 × 必须覆盖的小时数 ÷ 班次时长 = 班次名额。将名额相加，除以一名志愿者实际会承担的班次数（在报名表中询问；不要假设），再加上机动人员储备。已公布的参考数据和计算示例见 references/sizing-and-shift-planning.md。绝不能根据参会人数推算所需人数。
4. 编写岗位目录，详细程度按第二个菜单的选择确定，并参考 references/role-catalog-and-fit-criteria.md。每个岗位都要写明适配条件，不能只有岗位名称——FOSDEM 的引导员岗位要求能够自信地在最多 800 人的会场发言，信息台岗位则要求能够处理现金。
5. 按第一个菜单选择的渠道开展招募，并预留所选级别要求的提前量。报名开放前先发布岗位目录：人们要选择岗位，而不是时段。
6. 逐一确认每位报名者的姓名，并为其指定一位明确的协调员。 没人回复的报名只是一份名单，活动当天岗位仍会空缺。
7. 编制班次表，并将到场缓冲时间计入已公布的时段。 志愿者应在岗位开始前到场，而不是等到开始时才到；缓冲时间属于班次的一部分，不是额外的善意付出。对首次担任岗位的志愿者应延长缓冲时间——PyCon US 要求分会场主席提前 15 分钟到场；首次担任该岗位则提前 30 分钟。
8. 在每位志愿者首次上岗前进行说明。 无论其他安排多么非正式，说明中都必须包含以下内容：该岗位的具体工作流程、需要升级处理时联系谁以及通过哪个渠道联系，还有面向志愿者的行为准则升级处理话术。这两份材料，无论是内容详尽的版本还是最精简的版本，都认同最后这一项——DevOpsDays 虽然只用一句话说明，仍然指示组织者“培训工作人员和志愿者”，让他们了解如何处理违规行为。参见 references/briefing-and-coverage-protocols.md。
9. 发布值守规范，说明：
   • 无法参加班次时如何报告。
   • 接班人员迟迟未到时要等多久。
   • 应联系谁。
   • 为每个班次指定一位明确的负责人，负责现场指导该班次的各个岗位；志愿者若只能听从碰巧在附近的人员所发出的相互冲突的指示，就会造成协调失灵，而设置这个单一联系点正是为了避免这种情况。
   • 维系整份排班表的规则：确认替班人员到位前，不得离开岗位。
10. 认可志愿者的付出，然后交接后续工作。 按第三个菜单设置与班次和岗位挂钩的福利。所有关于如何让同一批人参加下一届活动的安排——校友名单、留任机制以及与特定班次无关的认可——都属于 samber/dev-event-organizer-skills@event-volunteer-experience。 如果你的 harness 具有持久记忆，请存储岗位列表及每个岗位的人数、有效的班次时长、哪些岗位在什么时间出现人手短缺、未到岗率及补上了多少人，以及所有完成班次人员的姓名。这样，下一届就能从真实的岗位列表和真实的人员名单开始，而不是从空白页开始。

排序后的菜单

以下所有排序都只是默认方案，而非铁律。排序会因情境和执行人员而变化。呈现三个菜单中的任何一个之前，都要根据访谈重新排序，并说明哪个回答让哪个选项发生了变化：

• 紧迫的人员名单截止日期（Q6）会优先考虑能在几天内招满人员的渠道。
• 周期性任务要求（Q7）会优先考虑只需编写一次、即可重复使用的内容。
• 默认方案未考虑的资源（Q9）可能直接胜过推荐选项：上一届的志愿者名单能让首选渠道变成一封邮件，而愿意派出 8 人的本地用户组可以独自负责整个区域。

如果访谈表明某个选项不可行，就从计划中删除，而不是把它放在列表底部。被排除却仍留在列表中的选项，会在活动前 2 周重新变成工作范围。

**简报深度不会提供菜单，这是有意为之。**对其排序只会制造虚假的精确感：第 8 步中的三个组成部分，交付成本大致相同；无论志愿者简报的内容多么详尽，都会包含这三项。没有值得推荐的高效子集。

招募渠道

效率：直接通过人脉邀约 > 回访过去的志愿者 > 需注册的报名表 > 与本地团体建立合作 > 专门的志愿者网站。

• 价值（岗位可靠有人值守）：专门的网站 > 需注册的表单 > 与本地团体建立合作 == 回访过去的志愿者 > 直接通过人脉邀约
• 工作量：专门的网站 > 与本地团体建立合作 > 需注册的表单 > 回访过去的志愿者 > 直接通过人脉邀约
• 合规成本：专门的网站 > 需注册的表单 > 回访过去的志愿者 > 与本地团体建立合作 == 直接通过人脉邀约

支配关系检查：5 个梯级，10 对比较，严格支配关系为零——这只是构造上的结果，而构造上的结果绝不算通过。 有 3 种机制阻止了这 10 对支配关系，单靠其中任何一种都无法解释完整的渠道菜单：

• 8 对以常规方式不满足条件：覆盖面更广的梯级至少有一个成本轴更高。
• 1 对只在合规成本上不满足条件，这一点值得说明：需注册的报名表在价值和工作量上都胜过与本地团体建立合作，唯一的阻碍是，建立一个信息收集点所需的审查成本高于与团体进行一次沟通。
• 最后一对是与本地团体建立合作和回访过去的志愿者，两者价值持平，而各自在不同的成本轴上更低，因此没有一方能在两个成本轴上都至少与另一方持平。

这 3 个原因都不能算作证据；效率排序依赖于下方的论据。

直接通过人脉邀约效率最高，因为它只需花一个下午发消息，而回复的人已经认识组织者，这也是他们愿意到场的主要原因。它的上限很低，大约只有十几个人，这正是渠道阶梯还需要继续往下排的原因。

两个 == 平局都是真实的：

• 价值：与本地团体建立合作和回访过去的志愿者，都能通过一次沟通确认数名志愿者，且人数上限都取决于另一端团体的规模。
• 合规成本：两者都不会建立信息收集点，因此两者唯一产生的记录，都是你本来就在维护的名单。

合规成本在这里是真正的评估轴，不是凑数的。任何收集报名信息的渠道，都会收集非参会者的姓名、电子邮件、电话号码，通常还会收集饮食需求和 T 恤尺码等信息，因此需要在提交第一份表单之前制定保留规则并明确负责人。保留过去志愿者名单也是同样的决定，只不过是早在一年前做出的，而且很容易被忘记。

默认方案：回访过去的志愿者，加上需注册的报名表。 参会人数约低于 150 人时，仅靠人脉邀约就是完整方案。

资源不足：专门的志愿者网站——价值最高，但两个成本轴也都最高，因此每一轮效率比较都会将它淘汰。以下情况可考虑采用：

• 房间数量超过一名协调员手动安排的能力。
• 志愿者必须能自行安排跨越多天、多房间的班次。
• 活动会定期举办，网站可一次搭建、重复使用。

FOSDEM 恰好符合这一条件。

排名之外的补充：在台上发出求助呼吁。 在黑客马拉松或聚会结束时公开招募志愿者，曾招募到新的组织者。对于活动当天的志愿者而言，这属于直接通过人脉邀约的一种形式，而不是第六个梯级：现场气氛正好，大家也已经认识组织者。呼吁时要明确说明具体岗位、日期和时段，并指定一名协调员，在几天内回复每一条消息——否则它就会沦为下方那个被删除的梯级。对于想承担长期职责而非只值一个班次的人，请引导他们前往 samber/dev-event-organizer-skills@event-team-structure。

已删除，而非降级：没有指定协调员、没有确认环节的公开招募。 请在所有地方删除这种做法。在公告频道发布志愿者招募信息，却无人回复报名者，结果只会得到一份名单和一张无人值守的服务台；直到活动当天早上，它看起来都和真正有效的渠道没有区别。

岗位目录深度

效率：按区域设置明确岗位 > 完整的逐岗位目录 > 目录加逐岗位培训门槛 > 不加区分的人员池。

• 价值：目录加培训门槛 > 完整的逐岗位目录 > 按区域设置明确岗位 > 不加区分的人员池
• 工作量：目录加培训门槛 > 完整的逐岗位目录 > 按区域设置明确岗位 > 不加区分的人员池
• 合规成本：目录加培训门槛 > 完整的逐岗位目录 > 按区域设置明确岗位 > 不加区分的人员池

支配关系检查：4 个等级，6 组配对，严格支配关系为零——这只是通过构造确保的干净结果，并不代表合格。 三个维度的排序完全相同，因此有一个机制阻断了所有配对：目录越深入，收益越大，但两个成本维度也严格越高。这也涵盖了与不加区分的人员池的配对——它在价值上落败，而不是免费赢得任何优势；下文的警告则说明了这种低成本究竟会造成什么后果。这项检查什么也没发现；这个排序只是论证出来的。

按区域设置明确岗位——注册、信息、场地、布置与撤场、机动人员——效率最高，因为只需一页内容，就能消除活动当天最大的单一故障：志愿者站在走廊里，却不知道自己负责什么。

合规成本的排序值得警惕，因为它恰好与各选项留下的风险相反。记录某个岗位负责现金或注册记录，就会引发关于哪些人可以接触这些数据的讨论。

不加区分的人员池完全不会引发讨论，而且还会导致一个从未经过审核的陌生人独自接触注册用笔记本电脑。纸面上便宜，现实中代价高昂。

默认选择：按区域设置明确岗位，并将 Q5 中提到的岗位——任何涉及付款或注册记录的岗位——分配给具体的指定人员，而不是由任何人自行认领。

优先投入不足的选项：目录加逐岗位培训门槛——价值最高，同时两个成本维度也最高。对于任何涉及金钱、个人数据，或处理不当就会导致某场活动中断的设备的岗位，都应采用这一方案。FOSDEM 只对这类岗位设置门槛，不做更多要求：新加入的信息台志愿者在处理交易前，会接受销售点系统培训。这是一个五分钟、适时进行的门槛，而不是让所有人参加一整天的培训。

应当删除，而非降级：不加区分的人员池，适用于任何涉及现金、参会者记录，或作为行为准则报告首要受理点的岗位。只有在组织团队本身就是全部志愿者时，才保留这种做法。

认可方式

这里的每个层级都与值班挂钩。活动结束后才给予的认可——例如发布感谢名单并列出志愿者姓名、保留往届志愿者名单、校友联络机制——属于 samber/dev-event-organizer-skills@event-volunteer-experience，并设有本清单未评估的同意门槛。

效率：以值班换取参与机会 > 值班结束时点名致谢 > 妥善提供餐食 > 赠送可留作纪念的志愿者 T 恤 > 与值班挂钩的身份福利。

• 价值（完成的值班次数，以及回归的人数）：妥善提供餐食 > 以参与机会换取值班 > T 恤 > 与值班挂钩的身份福利 > 值班结束时点名致谢
• 所需精力：T 恤 > 妥善提供餐食 > 与值班挂钩的身份福利 > 以参与机会换取值班 > 值班结束时点名致谢

这里不适用合规成本维度：T 恤、餐食、座位和口头致谢都无需审核，而且可以在下一届活动中调整。公布志愿者姓名才会带来这种曝光，而它不在本清单中——参见上面的相关条目。本节底部删去的那一项，则是出于另一种曝光风险。

以值班换取参与机会，是两个成熟项目都在使用的机制；对于免费或未售罄的活动，这不会产生任何费用。它有两种值得借鉴的公开做法：

• 为志愿者预留他们负责值班的场次座位——PyCon US 会提醒教程主持人报名参加自己想听的教程。
• 在 FOSDEM 担任引导员时坐在前排——将活动参与机会直接作为担任会场引导员的回报。

T 恤虽然被列为一种认可方式，但它在实际运作中也很有用：与会者能通过它在走廊里找到志愿者。FOSDEM 用颜色区分 T 恤——普通志愿者穿橙色，视频团队穿绿色——这样一项福利就变成了导引系统，因此即使预算削减，也比纯粹的福利更可能保留下来。

在报名表中询问每位志愿者希望从当天的活动中获得什么：想听的演讲、想认识的人、想练习的技能、曝光机会。组织者提到，人脉、学习、减少孤立感、乐趣，以及自由职业者所需的业务线索，是让他们持续参与的原因；正在走向组织者岗位的志愿者也有相同需求。根据对方表达的需求安排岗位无需花费，而有效的「以参与机会换取值班」也正是靠此实现的。

默认做法：以参与机会换取值班，并为岗位提供餐食。 对于免费或自行安排餐食的活动，这两项的成本几乎为零，而且都出现在阶梯的每个层级中。

容易被忽视：妥善提供餐食——它在价值维度上排名最高，却仍排在两项几乎不费力的选项之后，因为餐饮需要预算，而且餐饮承包商需要提前数周得知人数。如果值班时长超过约 3 小时、覆盖用餐时间，或安排在活动时间之外，就应提高其优先级。FOSDEM 会为这些情况提供餐食：

• 为正在值班的志愿者在信息台提供饮料和点心。
• 为较长的班次提供餐券。
• 为布置、清理和运输团队提供完整的餐食安排。
• 为无法离岗的岗位安排工作人员送餐。

删除，而非降级：现金津贴。 向志愿者付费会改变双方安排的性质，而随之而来的身份认定问题，一旦首笔款项发出，在本届活动期间就无法逆转。技术活动的志愿者项目不会发放津贴，而这种做法的一贯性本身就是一种信号。

失败模式

• 按参会者比例确定规模。 流传的唯一数据来自某场活动的最后一届，描述的是一个已经超出承载能力的团队。改进方法：从岗位和工时出发，自下而上估算（第 3 步）；参会人数不参与计算。
• 在大型会议开始前一个月招募志愿者。 DevOpsDays 提前一个月招募的做法确实存在且合理——适用于通过人脉招募、规模只有几百人的活动。改进方法：在已制定活动方案的阶段，至少提前六周开放报名，并分阶段发送提醒；名单截止日期应由 T 恤订购和简报安排决定，而不是活动日期。
• 排班表没有明确的替补规则。 可预见的问题不是有人没来，而是值岗人员离开了岗位。改进方法：公布等待后升级处理的流程，并明确规定：未经确认已有替补，任何人都不得离岗（第 9 步）。
• 让志愿者负责行为准则一线响应，却不给他们话术。 任何志愿者都可能是收到举报的第一人，不只是指定的响应团队成员。改进方法：向所有人讲解五步升级处理话术，包括他们无需与任何人当面对质这一点。
• 简报未提及提前到场的缓冲时间。 “你的班次 14:00 开始”会让志愿者 14:00 到场，然后领取 T 恤、寻找房间，最后到 14:20 才抵达岗位。改进方法：将缓冲时间纳入班次时间，并为首次参与者预留更多时间。
• 几个人在同一班次中指挥同一名志愿者，却各自不知道其他人对其说了什么。 这是不同于 Q6／第 9 步确认流程的协调失误：它会在班次进行中实时发生，影响已经在岗位上值守的人员。改进方法：值岗流程应为每个岗位的每个班次指定一位明确的联系人，由其负责现场指挥；这样志愿者只需找一个人确认，而不是询问碰巧路过的人。
• 合并两个“runner”岗位。 FOSDEM 的 Runner 是在候场区待命、随时接受任务的通用机动人员；PyCon US 的 Session Runner 则负责引导演讲者，按紧凑的 15 分钟间隔工作。名称相同，工作却不同。改进方法：在自己的岗位目录中将二者分开命名；活动若将两者合并，最终哪个岗位都做不好。
• 成功的招募呼吁让协调员不堪重负。 招募呼吁如果效果很好，一周内就可能让志愿者人数大增；有个团队的运营人员从 1 人增至约 15 人。改进方法：在发出招募呼吁前公布岗位目录，为每位首次参与的志愿者安排一位返场志愿者搭档，共同值完其第一个班次；并将简报安排成正式场次，而非一对一进行。
• 为只有 150 人参加的活动搭建志愿者网站。 过度投入确实是一种失败，不只是投入不足。改进方法：根据当前阶段选择合适做法，并在开发任何可复用内容前，重新阅读资源不足选项的升级条件。

衡量指标

衡量岗位覆盖和简报完成情况，而非报名人数。报名人数是最容易显得不错的指标，但活动可能在周六 15:00 就会出现人手不足。

• 已覆盖的岗位时段，占排班所需岗位时段的比例。 这是唯一能回答人员名单是否足够的数字。按小时计算，而不是按天汇总——即使人员安排全天看似平衡，也可能仍有空缺。
• 有明确指定的替补人员的岗位比例。 这与上述指标不同，也更能预示下午是否会出问题。
• 缺席率，以及缺席后在岗位空缺前确认替补人员的比例。 后者才是流程实际能够控制的部分。
• 首次值班前完成简报的志愿者比例，包括升级处理话术。 目标为 100%。
• 按时开始的班次比例，以公布的时间为准，并计入缓冲时间。

达标线，并持续迭代直至达标：排班中的每个岗位时段都有明确指定的人员和替补人员；每位志愿者都在首次值班前听取了升级处理话术的简报。这两条标准由团队自行设定，并非外部标准。它们可以根据你制定的排班表进行核查，而不是对照行业数字——这也正是它们实用的原因。

调用示例

• “举办一场有 400 人参加、为期一天、设有 3 个分会场的会议，需要多少名志愿者？” → 先进行访谈，然后按步骤 3 自下而上计算；拒绝回答比例问题，改为提供岗位清单。
• “距离活动还有两周，但只有 4 人报名。” → 根据截止日期严格调整招募方案的优先级：联系过去的志愿者并发动人脉，同时减少岗位，而不是让岗位人手不足。
• “简报时要告诉志愿者什么？” → 参照步骤 8 和 references/briefing-and-coverage-protocols.md；无论规模大小，升级处理话术都是必需的。
• “我们有位场地志愿者刚发消息说今天下午来不了。” → 按照覆盖流程，在协调频道中说明岗位和时段；在确认替补人员之前，不要让当前人员离岗。

预期输出：包含各岗位人数的岗位清单、注明到岗缓冲时间和指定替补人员的班次表、包含适配标准的角色目录、注明日期的报名与确认计划、简报话术，以及已公布的覆盖流程。

参考资料

• samber/dev-event-organizer-skills@event-code-of-conduct - 包含政策、响应团队组成和事件处理手册；此技能负责为响应团队招募和排班，并向每位普通志愿者说明升级处理话术。
• samber/dev-event-organizer-skills@event-run-of-show - 以此技能的班次计划为输入，编写活动期间各岗位的工作安排；两类简报分别进行。
• samber/dev-event-organizer-skills@event-volunteer-experience - 关注班次结束后的关怀与留任；包括不与具体班次挂钩的认可、校友联系机制，以及邀请志愿者参加下一届活动。
• samber/dev-event-organizer-skills@event-team-structure - 负责常设组织团队的结构，其中 Volunteer Lead 是明确指定的角色；其职责范围上限与此技能一致。
• samber/dev-event-organizer-skills@event-attendee-experience - 负责为签到台、帮助台和餐食发放等岗位安排人手，这些岗位均由此人员名单覆盖。
• samber/dev-event-organizer-skills@event-first-edition - 适用于首届活动中创始团队就是全部志愿者的情况。