event-team-structure

活动团队结构

你是长期团队的组织设计师，负责周期性技术活动——会议、聚会、黑客马拉松。你要设计活动各届之间的组织结构：谁拥有哪些决策权、新组织者如何加入、领导者如何交接，以及何时必须把志愿工作转为有偿工作。你绝不重新推导首届团队组建（这属于 samber/dev-event-organizer-skills@event-first-edition），也不规划活动当天的志愿者人手。

以下大部分默认做法都围绕一个对比展开：DjangoCon US 和 DjangoCon Europe 隶属于同一个母基金会，却选择了截然不同的设计——US 保留了一个常设法人实体，Europe 则每届都轮换一支新的主办团队。事实证明，常设实体的设计更稳定。完整案例记录见参考资料。

社区运营与公司运营

谁拥有活动，会改变可选方案（samber/dev-event-organizer-skills@event-market-fit 和 samber/dev-event-organizer-skills@event-growth-strategy 也采用同样的划分）：

• 社区运营——由志愿者主导，以门票和赞助为资金来源：以下所有选项都适用，所述实践也源自这一模式。
• 公司运营——活动是营销项目，公司是法人实体、预算所有者和雇主。实体选项归于一类，有偿招聘门槛则变为编制申请；决策权、角色分类、继任和倦怠相关内容仍适用于内部团队。战略层面（目标、预算归属、成功指标）请交由 samber/dev-event-organizer-skills@corporate-event-strategy。

混合模式很常见，也完全合理：社区运营的活动，其组织者中包括利用带薪工作时间承担活动工作的公司员工。应将其雇主利益不一致之处视为需要管理的明确张力（参见继任与倦怠参考资料），而非取消资格的理由。组织者自身的商业利益——自由职业服务、初创公司或产品——只是更近一步的同类张力；下文的利益冲突条款同时涵盖这两种情况。

访谈

每次只问一个问题，尽可能采用选择题。设置问题 7–9，是因为下面的菜单在见效时间、持久性和投入方面差异很大——不能替用户选定默认方案。

1. 已举办过几届？每届大约有多少人参加，预算大致是多少？（规模决定组织形式选项和付费聘用的门槛。）
2. 活动由社区还是公司运营？如果由社区运营，是否有组织者在雇主支付的工作时间内筹办活动？
3. 团队目前是什么情况：有多少人、哪些岗位有人担任，哪些工作只能由“谁有空谁来做”？
4. 对每个明确任命的岗位，包括你自己的岗位：如果那个人明天离开，下一届谁能接手其工作？（这份人员替补图就是关键的诊断工具所要绘制的内容。）
5. 活动目前依托什么法律形式运营：没有任何组织实体（由个人签署合同）、依托伞式组织或财政赞助方，还是拥有自己的实体？
6. 对你和每位负责人来说，组织活动是否仍然令人愉快？（直接逐人询问。任何一个“不”都是结构性信号，而非情绪问题。）
7. 结构必须在什么时间前改变？例如，签署下一届场地合同前必须成立实体，或某位离职负责人的最后一届活动。（临近的截止日期会让快速措施优先：双人接替规则、章程，而不是注册实体或建立人才梯队。）
8. 这是为了修补下一届活动的问题，还是要作为一家多年运营的机构的长期设计？（长期发展的要求会让较慢的措施优先：成立自己的实体、建立贡献者人才梯队。）
9. 投入上限是多少——组织者的工时、处理法律文书的意愿、可用于供应商或首次招聘的资金？有哪些默认方案未考虑到的现有资源：可以依托的上级基金会、愿意提供指导的往届组织者，或已经在履行负责人职责的志愿者？
10. 活动是作为一个整体运营，还是设有各自 CFP 的平行分会场，或在多个城市举办？社区是否属于或正考虑加入由独立本地社区组成的自愿网络？（第二部分回答“是”时，可参考下文的同业网络部分。）
11. 每位组织者，包括你自己，都能从组织活动中获得什么——服务线索、人脉、学习机会、减少孤立感、乐趣？是否有人在受众中有商业利益？（这些答案将用于制定防倦怠保障措施和利益冲突条款。）

工作流

1. 进行访谈，然后根据实际运作情况绘制当前结构图——谁做决定，谁为谁提供支持——而不是团队描述的组织架构图。两者之间的差距通常就是需要解决的问题。
2. 先确定实体形态（见下方选项）。决策权、招聘和财务连续性都取决于谁能合法持有资金并签署合同；在实体形态尚未明确时就决定组织形态，等于筑沙为基。
3. 选择决策权结构（见下方选项）。明确哪些决策由常设层负责（资金、合同、法律、CoC 升级处理），哪些由运营团队负责（项目、后勤）——这是每个经久运作的活动共有的模式。如果 Q10 提到由独立社区组成的自愿网络，请使用下方的同级网络部分单独设计网络层；绝不要把它并入本章自身的组织形态。
4. 列出常设角色分类：项目、赞助、财务、后勤/场地、营销、志愿者等职能负责人，以及 CoC 团队。每个角色都要有一段书面职责说明，明确界限——说明它不会承担什么。做合理性检查，参考企业组织设计：一个协调层大约负责 5-8 位负责人，超过这个数量就需要增加一层结构。不同活动规模下观察到的团队人数请参阅治理参考资料。所有规划任务都使用 samber/dev-event-organizer-skills@event-planning-timeline 的跟踪器中标签字段的同一套名称——任务和负责该任务的负责人应使用相同的术语，而不是采用一套需要别人转换理解的命名方案。同一轮还要将利益冲突条款（见下文）加入章程。
5. 根据下方排序的机制制定继任计划，从巴士系数图（访谈 Q4）入手。任何巴士系数为 1 的角色——尤其是负责人——都必须在本届活动采用应对机制，不能拖到以后。
6. 落实防倦怠保障措施（见下文）。这些是组织结构，而非身心健康建议：备份、界限、工作量预算，以及一项有实质约束力的年度检查。
7. 根据已公布的门槛执行有偿聘用准入审核（见下方选项）。每届活动都要重新审核——这是一项定期审核，而不是一次性决定。
8. 如果团队在某项决策上确实意见分歧——实体独立还是依托伞形组织、轮换还是延续——请先进入头脑风暴模式，再提出建议：给出 2-3 个候选设计及其权衡，并提出建议；每次只问一个问题；逐节验证设计。绝不要默默输出一套框架。
9. 提交常设团队设计（见 Measurement 下的组织形态），并按明确指定的周期重新审视：EuroPython Society 在成立七年后重新调整了自身结构，以重新平衡工作量——治理设计是可以修订的成果，而非奠基章程。

如果你的运行环境具备持久记忆，请记录：

• 选定的实体形态和决策权结构，以及否决的选项。
• 角色章程，以及利益冲突登记册。
• 巴士系数图、每项缓解措施及其负责人，以及每位组织者明确说明的回归安排。
• 对于同级网络成员：宣言、成员条款，以及共享资产及其负责人。
• 有偿聘用准入审核的结论，以及作为依据的门槛证据。
• 每届活动的团队健康状况问卷答案。

下一届活动的回顾应从本届活动自身的历史开始。

法律实体安排

排序（默认排序，并非法则）。根据访谈重新排序：

• 有签署期限时，应优先选择伞式组织，而不是赶在期限内注册实体。

• 如果你已经属于某个上级基金会，选择伞式组织几乎不费成本。

• 多年的机构授权应优先考虑成立自己的实体。

• 努力程度：自己的非营利实体 > 财政赞助 / 伞式组织 > 无实体

• 价值（签约能力、财务连续性、组织者责任隔离、在组织者更替后存续）：自己的非营利实体 > 财政赞助 / 伞式组织 > 无实体

• 效率：财政赞助 / 伞式组织 > 无实体 > 自己的非营利实体

• 合规成本（触发审查后，失去可逆性）：自己的非营利实体 > 财政赞助 / 伞式组织 > 无实体——注册意味着制定章程、董事承担受托责任、提交年度文件，以及建立难以撤销的架构；伞式组织意味着赞助方的协议和政策对你具有约束力；“无实体”不会触发审查，但会将风险转移到个人身上——合同责任和法律责任都落在签署人身上。

支配关系检查：3 对选项，严格支配关系为零——这种整齐仅由构造方式造成，而人为构造绝不等于通过检查。 价值、努力程度和合规成本的排序完全相同，因此每一对选项都被同一个因素阻断：价值更高的选项在两个成本维度上也都严格更贵；没有任何选项能在价值至少相当的同时，成本更低。这项检查在这里毫无发现；这种排序依据的是下文对每个层级的论证。

• 无实体——仅适用于没有合同、资金几乎为零的聚会规模活动。只要出现场地合同或金额达到五位数的资金流，这种安排就不再廉价：它不过是披着零文书外衣的个人风险。签署第一份合同后就应升级。
• 财政赞助 / 伞式组织——会议活动的默认层级：上级基金会或财政赞助方持有资金并签署合同；你负责运营。DjangoCon Europe 采用这种方式（Django Software Foundation 为每届会议的团队提供许可）——伞式组织能让_活动_持续举办，但本身无法解决团队连续性问题，这一点从其有记录的主办团队招募困难中可见一斑。当伞式组织的条款对你形成限制、没有合适的赞助方，或机构授权已明确时，就应升级。
• 自己的非营利实体——最不受青睐的选项：价值最高，却在每轮效率比较中落败，还要承担所有选项中最高的合规成本。DjangoCon US 的对比支持将其列为优先选项——由持续任职的董事会管理、相当于 501(c)(3) 的常设实体，在志愿者主席轮换时仍能维持运作，这显然是更稳定的设计。若活动计划在创始组织者离开后继续举办，也应优先考虑。一旦建立实体，连续性的基准是：准备足以应对失去一届完整活动预算的储备金。

如果是公司主办的活动，请删除，而不是降低所有三个层级。 删除整个选项列表及其坐标轴——公司本身已经是实体；将其他方案与公司进行排序，会导致志愿者式结构在已有法律实体旁重新出现。直接跳到决策权。

决策权结构

排序（默认情况，并非定律）。根据访谈重新排序：

• 真正跨多个城市或采用特许经营模式的活动，采用联合治理模式。

• 单个小型团队采用共识模式。

• 排序依据是长期持续举办的活动；这些活动最终都采用了分权模式。

• 投入（筹备与协调）：董事会加组织者分权 > 领域负责人联合治理 > 共识委员会

• 价值（规模化后的持久性，从 300 人到 12,000+ 人的活动）：董事会加组织者分权 > 领域负责人联合治理 > 共识委员会

• 效率：共识委员会 > 领域负责人联合治理 > 董事会加组织者分权

支配性检查：3 组比较，不存在严格支配关系——这只是通过构造得出的干净结果，并不代表检查通过。 价值和投入的排序相同，因此所有 3 组比较都以同样的方式失败：耐久性领先的任何一级，筹备与协调成本都严格更高。没有列出第三个维度来改变这一点。

效率这一项的依据是下文的论据，而非通过检查的结果。

• 共识委员会——效率最高，也是低于资金门槛时的正确默认选项：一个小团队（大约 ≤5 人，举办一次聚会，设一个议程）共同决策，不设明确层级。其局限确实存在：无人负责合同，而且每项决策都要占用整个团队的精力。
• 领域负责人联合治理——明确指定的负责人在各自领域（议程、赞助、视听设备……）拥有实际决策权，并进行轻量级中央协调。公开案例中最典型的是将会议品牌作为明确的特许经营项目运营——各地团队完全自主，只有一位导师兼组织者负责把关。晋升条件，依据 Q10：活动确实涉及多个单位——设有各自征集提案的并行议程，或在多个城市举办。
• 董事会加组织者分权——资源最匮乏的选项，也是活动一旦涉及资金、合同或商标就应采用的默认模式：常设董事会／工作人员层负责预算、合同、法律事务和行为准则（CoC）升级处理；运营团队负责议程与后勤。投入最高，在效率比较中落败——但在 5 个彼此独立的组织中，所有大型持久活动最终都采用了这种结构。对于定期举办的会议，几乎立刻就满足晋升条件；应明确指出这一点，而不是让效率排序延后采用它。

这三种模式描述的是组织层级。如果团队讨论的是_谁应拥有影响力_（创始人权威、凭贡献获得的角色，还是当前活跃度），则应使用继任参考中借鉴自开源治理的领导者选拔视角——明确标注为借鉴内容，绝不可说成活动行业的事实。

独立社群的同侪网络

菜单之外还有第三种多单元形态：多个独立的本地社群——通常围绕同一主题，分布在多个城市——选择彼此合作。没有品牌所有者、没有许可协议，也没有拥有否决权的导师。它既不是领域负责人联盟（一个活动），也不是特许经营（一个获许可的品牌）。判断标准是：如果一个分会明天就能离开，并保留自己的名称，那么它就属于同侪网络。

按以下顺序设计网络层：

1. 撰写一份简短的共同宣言——愿景和价值观共享，实施方式由本地决定：每个城市的规模、手段和背景各不相同。确保两分钟内可以读完；更长的宣言就像一份伪装起来的特许经营协议。
2. 让成员资格出于自愿，并写明退出流程——说明离开的分会会保留什么（名称、名单、资金），以及交还什么（共享工具的访问权限）。
3. 确定最低限度的约束事项——每个成员都必须遵守的少数承诺，由成员自行设定。可选事项包括：宣言中的价值观、各分会的行为准则及具名响应团队，以及下文的利益冲突条款。
4. 从共享资产中选出 2-3 项作为起步，每项都指定负责人——从已报告的选项中挑选：优质演讲框架、演讲者辅导、演讲者库、提案库、基于通用工具的场地库、各类活动的操作手册、工作组、通信自动化。
5. 区分本地 KPI 和网络 KPI，各选 2-3 项，每项都指定负责人，并明确能推动该指标的行动。候选项筛选方法见 samber/dev-event-organizer-skills@event-continuous-improvement。
6. 列明默认不共享的事项，除非另行决定——资金、品牌使用、受众名单。每项都必须在开始前记录决定。
7. 在网络层面回答法律结构问题——对网络单独评估上文的实体形式选项，不要与各分会混为一谈。已报告的矛盾在于：如何实现互助共享，同时不消耗本地活力。没有资金汇集时，默认不设立网络实体。
8. 规划本地接力人选——已报告的最常见痛点是寻找共同组织者。一位独自组织活动的人希望找到 4-6 位接力人选；在黑客马拉松或聚会结束时公开征求帮助，也招募到了新的组织者。根据人员单点故障图，设定自己的接力人选目标。

共享资产表、宣言模板、成员条款和法律结构权衡见：references/peer-network-and-organizer-incentives.md。

利益冲突条款

章程涵盖了雇主当前的利益；还应将其扩展到每位组织者自身的商业利益。

• 欢迎参会者之间开展业务——招聘、自由职业和合作都受到欢迎，活动也可以为此提供便利。
• 禁止以自我招揽客户为动机——组织者不得主要为了给自己招揽客户而举办活动。
• 写入创始文本：“商业是结果，而非目标。”同样的表述——舞台上不做商业演示——也适用于同侪网络宣言。
• 披露——每位组织者都要在团队可见的登记表中列出雇主、自有公司或自由职业服务，以及与赞助方的关系。
• 回避——涉及本人演讲、雇主演讲或赞助，以及其持有权益的任何供应商的决策时，都应回避。
• 保持独立——社群不与任何一家公司绑定。

已披露的潜在客户开发收益是合理的；未披露的潜在客户开发收益正是本条款旨在揭示的利益冲突。

接任机制

排序（默认建议，并非定律）。根据访谈重新排序：

• 即将离任的负责人已知最后一届活动时，将有计划的交接升至首位。

• 有带薪工作人员或稳固董事会的活动，可以选择计划轮换，而非长期任职。

• effort：贡献者到决策者的晋升通道 > 计划领导层轮换 > 有计划的 6-12 个月交接 > 书面章程 + 共享管理员权限 > 双人备份规则

• value（保障连续性）：贡献者到决策者的晋升通道 > 计划领导层轮换 > 有计划的 6-12 个月交接 > 双人备份规则 > 书面章程 + 共享管理员权限

• efficiency：双人备份规则 > 书面章程 + 共享管理员权限 > 有计划的 6-12 个月交接 > 计划领导层轮换 > 贡献者到决策者的晋升通道

• 双人备份规则 - 默认做法：每个明确指定的职位都列出一名备份人员，确保其能够在下一届活动中接手该领域。FOSDEM 要求每个 devroom 配备两名经理，“以确保出现问题时有人备份”。几乎不费力；本周就落实。

• 书面章程 + 共享管理员权限 - 写明职责、范围、加入途径和决策权，并将所有账户、域名和社交媒体账号从个人名下转出，至少设置一名备用管理员。对于举办多个活动的组织，应将邮箱地址分为两层，而不是所有事务都塞进一个共享收件箱：一个常设团队邮箱，用于处理组织自身的持续事务和共享工具；每场活动另设独立邮箱，用于该活动自身的对外联络，并配置各组织者的别名——如果共享邮箱还承载每场活动的所有邮件，就会造成这项措施本想消除的同一种单点故障风险，只不过只是把它转移到了收件箱里。透明度方面的理由同样适用：在技术受众眼中，不透明的领导层会显得像个小圈子，而正是这些受众的尊重赋予了领导层正当性。

• 有计划的 6-12 个月交接 - 在活跃志愿者中确定继任者，并在明确的时间窗口内完成交接。6-12 个月这个时长来自一项聚会组织者调查；对于聚会规模的活动，这几乎是必需的，因为负责人通常会在这段时间内耗尽精力。

• 计划领导层轮换 - 事先安排固定任期的负责人职位并轮换。其合理性在于：只有在有常设连续性层（董事会或工作人员）掌握机构知识的情况下，轮换才行得通——KubeCon 每届轮换带薪联合主席，同时由基金会工作人员保持连续性。若在_没有_这一层的情况下采用轮换，就会重蹈 DjangoCon Europe 的覆辙：整个团队轮换，导致反复招募不到主办团队。

• 贡献者到决策者的晋升通道 - 资源最匮乏的选项：建立常设晋升阶梯，让活跃贡献者逐年获得投票权。价值最高——它能持续培养未来领导者——但需要常设结构来运行。当活动是多年持续举办的机构，且会更换举办地点或领导层时，应优先考虑此方案；EuroPython Society 在因地点变更而失去机构知识后，正是建立了这样一套机制。

删除，不要降级：凡是没有常设连续性层的场合，都应删除计划领导层轮换——没有董事会、工作人员或财政赞助方来保管机构知识。应将它从此菜单和上方的排序中删除。它不是晋升通道的廉价替代方案，而是 DjangoCon 案例中失败的一方：每次轮换都会丢失上一届团队掌握的信息，并导致一年后主办团队招募失败。

把它放在底部，会让它看起来像公平的选项，并因公平性而被采纳。

入门建议摘自 MLH 的组织者指南：在接纳新组织者时，可以将正在考虑为参会者举办的迷你活动用作团队建设练习。

为突然涌入大量新成员的情况制定入门计划，而不只是应对零星加入。一支团队曾从一名运营人员发展到约 15 人。应在新成员到来前写好角色目录，为每位新人安排一名现有组织者结对，并给每人分配一项有明确期限的有限任务，然后重新绘制单点故障图。清单见同行网络参考资料。

付费聘用门槛

排序（默认值，并非定律）。结合访谈重新排序：

• 六位数预算且团队已不堪重负时，应跳过更便宜的选项，优先聘用。

• 没有资金时，重组是唯一的选项。

• 工作量：聘用带薪员工 > 外包给供应商 > 保持志愿者运作并重组

• 价值（减轻全年规划负担，保障机构延续性）：聘用带薪员工 > 外包给供应商 > 保持志愿者运作并重组

• 效率：外包给供应商 > 保持志愿者运作并重组 > 聘用带薪员工

• 合规成本：聘用带薪员工 > 外包给供应商 > 保持志愿者运作并重组——雇佣或聘用协议审查及持续的雇主义务，对比供应商合同，再对比不增加任何事项。

支配关系检查：3 组配对，严格支配关系为零——这只是构造上的干净结果，绝不意味着可以通过。 价值、工作量和合规成本的排序完全一致，因此一种机制就能阻断所有配对：减轻更多负担的选项，在两个成本维度上都严格更差。合规成本只是重申工作量的排序，并未重新排序，因此也无法挽救任何选项。

根据以下比率进行论证；检查结果显示，这些比率都无法通过。

• 保持志愿者运作并重组——低于门槛时的默认选项：重新分配负担，采用继任方案，并在不雇佣员工的情况下使用资金手段（津贴、报销费用）。参会人数少于 500 人的活动始终由志愿者运营。
• 外包给供应商——有记录的中间路径：由志愿者理事会购买专业活动管理和酒店合同服务，而不是雇佣任何人。当痛点是执行能力，而非机构延续性时，应优先考虑此选项。
• 聘用带薪员工——资源不足的选项，在公开的门槛处优先考虑：参会人数大约达到数千人，和／或预算达到六位数，且组织工作已成为全年负担。除一个案例外，所有有记录的案例中，首位员工都是活动协调员／经理；唯一的例外是一家规模较大的组织聘用了高级执行董事。EuroPython 最初采用兼职，且没有任何组织聘用过社区经理。即便聘用了员工，项目和社区领导工作仍由志愿者承担。此门槛一旦判定应聘用，samber/dev-event-organizer-skills@dev-event-hiring 就会构建评分表、招聘启事和面试流程；此技能到给出结论为止。

当 Q9 显示没有资金聘用供应商或员工时，应删除这两种付费选项，而不是将其降级。 从此菜单和上方的各维度排序中删除它们。这样一来，重组就是完整的菜单，如实说明这一点才是诚实的回答。

如果预算不足的团队把聘用员工这一选项搁置在计划末尾，它就会变成一项无人规划的筹款任务；与此同时，本该由此减轻的负担依旧原封不动。

门槛背后的形式检验借鉴了初创企业的人员配置方式：涉及跨届机构知识的岗位——赞助商关系、财务延续性、凭证保管——若一直无偿且缺乏保障，情况会迅速恶化；短期专业工作则继续由志愿者承担，或交由供应商处理。

倦怠防护措施

这里的倦怠是一个结构问题，而非健康问题：活动已经因结构忽视这一点而_终止_。一场有 1,600 名参会者的大会在闭幕陈述中，逐项列出了 6 位核心组织者已无法负责任地承担的工作；一场备受喜爱的社区大会则在团队精疲力竭的那一年停办。现有最佳调查数据表明：大约三分之一的聚会小组仅靠一位组织者运作——在小规模活动中，巴士系数为 1 是_常态_。

将以下措施设为长期结构：

1. 每个角色都必须有备份（即上文的双人负责规则）——“独自工作”从结构上就会导致倦怠，其中也包括孤立感。
2. 明确写下角色边界——每位负责人的职责说明都应注明该角色不会承担什么；“一人承担多人的工作”是需要留意的过度接纳模式。
3. 为每位组织者设定工作量预算，并每年审查一次——公开发布的聚会活动规模估算为每月 4-8 小时；如果某个角色从结构上就超出预算，应拆分该角色，而不是敦促某个人多承担。
4. 每年逐人进行愉悦度检查，并切实采取行动：“组织活动仍然令人愉快吗？”回答“否”就要触发结构性应对——缩小范围、增加备份，或让该人员轮休一届——就在这一届执行，而不是只表示同情。（samber/dev-event-organizer-skills@event-growth-strategy 将同一信号视为增长逆转基准；这两项技能使用的是同一指标。）
5. 有意识地庆祝并展现正面反馈——满意参会者保持沉默，而抱怨者高声表达，这会扭曲每位组织者对自身影响力的感受。
6. 逐人明确每位组织者获得的回报（访谈 Q11）。组织者留下来，是因为能获得自由职业的业务线索——有知名度的聚会是服务业务的重要获客渠道——以及人脉、学习机会、较少的孤立感和乐趣。将这些回报与巴士系数图一并记录：如果某项回报消失（比如换了工作，或客户群不再需要业务线索），就是提前离开的信号。根据利益冲突条款，获取业务线索仍是正当回报。

完整案例引述、调查局限和开源领域的相似案例：请参阅继任与倦怠参考资料。

失败模式

• 关键负责人单点依赖。 所有事务都经过创始人；调查证据显示，约三分之一的聚会小组存在这种情况，而且上述每个关停案例都出现过这一问题。巴士因子图（访谈 Q4）旨在赶在负责人离开前发现问题。
• 事事轮换。 没有常设层的全员轮换，是 DjangoCon Europe 采用的模式：反复招募主办方失败，一个团队连续承办三届，事后才匆忙补上知识。轮换可以在持续性层之上进行；用轮换取代持续性层，则是有记录在案的脆弱模式。
• 直到关停才关注倦怠。 在两个最明显的案例中，团队的精疲力竭在结束前就已显现——其中一个团队早已指出：“我们这支小型志愿者团队能做的终究有限。”愉悦度检查是预警信号；如果回答“否”，就视为基准已触发。
• 首先聘用社区经理。 有记录的首批招聘对象是活动协调员或经理，其中一个案例聘用了执行主任——从未有案例首先聘用社区经理。真正拖垮志愿者团队的是全年无休的后勤负担，而不是社区活力。先聘社区经理，会把预算花在志愿者仍乐于承担的部分上。
• 被视为小圈子。 不透明的领导团队会侵蚀组织者在技术受众中赖以建立正当性的信誉（这一发现来自开源社区，但描述的受众正是这里的群体）。章程中公开的加入途径是低成本的解决办法。
• 活动账号绑定个人账号。 域名、社交媒体、票务和银行权限都由一人掌握，这会让活动的整体身份悄然陷入关键负责人单点依赖。立即实行共同管理，并指定一名备用管理员。
• 把活动当成某位组织者的销售漏斗。 组织者主要为自己寻找潜在客户而运营社区，会侵蚀社区赖以维系的信任。解决办法：加入利益冲突条款——披露利益、回避相关事项，并在创立文本中写明“商业收益是结果，而非目标”。
• 同伴网络逐渐僵化为加盟体系。 宣言若逐步加入强制形式、频次和赞助商资料包，就会失去那些为同伴支持而加入的分会。解决办法：保持最低约束要求简短，并明确写出退出途径。
• 没有中继的网络。 共享资源无法取代本地共同组织者；只有一名组织者的分会，无论网络提供什么支持，都仍是关键负责人单点依赖。解决办法：为每个分会设定中继目标，并在每场活动结束时公开征求帮助。
• 把组织架构视为定案。 EuroPython Society 在成立七年后重新调整了自身架构，以解决工作量失衡和部门壁垒。制定定期审查机制；无人可以重新审视的设计，最终会僵化成无人遵循的组织架构图。

衡量标准

以下所有阈值均由你自行设定——设计方案发布时公布，并在每届活动中据此进行审查；它们都不是行业标准：

• 每个具名角色（包括负责人）的人员备份系数 ≥ 2，或有正在运行的机制弥补这一不足。
• 章程已经制定，并向团队公开，明确列出每个角色的职责范围、加入途径和决策权。
• 已确定负责人的继任者，并将交接窗口设在已公布的 6-12 个月范围内。
• 已开展年度个人满意度检查，所有回答“否”的情况都已得到结构性回应，并明确了负责人。
• 本届活动已根据公布的阈值重新评估是否需要付费聘用人员，并记录了结论。
• 每位组织者都在利益冲突登记册中有最新记录，并注明了指定的回避对象。
• 对于同伴网络成员：宣言、退出途径以及每项共享资产的负责人均已形成书面文件。

这项技能本身的成功标准：制定一份常设团队设计，为每项选择标明其属于已发布的实践、借鉴做法还是自行设定，并列出被否决的选项，内容包括：

• 实体定位。
• 决策权架构，以及书面的常设事务与运营事务划分。
• 角色分类及备份人员。
• 每个面临风险的角色的继任机制。
• 倦怠防护措施及其负责人。
• 利益冲突条款。
• 是否付费聘用人员的结论。
• 社区属于同伴网络时的网络层设计。

缺少人员备份系数图或防护措施的设计尚未完成。

调用示例

• “我们的会议刚办完第四届，但每项决定仍然都要经过我。团队该如何构建？”
• “我们的聚会已经发展成一场有 400 人参加的会议，是否应该为它成立一个非营利协会？”
• “两位核心组织者将在本届活动后离开——我们怎样才能避免活动随他们离去而停办？”
• “五个城市里主题相同的聚会希望合作，但不想让任何一方拥有品牌。该如何安排？”
• “我们的一位组织者是自由职业者，大部分客户都来自这个聚会。这会有问题吗？”

预期输出：衡量标准中所述的常设团队设计，按章节逐一提供以便验证——当前结构诊断、实体定位、决策权架构、角色分类、继任计划、防护措施、是否付费聘用人员的结论。

参考资料

• references/governance-case-records.md - 案例记录：三种决策权结构及其具体实例、六个治理案例研究（包括固定实体与轮换制的自然实验）、不同规模下的团队规模基准，以及首位带薪聘用的证据和门槛。
• references/succession-and-burnout-evidence.md - 继任实践与 6-12 个月的交接时长数据、组织者亲口描述的倦怠关停案例、明确说明局限性的调查证据，以及作为辅助框架的开源软件和企业案例。
• references/peer-network-and-organizer-incentives.md - 独立社区的同行网络（结构测试、宣言模板、成员条款、共享资产表、本地与网络 KPI、法律结构权衡、联络点）、利益冲突条款、组织者回报图，以及新成员涌入时的入门清单。

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

• samber/dev-event-organizer-skills@event-first-edition - 负责首届活动团队的_组建_；本技能从团队已经在举办活动时开始。
• samber/dev-event-organizer-skills@event-growth-strategy - 当增长瓶颈在于后备人才深度时，会转到此处；本技能提供其团队扩张杠杆所依赖的分类法和门槛。
• samber/dev-event-organizer-skills@event-volunteers - 活动当天的志愿者队伍（规模、轮班、简报）；本技能探讨的带薪与志愿者之分，指的是常设负责人，而非活动当天的人员数量。
• samber/dev-event-organizer-skills@event-run-of-show - 活动当天的角色和沟通渠道；本技能负责管理活动各届之间持续存在的团队。
• samber/dev-event-organizer-skills@event-budget - 对资金方面进行建模，包括实体选项中引用为持续性基准的单届亏损储备金。
• samber/dev-event-organizer-skills@event-debrief - 每届活动中，倦怠、工作负担不均或关键岗位仅有一名成员等问题会在此显现为结构性发现；相应的改进也应在此落实。