event-volunteer-experience

活动志愿者体验

你负责照顾 samber/dev-event-organizer-skills@event-volunteers 已经招募的人员，关注该技能不涉及的两个时段：他们不在岗位上值守的时间，以及活动结束后的几周。

两项输入，都不是由你编写：一份已完成的排班表，以及一套通用的接待标准。

三项输出：

• 志愿者实际可用的非值班计划
• 针对志愿者的接待补充方案
• 一份收尾版本——致谢、按保留规则记录，并交给下一次负责招募的人

边界在哪里

samber/dev-event-organizer-skills@event-volunteers 从自身角度划定了分界。其认可菜单的每个级别都与班次挂钩，并将活动结束后的认可交由这里处理：发布点名感谢志愿者的内容、保留往届志愿者名单、校友联络。值班餐食、T 恤以及在你负责的房间里安排的座位都归它处理，不在这里重新决定。

只沿一个方向修正这条界线，并在修正时说明：本版本中的非值班关怀也归你负责。 该技能会涉及到场缓冲时间和班次时长；但绝不会涉及志愿者离岗期间做什么、吃什么或坐在哪里。

• 绝不重新讨论名册人数、班次时长或人数计算。 将要求交给上游处理。 “每位志愿者都需要一段连续的离岗休息时间”是该技能自下而上计算人数的输入，而不是你在这里做的修改。

• 两个菜单中各有一个相同级别，这就是分界。 samber/dev-event-organizer-skills@event-volunteers 将“班次结束时点名致谢”列在其班次认可菜单中：这是当场口头致谢，其自身文本明确排除发布姓名（“发布志愿者的姓名才会带来这种曝光，但这不在本菜单中”）。活动结束后公开发布的感谢内容归你负责——包括姓名列表、征求同意和允许选择退出。绝不能让一条消息同时承担这两种用途，否则就会漏掉征求同意的环节。

• 绝不重新决定餐饮标准、饮食与过敏原政策或标识。 samber/dev-event-organizer-skills@event-hospitality 为所有人群制定这些内容，而你只添加志愿者层面的内容，结构与 samber/dev-event-organizer-skills@event-speaker-experience 为演讲者采用的方式相同。餐饮技能自己的边界表将非值班期间的补给交给你，其中的饮食、过敏原和酒精相关要求沿用既有规定，不再重新争论；值班岗位上的食物则交由 samber/dev-event-organizer-skills@event-volunteers 处理。

• 绝不撰写角色定义。 将表现突出的志愿者标记为候选人，然后就此打住；samber/dev-event-organizer-skills@event-team-structure 负责角色分类，以及发出邀约后的一切事宜。

• 绝不涉及行为规范。 samber/dev-event-organizer-skills@event-code-of-conduct 负责政策和响应团队，而 samber/dev-event-organizer-skills@event-volunteers 已经向每位志愿者说明了升级处理流程。志愿者关怀不延伸到志愿者安全事件报告。读者若误以为它包含这项内容，就会写出第二套相互冲突的流程。

• 你的感谢面向外部；复盘不是。 samber/dev-event-organizer-skills@event-debrief 从不向参与者发送问卷或消息，因此不存在职能冲突。它在内部评估志愿者运营的表现；你则直接向志愿者本人沟通。

• 校友联络归你负责，而 samber/dev-event-organizer-skills@event-community-building 在构建时必须与此保持一致。 你负责为_本_版本的志愿者做收尾——致谢、保留名单、候选人标记。该技能负责长期、跨多个版本的社群工作，而这份名单之后也会纳入其中。

  这一划分基于 samber/dev-event-organizer-skills@event-volunteers 已经发布，并明确将下一版本的志愿者相关内容交由这里处理。另一个技能也会从自身角度与此保持一致：它将受众限定为从未担任过班次的社群成员，并将校友联络作为其覆盖范围中的一个部分来运作，而不是另建一个空间。

• 这里不负责志愿者反馈。 samber/dev-event-organizer-skills@event-feedback 会对参会者、演讲者和赞助商的调查问卷进行分组，但不涉及志愿者。志愿者问题集更接近该技能的职责，而不是本技能的职责，因此要明确说明这一点，而不是将其纳入这里。

访谈

一次只问一个问题；适用时采用选择题。之所以有第 5 至第 7 个问题，是因为下面的菜单在见效时间、持久性和投入精力方面各不相同，因此不能替用户选定这些默认项。

1. 如果志愿者不来做这项工作，他们原本会以参与者身份出席吗？他们是否放弃了一张门票（无论收费还是免费）来承担这项工作？
2. 排班表是否已经确保每位志愿者至少有一段连续的离岗时间？活动日有多长？
3. 场馆在活动日程区域之外能提供什么？一间全天可用的房间、一处角落，还是无处可用？
4. 以前的活动是否已经建立过往届志愿者名单？由谁负责？名单是否设有删除日期？
5. 必须在什么日期前完成收尾？是什么决定了这个日期——下一届的志愿者招募、回顾总结、场馆发票，还是没有明确安排？
6. 这是一次性活动，还是定期举办、且本届志愿者会成为下一届人员名单的活动？
7. 活动结束后，精力投入的上限是多少？活动结束一周后还有谁在工作？除了班次本身，是否有志愿者专项预算？
8. 是否有未成年志愿者，或在他人的雇佣或保险安排下到场的志愿者？（这种情况需要转交审核，绝不能由此技能给出答案。）
9. 两届活动之间是否已有固定的社群空间？由谁负责？（这决定了校友联系环节有多少本来就归你负责。）
10. 回归的志愿者是否会承担与新人真正不同的工作？

工作流

1. 查看相关技能已经确定的内容：排班表、与班次挂钩的福利，以及未经确认有人接替就不得离岗的规则。这里不会重新讨论这些内容。
2. 将常规接待标准视为既定要求。 只记录你为志愿者额外增加的部分，这样补充内容就能与标准清楚区分，便于审计。
3. 使用第一个菜单设计离岗时间。 将结果作为要求交给 samber/dev-event-organizer-skills@event-volunteers，而不是由你修改排班表。
4. 使用第二个菜单确定离岗接待等级，依据问题 3 中实际可用的场地，以及步骤 2 中的标准。
5. 为本届活动收尾：征得同意后公开致谢；将名单记录在案，注明负责人和删除日期；并向常设团队标记可能的候选人。
6. 移交名单。 下一届的招募从这份名单开始。注明接收人和移交时间，确保这是一次正式交接，而不是无人承接的文件。

任何面向志愿者的信息和任何已发布的权益承诺，都必须先给用户查看。排班表无法兑现的离岗承诺比没有承诺更糟，因为志愿者会据此安排自己的日程。

如果你的运行环境支持持久化记忆，请按届记录：

• 哪些志愿者有可用的离岗时间段，哪些没有
• 离岗补充安排的实际成本
• 向谁致谢，以及谁同意被公开提及
• 谁表示愿意回归
• 名单存放位置及其删除日期

这份记录能让下一届的联系环节由你负责，而不是照搬此技能的默认做法。

排序菜单

以下每种排序都是默认方案，而非铁律——它会随情境和执行者而变化。呈现菜单前，请根据访谈重新排序，并说明哪个回答让哪个选项发生了变化。

三种效率排序、每个默认阶梯、每项提升条件以及每项删除，都是本技能自行设计的，并非经测量得出的排名。 如果有具名活动采用了其中某种做法，会在相应位置注明。没有已发表的数据比较这些阶梯在志愿者回归率方面的差异。请将每种排序视为一个起点，根据你对自己活动的了解推翻它，并在呈现时说明这一点。

默认方案忽略的一项现成资源，足以让推荐阶梯黯然失色：已有的往届志愿者名单（Q4）能将第三个菜单的大部分内容压缩成一封邮件；而已有他人负责的常设社区空间（Q9），意味着你甚至不必建立校友社群。

如果访谈表明某个选项不可行，就应将其从计划中删除，而不是放在列表底部。留在列表中的不可行选项，会再次成为计划范围的一部分。

值班外时间

志愿者不在岗时可以做什么。不包括他们负责的场次中的席位——那与班次挂钩，属于相邻主题。

效率：值班外指引 > 指定的个人参会时段 > 已公布的值班外保障 > 不作安排。

• 价值（亲历过活动、并表示会参加下一届的志愿者）：指定时段 > 值班外指引 > 已公布的保障 > 不作安排
• 投入（协调工作，以及计入相邻主题的排班人数计算）：指定时段 > 已公布的保障 > 值班外指引 > 不作安排

这里不适用合规成本这一维度：这些选项都不会收集数据、发布任何与个人有关的信息，或触发审查。

这里的价值和投入顺序不同，二者之所以不同，取决于一项推断。这项推断来自本技能本身，并非经测量得出的发现：

• 相邻技能按 2-3 小时规划班次，而一场活动日比一个班次长好几倍。
• 因此，大多数志愿者本来就有值班外时间，无需任何人专门安排。
• 他们缺少的是知道这段时间里值得去参加什么。
• 一则指引恰好能满足这一点。而一项保障只是提供他们本来就有的时间。

Q2 是打破这一推断的关键问题。如果排班表没有留下空闲时段，保障就不再是多余的，顺序也会反转。

• 值班外指引 - 默认选项。给值班外的志愿者一则简短的实时说明，告知当前正在进行的活动以及哪里还有空位，并利用现有日程和流程表。投入几乎为零，而且能让志愿者利用已有的时间。
• 已公布的值班外保障 - 在已公布的班次安排中明确规定最低离岗时长。成本不在于撰写安排，而在于计入相邻主题的排班人数计算。如果 Q2 的答案表明，排班表并未给每位志愿者都留出连续的空闲时段，就应将其优先级提到指引之上，因为如果志愿者没有空闲时间，再好的指引也无从指向。
• 指定的个人参会时段 - 资源紧张时的选项：每位志愿者指定自己绝不会错过的场次，在分配班次之前围绕这些场次安排排班。1995 年的 World Wide Web Conference 将这一做法直接写入自己的志愿者排班政策：协调人员围绕每位志愿者选定的场次安排空闲时间，或者把该志愿者安排到这些场次工作。PyCon US 则针对一种职位采用了更有限的版本：报名担任自己最想参加的教程的 Tutorial Host，就能以这种方式确保获得席位。此选项的价值和投入都居首，因此效率永远不会选择它。如果 Q1 表明志愿者放弃了原本会使用的门票，且 Q6 表明本届活动还会再次举办，就应优先考虑此选项。对这些志愿者来说，“我负责了这场活动，却什么都没看成”会决定他们明年是否再来。
• 不作安排 - 由排班表留下多少时间，就有多少时间。应将其明确作为一种选择，而不是无意间落入这种情况。对于班次较短、工作量较轻的活动，这种做法是合理的。

删除，而非降级：允许志愿者在岗位清闲时擅自离岗。 将其从此菜单和上方的各维度说明中删除。它看似是页面上成本最低的选项，却直接违背相邻主题已公布的岗位保障规则：未经确认有人接替，任何人都不能离岗。这样做导致的后果不是错过一场活动，而是一个无人知道已经无人值守的服务台。

非值班接待档次

在通用标准基础上，为志愿者提供的额外安排，适用于离岗时间。与班次挂钩的部分——岗亭供餐、长班次餐券、为布置和撤场团队提供的餐食——已属于同级技能的范围，此处不再重复。通用餐食安排以及志愿者下班后使用的安静室，由 samber/dev-event-organizer-skills@event-accessibility-inclusion 和 samber/dev-event-organizer-skills@event-attendee-experience 决定，此处不作讨论。

效率：非值班供餐权限 > 志愿者休息空间 > 志愿者社交餐 > 仅与参会者同等待遇。

• 价值（让志愿者在漫长的一天结束时仍能保持状态，并愿意在下一届继续参与）：休息空间 > 社交餐 > 非值班供餐权限 > 仅与参会者同等待遇
• 工作量（房间、预算项目、人数统计、一场晚间活动）：社交餐 > 休息空间 > 非值班供餐权限 > 仅与参会者同等待遇

此处不推导合规成本维度。这些档次涉及的饮食、过敏原和酒精风险属于通用标准，已由 samber/dev-event-organizer-skills@event-hospitality 决定，此处沿用而不再争论——重复推导，就会导致两项技能各自形成不同的政策。

在此菜单的最高档，效率与价值的排序有所不同：休息空间的价值最高，社交餐的工作量最大，而最便宜的档次两者都不是第一，却在性价比上胜出。

• 非值班供餐权限——默认选项，而非值班档次必须从供餐安排开始。它面向离开岗位、因此在通用供餐队列中排在最后的志愿者。为值班期间无法赶上供餐时段的志愿者预留配额，并明确排队规则，避免他们把短暂休息耗在队伍里。FOSDEM 公布的福利属于与班次挂钩的部分：长班次志愿者可以免排队，工作人员会把食物送到岗位，或安排休息。将这一安排扩展到离岗时间，是本技能自行提出的做法。
• 志愿者休息空间——设在活动议程区域之外的一间房或一个角落，配有座位、水、自取零食，并明确允许离岗的志愿者使用。它在价值维度上排名第一，因为只有这一档能让人真正暂停工作。这是本技能自行提出的志愿者实践。当 Q2 显示活动日程很长或持续多日，或 Q3 显示确实有可用房间时，应将其提升为默认选项。
• 志愿者社交餐——投入不足的选项：在最后一班结束后，为志愿者提供餐食或饮品。它的工作量最大，价值排名第二，因此效率排序始终不会选它。当 Q6 显示活动将会再次举办时，应将其提升为优先选项，因为它带来的回报要等到本届活动结束后才会显现。DevOpsDays 将讲者晚宴和小型感谢礼品列为单独支出项目。将这一做法延伸至志愿者，是本技能自行提出的做法，但并不能直接照搬：讲者是受邀嘉宾，而志愿者是活动运转所依赖的劳动力；讲者的预算按讲者名单编制，而同一活动的志愿者名单通常规模更大。
• 仅与参会者同等待遇——志愿者在自己的时间里吃参会者吃的东西。对于短期、仅有一个班次的活动，这是合理的。应将其明确列为一项决定。

已删除，而非降级：将活动的安静空间或无障碍空间改作志愿者休息室。 从此菜单及上方的各维度排序中删除。它看似免费，实则不然。这个房间的存在是为了让无法置身于互动环境中的人有所去处，而 samber/dev-event-organizer-skills@event-accessibility-inclusion 已为这类人群安排了该空间。让离岗志愿者占用它，会破坏这处空间原本要保障的特性。借用其他房间，或不安排房间。

活动收尾与校友循环

最后一班结束后会发生什么。认可与延续属于同一菜单，而非两个。 两者都在同一周内由同一个人决定，预算也都几乎为零。两者都以同一个结果衡量——志愿者再次参与；而没有保留名单，身份标记这一阶就无从存在。

效率：保留往届志愿者名单 > 公开致谢 > 提名流程 > 常设校友频道 > 回归志愿者标记。

• 价值（回归的志愿者，以及涌现的组织者）：保留名单 > 提名流程 > 常设频道 > 公开致谢 > 回归志愿者标记
• 工作量（小时、持续投入、政治资本）：常设频道 > 提名流程 > 回归志愿者标记 > 保留名单 > 公开致谢
• 合规成本（触发审核、消耗可逆性）：常设频道 > 保留名单 > 回归志愿者标记 > 公开致谢 > 提名流程

合规成本在这里值得单独列为一个维度。除最后一阶外，每一阶都会持有或公开非参会者的个人数据；而保留名单是唯一会在收集它的那一届活动结束后继续保存的。保留义务继承自相关项目中的报名流程，并非在这里另行设定：将其应用于一份会在活动届次结束后继续保存的名单，而不是重新推导规则。

• 保留往届志愿者名单 - 默认选项，也是承重的一阶。samber/dev-event-organizer-skills@event-volunteers 将召回往届志愿者列为招募渠道中效率第二高的方式，并将其列入自己的默认方案；因此，没有这份名单，下届活动就无法在结构上实现该渠道。这是相关项目公开发布的默认方案，并非外部证据：它表明名单很重要，但没有人衡量过实际成效。创建名单当天，就为它指定负责人和删除日期。
• 公开致谢 - 列出姓名并发布帖子，点名之前先征得同意。效率排名第二，因为只需花一个下午；它也是唯一能让未参与志愿服务的人看到的一阶，因此既是招募渠道，也是活动收尾。它能触达所有到场的人，包括那些你再也不会见到的人。
• 提名流程 - 为表现突出的志愿者提供一条明确路径，使其与常设团队进行候选人交流。价值高，且完全不涉及数据披露。代价在于协调和政治资本。提出建议并交接：后续所有事宜都由 samber/dev-event-organizer-skills@event-team-structure 负责。设计这条路径时，应适配你自己的常设团队，而不是寻找可照搬的模板。references/alumni-list-and-handoff.md 借鉴了 DEF CON 自己的背书标准，作为建议应记录哪些内容的起始清单。在建议中增加一个字段：志愿者参与组织工作能获得什么回报。组织者留下来，是为了拓展人脉、学习、减少孤立感、享受乐趣；对自由职业者而言，还能获得服务线索。最常见的痛点是找不到本地的共同组织者，而在黑客松或聚会结束时公开寻求帮助，曾招募到新的组织者。收尾消息正是发出这一邀请的自然时机：感谢志愿者，然后说明有哪些组织角色尚待填补。
• 常设校友频道 - 一个能让名单在届次之间保持活跃的空间。它的工作量和合规成本都最高，因此效率排序从不选它；Q9 也可能表明这根本不是你该负责搭建的东西。只有在活动多年持续举办，且已有专人获得经费负责管理的情况下，才考虑采用。
• 回归志愿者标记 - 跨届次保留的身份标记。没有保留名单就无法存在，因此它无法省去上一阶的工作；而且它把认可给予的，是已经回归的志愿者——唯一不再需要确认是否会回归的群体。这就是它在效率排序中垫底的原因。提升条件，以 Q10 为依据：回归的志愿者承担真正不同的工作。 删除，而非降级：具有实际现金价值的正式报酬——抽奖奖品、差旅补助，或作为值班报酬而赠送的其他活动免费门票。将其从此菜单和上方的轴线中删除。一旦某项奖励看起来像工资，这种安排就不再是志愿服务；第一份奖励发出后，这个问题便无法逆转。这与同级内容中删除现金津贴的做法一致。TechCrunch 在自家活动中就采用了这种形式：承诺至少工作若干小时，即可获得一张标明美元价值、用于参加该公司旗下另一场较晚活动的通行证。这就是被删除的那一档在实践中的样子，也是它应当继续被删除，而非加上限制后成为菜单选项的原因。

作为邀请而非报酬提供的免费门票，是另一回事。如果要提供，请以书面形式说明它属于哪一种。没有惯例会将免费门票与_同一场_活动的下一届挂钩：现有的知名项目都是跨活动安排，属于同一主办方旗下的活动组合，而不是在某个定期举办的会议上，今年做志愿者、明年免费参加。

失败模式

• 从这里重新讨论班次表。 每项值班外权益都会影响人数，而人数计算属于同级内容的范围。解决方法：说明要求，提交给上游处理，并让排班表据此调整。
• 公布排班表无力兑现的值班外承诺。 志愿者会据此安排一天的行程，结果却不得不在承诺的休息时间继续工作。解决方法：公布前确认排班表能兑现这项权益，绝不能等到公布后再确认。
• 将指引理解为可以离岗。 解决方法：明确指引适用于已经离岗的志愿者。每次都要一并重申替岗确认规则。
• 挪用分配给其他人群的资源。 例如安静室、演讲者餐饮、赞助商休息室。解决方法：将志愿者的额外福利作为单独一项预算列出，无论金额多小；否则就不要提供。
• 未经询问就在公开场合点名致谢。 致谢帖也是一种公开发布。解决方法：报名时征求同意，或发布前询问，并提供无需说明理由即可选择退出的方式。
• 永远保留校友名单，却无人负责。 名单不再是留存名单，而会变成没人记得是谁收集、也没人记得负责的遗留责任。解决方法：第一天就指定负责人和删除日期，并主动续期，而非因无人反对就默认保留。
• 自行回答未成年人或保险方面的问题。 解决方法：明确需要审查，转交法律顾问和保险方处理，然后停止。

衡量指标

这些方面都没有基准：没有公开数据说明志愿者名单中应有多少人再次参与。以下每个阈值都是本技能自行设定的标准，而非测量所得；只有与往届相比，才能体现意义。

• 至少有一段连续离岗时间的志愿者比例（门槛），根据已公布的排班表统计，而非事后询问。如果不是 100%，说明这项权益没有得到保障。
• 至少参加过一场自选活动的志愿者比例（自行设定）。只有开始使用指引或明确列出休息时段后，这项指标才有意义。在活动结束时用一个问题询问。
• 本届志愿者中下届再次参与的比例（自行设定）。记录该比例，并且只与上一届相比。
• 名单完整性（门槛）：存在往届志愿者名单，且有指定负责人和删除日期。
• 同意完整性（门槛）：每位被公开点名的人都同意被点名。没有例外，因为例外情况正是会公开显现的问题。

两个自行设定的比例需要等到第二届才有参考意义。三个门槛则不需要，因此它们设有合格标准：根据已建立的排班表和名单逐项检查，并持续改进，直到三项全部达标。

调用示例

• “我们的志愿者忙了一整天，却没看上一场会议。明年该怎么办？” → 重新按 Q1 和 Q2 排序的非值班菜单。答案是一项向上游提交的要求，而不是修改排班表。
• “我们要不要设立志愿者休息区？” → 接待菜单。答案取决于 Q3 和当天的时长，而且这不是安静室。
• “活动结束后，我们该如何感谢志愿者？” → 收尾菜单中默认的两个层级，以及发布任何姓名前的同意确认环节。
• “我们希望明年还是这些人回来。” → 先建立留存名单，指定负责人和删除日期，然后交接给下一届的招募工作。
• “我们能把明年的免费门票作为感谢送给志愿者吗？” → 没有任何惯例会把赠票与同一活动的下一届挂钩。现有的具名计划都是跨活动的，性质更像报酬，而不是感谢。请决定你提供的是哪一种，并以书面形式说明。

预期输出：

• 一项向上游提交的非值班要求
• 一份针对志愿者、相对于通用标准明确增补内容的接待安排
• 一份妥善处理同意事宜的收尾计划
• 一份留存名单，其中注明负责人、删除日期，以及负责下一届招募的具名接收人

参考资料

• references/alumni-list-and-handoff.md - 留存名单结构、负责人和删除日期、向招募工作的交接，以及候选人标记
• references/closure-messages.md - 征求同意的收尾消息模板和示例

另请参阅同一合集中的内容：

• samber/dev-event-organizer-skills@event-volunteers - 招募志愿者、定义角色、规划轮班、进行简报，并负责与轮班挂钩的福利。其轮班表是此技能的输入；其往届志愿者回邀渠道则是此技能留存名单的去向。
• samber/dev-event-organizer-skills@event-hospitality - 制定不针对特定人群的通用标准；此技能在此基础上增补内容，而非重复陈述。
• samber/dev-event-organizer-skills@event-team-structure - 接收已标记的候选人，并从此处开始负责相应角色。
• samber/dev-event-organizer-skills@event-accessibility-inclusion - 负责安静且无障碍的空间；此技能不会借用该空间。
• samber/dev-event-organizer-skills@event-debrief - 在内部复盘志愿者运作；此技能则直接面向志愿者编写内容。
• samber/dev-event-organizer-skills@event-community-building - 负责各届活动之间持续运作的社群，留存名单属于其中，并从自身角度体现这一界限。