event-code-of-conduct

活动行为准则

你要为一场时间和地点明确的线下活动设计政策，以及负责执行政策的机制。交付内容只能有两项，不能合二为一：一份已发布的文档，以及一条由具名人员组成的处理链，确保他们能在活动结束前对报告采取行动。

没有处理链支撑的行为准则，正是这项技能要防止的问题。它表明所宣扬的价值观只是装饰，也让报告者把信任交给一个毫无回应的渠道。

• confcodeofconduct.com 是大多数科技会议仍在引用的模板，它自己也说明了这一点：其文本“不可视为具有可执行性”，而使用该模板的活动应制定自己的政策。
• opensource.guide 直接阐明了这一原则：“无法（或不能）执行的行为准则，比没有行为准则更糟。”

这不是法律建议

输出内容包括一份政策、一份人员安排计划和一套操作手册。制裁措施会将人员逐出付费活动，而报告渠道会收集与具名个人有关的敏感个人数据，因此其中部分内容涉及真实的法律风险。

• 合同措辞：约束赞助商工作人员的条款，以及票务条款中关于驱逐且不予退款的权利。这些内容应交由法律顾问审查。请通过 samber/dev-event-organizer-skills@event-sponsor-agreement 转交，该流程负责处理这一条款。
• 事件记录的数据保留、访问和删除规则，应交由负责组织隐私义务的人员处理。
• 任何涉及犯罪、未成年人或迫在眉睫的人身威胁的情况，都应优先联系紧急服务部门和法律顾问，然后再进入此流程。

在面谈前说明这一点。把已发布的政策误当成法律保护的组织者，处境比没有政策的组织者更糟。

面谈

每次只问一个问题，尽可能采用选择题。之所以设置问题 5-7，是因为下方的选项在生效时间、持久性和投入成本方面差异很大，不能替用户决定默认排序。

1. 活动是什么形式（聚会、黑客松、单日或多日会议）？预计人数、日期，以及有多少个实体地点或场地？
2. 除持票人之外，还有哪些人受该准则约束：演讲者、志愿者、赞助商和展位工作人员、承包商、媒体、卫星活动或参会者自发组织的周边活动，以及在活动前后持续开放的在线聊天群？
3. 此活动由一个组织实体负责，还是依托一个会约束第三方组织者的伞形品牌或特许经营协议开展？（与规模相比，这一因素对后续设计的影响更大——请参阅本次面谈后的分支说明。）
4. 谁可能成为报告对象，同时又属于组织团队、掌管预算或是活动的主打人物？请如实回答；整个设计都取决于这一点。
5. 政策必须在什么日期前发布？该日期是由门票开售、赞助商合同还是团队自己的目标决定的？（硬性日期会优先采用能快速落实的层级，并压缩起草准备时间。）
6. 这是一次性活动，还是团队打算每年持续举办的活动？（长期持续举办的安排会优先考虑更持久的层级——例如经过演练的常设团队和记录管理机制，而非只写一次的政策页面。）
7. 投入上限是多少：组织者可投入多少小时、活动期间是否有人能实时值守渠道、用于外部协助的预算，以及团队愿意在每届活动之间持续维护多少工作？
8. 当前已有哪些默认排序未纳入考虑的现有资源：拥有自己事件处理团队的母基金会或伞形组织、上一届的政策和记录、内部律师、书面的文化认同或价值观文件、已经受过培训的志愿者队伍？

单一主办方活动 vs. 多主办方特许活动

无论谁买了门票，骚扰都是同一种行为，也需要同一份明确列举的清单。真正会改变以下每项机制的，是谁能管理现场人员。

• 单一主办方活动（PyCon US 模式）。同一个实体负责场地、志愿者、议程和制裁：这里的一切都由你决定并执行。限制在于承载能力——团队规模小且成员具名，现场处理时间紧迫；如果举报涉及团队成员，你上面也没有可以升级求助的对象。PyCon US 的解决办法是指定三位具名负责人（Incident Responder、PSF Director of Operations、Conference Chair），分别公布联系方式，因此即使举报对象是其中一人，举报仍有其他去处。
• 多主办方特许活动或伞式活动（MLH 成员活动模式）。中央机构拥有政策；当地组织者因成员协议的约束而采用该政策：“你应采用、公开提供并执行 MLH 行为准则。”当地组织者不能自行临时处理：“组织者必须立即联系现场的 MLHers 或 MLH Incidents Team。”你的政策工作主要_不是起草_，而是核实究竟哪份文件对你具有约束力、了解中央处理手册，并明确由中央机构决定是否对外发布信息，且当地的措辞和发布时间须先由中央统一商定。

还有第三种模式介于两者之间：由独立本地社区组成的自愿互助网络，共享一份简短宣言，没有品牌所有者，也没有约束执行的成员协议（samber/dev-event-organizer-skills@event-team-structure 设计了这一网络层）。对于行为准则，应将每个分会视为单一主办方活动：由其负责自己的政策、响应团队和制裁措施。网络可以共享基础文本和处理手册作为资源，也可以将“公开发布行为准则并指定响应团队”列为最低约束要求；但价值观宣言不是政策，除非成员书面同意，否则网络机构无权裁决分会的个案。宣言中的商业定位（“商业是结果，而非目标”，舞台上不得进行商业演示）应放在演讲指南中，而非制裁阶梯中。

只要建议因模式不同而有所区别，就应说明它假定采用哪种模式。大部分政策结构都适用于这三种模式；响应团队的人员配置选项、申诉途径和公开声明的授权方则不适用。

无论采用哪种模式，赞助商和展位工作人员都处于这条界线的一侧。他们属于政策适用范围——MLH、PyCon US 和 confcodeofconduct.com 都在各自的适用范围条款中提到了赞助商——但他们受雇主签署的合同约束，而非所购买的门票。应在政策中明确说明他们也受其约束；具体条款措辞见 samber/dev-event-organizer-skills@event-sponsor-agreement。

工作流

1. 说明免责声明，然后进行访谈。
2. 使用下面的第一个菜单选择基础文本的立场。如果活动受特许经营或伞式协议约束，请跳过起草：找到具有约束力的文件，并确认适用哪个版本。
3. 撰写范围条款：涵盖哪些人员、哪些场所、哪些日期，以及场外发生的事情如何处理。使用 references/policy-anatomy-and-scope.md；范围条款是大多数活动最容易写错的部分，也是决定能否对违反政策的人执行制裁的关键。
4. 使用第二个菜单选择报告渠道。在政策中写明两部分保密承诺：报告内容保密，且报告者的身份也保密，除非他们另有指示。
5. 使用第三个菜单组建响应团队，然后在报告说明中公布成员姓名。人们知道由谁接收报告后，报告意愿会更高。
6. 根据 references/incident-runbook-and-response-team.md 编写事件处理手册：接收报告的脚本、记录字段、升级流程、预先确定的决策方法、四部分通知、结案流程。以小时和天为单位设定响应时限，并予以公布。
7. 使用 references/sanctions-ladder-appeals-and-transparency.md，在首起事件发生前公布制裁阶梯。事后才制定制裁措施，会让事件演变成治理危机。
8. 确定申诉途径，并说明哪些级别可以申诉。 活动通常并不意味着所有制裁都享有统一的申诉权；MLH 仅允许对停权和永久禁令提出申诉。应明确说明这种不对称，而不是含糊其辞。
9. 根据 references/staff-guidance-geek-feminism-ada-initiative.md，向所有工作人员，而不只是响应团队，进行说明：任何工作人员都可以口头警告；对于一次性谈话，在事后简要沟通即可；对于严重情况，应立即制止；每次警告都要告知指定联系人。
10. 在开放入场前进行演练。 带团队走一遍两三个模拟案例。未经演练的团队会在事件发生时才摸索决策规则。
11. 承诺为本届活动发布透明度报告，并说明报告会包含和不会包含哪些内容。

如果你的 harness 具有持久记忆，请存储范围决定、响应团队名单及其利益冲突声明、已公布的响应时限，以及每项制裁的级别和理由。下一届活动将从已有的制裁阶梯和可识别重复违规的记录开始——只有这样，第 2 级才有意义。

排序菜单

以下排序都是默认建议，而非规则；具体排序会随情境和执行者而变。在展示这三个菜单中的任何一个之前，请根据访谈结果重新排序，并说明哪个回答让哪个选项发生了变化：

• 硬性发布日期（Q5）会提高那些能在一个下午内落实的级别的优先顺序。
• 逐年累积的任务（Q6）会提高持久型方案的优先顺序。
• 默认假定不存在的资源（Q8）可能会彻底改变推荐级别——设有独立事件团队的伞式组织会让第三个菜单中的大多数选项变得多余，而现成的价值观文件则会让第一个菜单中资源不足的选项变成文字润色。

如果用户的限制排除了某个选项，请将它从计划中删除，而不是把它放在列表末尾。被排除的选项若仍留在列表中，就会在 T-2 周时再次作为范围问题出现。

基础文本立场

效率（推荐顺序）：改编现有文本 > 原样采用 > 改编并添加文化前言。

• 价值：改编并添加文化前言 > 改编 > 原样采用
• 投入：改编并添加文化前言 > 改编 > 原样采用
• 合规成本：改编并添加文化前言 == 改编 > 原样采用

支配关系检查：3 对，严格支配关系为零——只有按构造得出的结果才干净，而按构造得出的结果永远不算通过。

• 价值和投入的排序相同，因此一种机制会阻挡所有配对：能带来更实用文档的立场，起草成本必然严格更高。
• 合规成本也无法区分任何一对——它只是重述了相同的顺序，其中两个改编选项并列。
• 这项检查没有发现排序错误；该排序的依据是下文的论证。

原样采用几乎不花成本，却仍然较差，因为模板提到了活动中并不存在的角色和联系方式——这会让其中的报告说明无法使用——而 confcodeofconduct.com 也声明其内容不具备可执行性。改编需要一两个小时，却能恰好解决这些问题。合规成本上的 == 是实打实的，并非回避问题：两种改编立场都保留相同的 Creative Commons 署名义务，也都会触发同一次由法律权限负责人进行的审阅；文化前言只会增加文字，不会扩大法律风险范围。

默认选择：改编现有文本。 只要已有明确的身份或价值观文件，就升级为添加文化前言。

原样采用的一种较窄变体：对于由志愿者运营的小型活动，直接链接到同类活动自有的、持续维护的行为准则和价值观页面，而非通用模板——这既能以近乎零的起草成本继承对方文本，也能继承其在当地的公信力和执行记录。只有在同一地区或社群中存在合适的同类活动文件，且其适用范围（线下与线上、管辖区域）确实符合本活动时，这种做法才稳妥；此外，它仍需解决通用模板面临的同一问题：在引用之前，确认链接的政策仍然有效、托管它的组织仍然存在，并将其中提到的联系方式或角色替换为本活动自己的信息。

被搁置：改编并添加文化前言——价值最高、投入也最高，因此每一轮都会在效率考量中落败。

• 这是让 CoC 成为人们会阅读、而非匆匆浏览的文件的立场。!!Con 自己的政策指出：“许多行为准则止步于防止骚扰，而我们的准则是有意塑造 !!Con 活动文化的一部分”，并将其期望部分命名为“如何成为 !!Con”。
• 如果活动已经开展过文化身份建设（参见 samber/dev-event-organizer-skills@event-cultural-identity），就应升级为这一选项；这样只需几天起草，便可转为编辑完善。

已删除，而非降级：从头起草自己的准则。 除非活动拥有内部法律顾问，且有具体理由表明没有任何模板适用，否则应删除这一选项。

• MLH、PyCon US 和 confcodeofconduct.com 发布的禁止行为列表大体相同；它们都源自 JSConf US 2012 和 Ada Initiative 的模板系列，而非各自独立形成。这一传承关系恰恰让这份列表成为参会者和举报者熟悉并期待看到的内容。
• 从头起草要花一周时间才能得出同一份列表，还可能遗漏其中的某些内容。而被遗漏的恰恰是举报者需要看到明确列出的内容，才能相信自己的情况符合受理范围。

举报渠道

效率：公开的电子邮件别名 > 现场可识别的响应人员 > 指定的利益冲突替代联系人 > 匿名受理渠道 > 有工作人员接听的电话或短信热线。

• 价值：现场可识别的响应人员 > 匿名渠道 > 指定的替代联系人 > 公开的电子邮件别名 > 有工作人员接听的热线
• 所需精力：有工作人员接听的热线 > 现场可识别的响应人员 > 匿名渠道 > 指定的替代联系人 > 公开的电子邮件别名
• 合规成本：匿名渠道 > 有工作人员接听的热线 > 公开的电子邮件别名 > 现场可识别的响应人员 == 指定的替代联系人

电子邮件别名在效率上领先，因为设置只需几分钟、活动前后都能使用，而且印刷版政策必须列出这个地址。现场响应人员在价值上领先，因为陷入困境的人会求助于看得见的人：PyCon US 让受过培训的响应人员穿着“颜色鲜艳的衬衫”，这是线上渠道无法做到的。合规成本中的 == 成立，是因为现场响应人员和指定的替代联系人都会触发同一项审核——公开个人姓名和联系方式。这需要与相关人员沟通并征得同意，而不是建立一套数据处理机制。

在这里，合规成本确实是一个重要维度，这与大多数选项菜单不同。每个渠道都有不同的风险：

• 匿名渠道：在这一维度上成本最高，因为无法确认举报人身份的举报，也就无法根据请求更正或删除；基于这类举报作出的处罚，也无法针对举报人进行核实。必须在收到第一份举报之前就制定留存、访问和决策规则，因为错误的结果事后无法撤销。
• 有工作人员接听的热线：通话记录以及可能包含敏感个人数据的录音，会落入第三方电信公司的手中。
• 公开的电子邮件别名：会产生一个包含相同数据的收件箱，必须有人负责管理、限制访问，并按照书面规则留存。

默认方案：公开的电子邮件别名 + 指定的利益冲突替代联系人 + 现场可识别的响应人员，适用于任何设有线下活动日的活动。对于仅在线上进行或仅在活动前开展的范围，则仅采用电子邮件别名加替代联系人的方案。

容易被忽视：匿名受理渠道——对于其他渠道收不到的举报，这一渠道恰好价值最高；但它也需要较多精力，因为必须制定一种在无法联系举报人时仍能执行的决策惯例。只要举报群体内部存在权力差异，就应采用这一渠道：例如受薪员工、听命于赞助商的赞助商展位工作人员、参加大学主办黑客马拉松的学生，或包含活动最高级别组织者的响应团队。PyCon US 没有公开的匿名_渠道_，但受理时接受匿名举报；CNCF 则运行一套有记录的转交流程，任何委员会成员都可以在不透露举报人姓名的情况下转交举报（这是项目惯例，而非某场活动的做法）。

响应团队配置

效率：明确公布的 3–6 人团队 > 转交给上级机构的事件处理团队 > 外部信任与安全承包商。

• 价值：明确公布的团队 > 上级机构的团队 > 外部承包商
• 工作量：外部承包商 > 明确公布的团队 > 上级机构的团队
• 合规成本：外部承包商 > 上级机构的团队 > 明确公布的团队

将团队规模定为 3–6 人是经过考虑的：即使三分之一成员无法参与，团队仍必须能够运作；对于为期三天的活动来说，这种情况必然会发生。应提前确定决策方法，包括意见相同和缺席时的规则，并让决策倾向于采取行动——实际观察到的主要问题是对有效报告不作为、拖延，而非行动过于仓促。

如果存在上级机构转交渠道，它几乎不费力；但其他地方都无法使用，因此应将其视为有条件的选项，而不是任何人都能选择的一个等级。它的合规成本在于，隶属协议会让你受他人的流程约束，并剥夺你推翻处理结果的自主权。

默认方案：明确公布的 3–6 人团队，报告说明中列出每位成员的姓名，并规定成员意识到需要回避时立即启动回避规则。

资源不足时：外部信任与安全承包商——在其他方案都无效的唯一情况下，它价值最高；但所需工作量也最大（采购、简报、预付服务费，以及向外部方提供参会者个人数据）。如果活动中最有权势的人就在组织团队内，且其上方没有独立机构，则应优先考虑此方案。如果行为准则无法约束社区中最有权势的人，就根本不应采用；在没有董事会可供上报的情况下，承包商是唯一能满足这一前提的选项。

应删除，而非降级：由一名指定组织者独自负责响应。 对于该组织者同时也是团队中职级最高者的活动，应删除这一选项，因为这样一来，渠道就无法接收最可能需要该渠道处理的那份报告；而凌晨 2 点由一人独自决策，也算不上流程。若把这一选项留在列表末尾，它就会在活动开始前两周以“随便找个人处理一下”的形式再次出现。

失效模式

• 发布了政策，却没有处理流程。 这是最典型的失效，模板的维护者也明确指出了这一点。解决办法：在指定团队、有效沟通渠道和处理阶梯就位之前，不要发布政策。
• 找不到响应人员。 在走廊里陷入困境的人，看到 PDF 中的电子邮件别名也无济于事。解决办法：让受过培训的响应人员穿着醒目的服装，并在开场公告中说明这一点。
• 没有针对响应团队的举报渠道。 解决办法：至少公布另外两位人员的个人联系方式，其中至少一人不在组织团队的管理链条内。
• 统一设置团队并未打算提供的申诉权。 解决办法：说明哪些处理层级可以申诉、向谁申诉、以何种形式申诉，以及截止时间。MLH 仅允许对暂停资格和封禁提出申诉，须通过书面电子邮件提交并附上证据。
• 将赞助商和展位工作人员视为政策范围之外。 解决办法：在适用范围条款中明确列出他们，并确认赞助合同包含合规条款和无退款驱逐权。
• 完全私下处理案件。 如果案件处理完毕，却没有任何人收到通知，人们会认为没有采取任何措施——有记录的失效案例中，受影响者因此认定什么都没发生而离开。解决办法：所有知晓违规行为的人都要知道已采取了应对措施；通知内容保密，但执行措施这一事实不保密。
• 将同伴网络的宣言误读为共同政策。 各分会以为网络会处理举报；网络则以为各分会会处理。解决办法：每个分会都发布自己的政策并组建响应团队；网络则明确写明，除非成员另有约定，否则网络不裁定任何案件。
• 地方组织者擅自发表公开声明。 解决办法：提前指定谁有权发表公开声明，并在任何人发言前集中商定措辞和时间。
• 采用团队无法执行的处理阶梯。 如果团队无权实施某个已公布的处理层级，那还不如采用更短但诚实的处理阶梯。解决办法：将处理阶梯精简到团队在领导层支持下实际能够做到的范围。

衡量

衡量处理流程，而不是政策——在收到举报之前，政策没有可观察的输出。

• 每届活动每 100 名参与者收到的举报数。 改进举报渠道后数量上升，说明信任有所提升，而非情况恶化。将此指标的目标视为自行设定的目标，绝不要刻意压低它。

• 从收到举报到确认收到，以及从收到举报到告知处理结果所用的时间。 根据公布的时限进行衡量。可选择以下两个时间标准：

  • PyCon US：对于非紧急举报，三位负责人须在 24 小时内开会，并在一周内跟进举报人。
  • Aurora 和 Gardiner 的手册（为在线社区编写）：24 小时内确认收到，10 个工作日内作出决定。

  活动的处理时限必须涵盖在活动期间内，因此它比项目的时限更紧。

• 收到结案通知的举报人占比。 目标是 100%；低于此值就意味着举报石沉大海。

• 开门前完成演练。 每届活动单独统计，结果为是或否。

• 发布透明度报告。 每届活动单独统计，结果为是或否。

通过标准，并持续迭代直至达标：每份举报都在公布的时限内得到确认，每位举报人都在公布的跟进截止时间前获知处理结果。该标准由组织自行设定；上述两种已公布的时限标准让它切实可行，而非凭空捏造。

调用示例

• “我们将在四个月后举办首届 300 人大会，需要一份行为准则。” → 开展访谈、调整现有文本，并在发布前组建一支由三名具名成员组成的团队。
• “一小时前有人向我们举报了一位演讲者，我们不知道该怎么办。” → 跳转到 references/incident-runbook-and-response-team.md 中的事件处理手册受理和升级步骤；先评估安全，再决定处理方式。
• “我们的 CoC 已经发布两年了，但从未收到过举报——这是好事吗？” → 根据第二份清单审核各个渠道；沉寂的渠道更可能是无人能触达，而不是活动毫无问题。
• “某赞助商展位的工作人员对参会者很无礼。我们能把他们赶出去吗？” → 先确认条款的适用范围，再查看处罚阶梯；合同中的驱逐权见 samber/dev-event-organizer-skills@event-sponsor-agreement。

预期产出：

• 一份政策文档。
• 一张单页举报卡，用于印刷版议程和网站。
• 一份响应团队名单，包含联系方式和回避声明。
• 一份团队可在凌晨 2 点遵循的事件处理手册。
• 一套已发布的处罚阶梯。

参考资料

• references/staff-guidance-geek-feminism-ada-initiative.md：Geek Feminism 和 Ada Initiative 示例政策中面向工作人员的部分，涵盖警告、中止演讲、受理举报和驱逐的依据。
• samber/dev-event-organizer-skills@event-volunteers：负责招募人员并安排班次，让他们担任本技能所规定的响应人员。
• samber/developer-relations-skills@developer-community-moderation：负责管理长期存在、跨活动的社群及其日常审核；本技能自己的政策和响应团队仅适用于单场有明确日期的活动，若举报、行为模式或相关人员的影响超出活动范围，则交由该技能处理。
• samber/dev-event-organizer-skills@event-attendee-experience：提供本事件处理手册用作受理空间的安静室。
• samber/dev-event-organizer-skills@event-accessibility-inclusion：负责设计活动，尽量从源头减少针对本政策保护群体的违规行为，并提供互动同意贴纸；references/policy-anatomy-and-scope.md 会落实这些贴纸所设定的摄影界限。在大型会议中，该技能还会配备一支易于识别的包容性团队，人员和队服可与响应团队共用，但受理工作绝不共用。不要用此技能制定行为准则；请改用描述中提到的技能。
• samber/dev-event-organizer-skills@event-comms-channels：负责参会者使用的聊天空间和活动应用，而本政策必须涵盖这些渠道；它创建的每个渠道都必须在适用范围条款中列明，且其名单决定哪些人受约束、由谁负责审核。
• samber/dev-event-organizer-skills@event-cultural-identity：负责体现活动现场价值观的内容，供政策序言采用；该技能定义文化，本技能撰写政策并负责执行。