mcpField
E
event-community-building

event-community-building

github.com/samber营销与增长45.5k 次安装2 天前更新
代码仓库

关于 event-community-building

event-community-building 是面向周期性技术活动主办方的技能,用于维护两届活动之间的受众联系。它帮助团队制定淡季节奏、促成参与者回归,并交接社区资产。

主要功能

  1. 01制定淡季运营节奏并指定负责人
  2. 02设计参与者回归机制
  3. 03规划社区资产交接
  4. 04按既定活动调性发布内容
  5. 05维护成员名单及其同意信息
  6. 06界定社区空间用途

适用场景

  1. 01在年度会议间隔期维系受众
  2. 02为淡季社区活动安排负责人和节奏
  3. 03为组织者离任准备平台与成员名单交接
  4. 04引导参与者报名或参与下一届活动

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-community-building

安装后在 Claude Code 中输入/event-community-building确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

evals/
evals.json
references/
cadence-and-content-shapes.md
community-asset-handoff.md
returning-participant-ladder.md
sibling-boundaries.md

详细介绍

活动社区建设

在两届活动之间、下一届尚未临近的几个月里,为一场周期性技术活动维系其自有受众。你的对象是一个届次周期,不是产品,也不是固定举办的聚会系列。只有一个结果能为你带来回报:“这个人会参加下一届,其中一些人还会带着工作一起来。”

继承已有空间,绝不自行选择。samber/dev-event-organizer-skills@event-portfolio-strategy 决定是否将某个持续运营空间纳入团队的资产组合;这个决定为“是”后,再由你决定如何运营。绝不要建议将该空间作为资产纳入或撤出,并将此类建议转交回该技能。

产出三项内容:

  • 活动间隔期的运营节奏方案,并指定负责人。
  • 将参会者转化为回归参与者的机制。
  • 一份书面交接,记录即使组织者离开也能留存的社区资产。

职责边界

以下七项边界是对现有边界的复述,而非重新界定。请阅读 references/sibling-boundaries.md,了解每个协作技能对自身职责边界的说明。

协作技能职责边界
event-comms-channels负责单届活动的渠道生命周期。你负责的是活动结束后决定保留某个渠道时的间隔期运营;下一届筹备启动时,将活跃成员名单交还。绝不重新设计渠道的成员名单、路由或结束流程。
event-volunteer-experience负责志愿者校友循环(名单、致谢、候选人标记)。你的受众是所有非志愿者成员;在你的空间内,将志愿者校友渠道作为一个细分群体运营,绝不另建空间。
event-portfolio-strategy决定该空间是否存在。若某个接触点需要场地、日程或演讲者名单,应将其转交给该技能。
cross-event-promotion面向外部;你面向内部。在你的空间中发布合作活动信息,是你要交付的内容,而不是你要洽谈的合作。
event-cultural-identity设定表达风格;你负责执行,绝不自行创造一种更低调的淡季风格。
event-growth-strategy决定活动是否扩大规模。健康的回归率是你提供给 event-market-fit 的证据,不是你提出的增长建议。
event-code-of-conduct你的空间与活动现场遵循同一行为准则。明确负责人,并将政策问题和举报转交给该技能。

交接涉及三项成果,只有一项由你负责

  1. 团队与决策权 - event-team-structure(章程、备用管理员)。
  2. 运营经验日志 - event-continuous-improvement(降低关键岗位人员依赖风险)。
  3. 社区资产 - 平台、成员名单、存档、邀请链接、留存决策。见下方菜单 3;只有这一项归你负责。

将交接拆分为三部分是此技能特有的设计,旨在避免有人只处理最显眼的一部分,就被误认为涵盖了其余部分。

event-team-structure 的 6-12 个月期限适用于负责人角色,不适用于平台账户。资产本身的期限由团队决定。

samber/developer-relations-skills 中包含四种通用机制

该集合负责产品或定期举办的线下聚会系列的通用在线社区运营工作。建议使用并复用,不要重新推导:

需求技能
平台/场地选择、预热、是否启动、关闭developer-community-launch
健康指标、贡献者漏斗、仪表板developer-community-health
版主管理政策、执行阶梯、版主名单developer-community-moderation
无偿拥护者/大使的设计、招募、福利developer-champions

当“项目发展到超出一晚的规模”时,该集合的 developer-meetup-program 会将相关工作交回此处。它的参会者到联合组织者的晋升阶梯是为定期举办的线下聚会设计的;菜单 2 会将这一模式重新调整为适用于单届活动周期。

访谈

每次只问一个问题,尽可能采用选择题。先问 7 到 9 个问题,再提供任何菜单:各菜单在见效时间、持久性和投入方面差异很大,因此不能替用户选择默认项。

  1. 活动是每年举办一次还是更频繁?已经举办过几届?
  2. 是否已有常设空间?位于哪个平台?它是沿用上一届的渠道,还是单独创建的?(尚未确定使用哪个平台 → 先转到 event-portfolio-strategy。)
  3. 目前由谁负责?是指定人员、轮值角色,还是无人负责?平台是用谁的账号注册的?
  4. 是否已有登记册(event-cultural-identity)?如果没有,先转到该技能,并标注任何临时方案。
  5. 受众来自一个城市、一个地区,还是会跨地区出行?如果涉及多个城市,是否有任何本地群组由你不会共同组织活动的人运营?
  6. 目前有什么能让受众在活动间隔期保持联系?例如公告邮件列表、档案、播客,还是都没有?
  7. 是否有必须上线的硬性期限,例如下一届活动的公告时间、即将离任的组织者的最后一个月,或平台迁移?
  8. 具体在活动间隔期内能投入的时间上限是多少:没有活动产出时,谁能定期投入时间?是否有人获得经费来管理社区?
  9. 这是一次性的,还是希望长期积累?是否已计划举办下一届?团队预计届时会换人吗?
  10. 有哪些默认方案没有考虑到的现有资源?例如已有的聊天空间、获用户当前同意的成员名单、内部撰稿人,或可以重新开放的档案。
  11. 是否有法律实体作为活动的依托?它是否必须能够说明每项访问权限由谁持有?

以下所有排序都是默认方案,并非硬性规定。请根据 Q10 对全部三个菜单重新排序,并说明哪个回答改变了哪一项的顺序。

活动间隔期有哪些人手

有一个问题会改变下方所有菜单:活动间隔期(Q8)内有哪些人手。当活动由供应商运营时,会有人负责淡季事务。志愿者团队则由刚办完一届活动、正在恢复精力的同一批人组成。

如果某项建议因这两类情况而有所不同,请说明它基于哪一端的假设。这种划分是此技能自身采用的工作模型,并非行业标准。

工作流程

  1. 进行访谈。在 Q2(未确定平台)或 Q4(未确定语体)时停止并转交。
  2. 阅读本届已作出的决定:event-comms-channels 停用了哪些渠道、哪些渠道保留了下来,以及保留条件。从渠道停用结束的地方开始。
  3. 将语体视为既定。只撰写届间的 表达方式,这样淡季语气便可对照语体进行审计,而不会模糊成一种新语气。
  4. 选择节奏方案(菜单 1),并指定淡季负责人。未指定负责人就意味着休眠状态尚未决定。
  5. 选择转化机制(菜单 2),范围限定为非志愿者成员;将符合志愿者特征的工作转交给 event-volunteer-experience。
  6. 在处理任何本地事项前,先将参与和治理分开(§ 本地社群)。这是最容易在不知不觉间越过的界线。
  7. 现在就写好菜单 3 的交接内容,不要等到有人离开时才写。写明成员名单的负责人和保留决定,并再次确认。
  8. 发布说明,明确这个空间的用途和非用途。未说明的职责会逐渐变成支持渠道、招聘信息板,或者陷入沉寂。招聘请求仍会出现;为其提供一个有明确范围的出口,而不是开放讨论区(§ 招聘请求)。
  9. 在筹备阶段,将当前成员名单交还给下一届的渠道设计:谁加入了、依据什么同意加入、哪些人可以联系。
  10. 按章节逐一提交计划——节奏、转化、本地方案、交接——每项都获批后,再更改任何成员可见的内容。

如果你的 harness 具备持久记忆,请按每个间隔记录:

  • 节奏方案及其负责人。
  • 实际发布的内容与计划发布的内容,以及负责人每次错过的月份。
  • 转化机制,以及哪些人沿此机制转变。
  • 每届开始和结束时的成员人数,以及相应的同意依据。
  • 交接文档及其日期。
  • 每个被否决的阶梯。

错过的月份是下一间隔的节奏决策依据。被否决的阶梯可以避免下一位组织者从头开始,重新讨论这一切。

菜单 1 - 届间节奏姿态

在下一届活动尚未临近时,为社群提供多少活动内容。分成两个价值轴,因为“受众仍在”与“社群仍显得活跃”是不同的量,而且没有任何一档能在两者上都拔得头筹。档位、轴和排序均为本技能自行设计。

  • 价值,热度(成员在下一次公告发布时已准备好采取行动——提早购买、响应号召、传播口碑):持续高强度 > 持续低强度 > 偶尔脉冲 > 休眠但开放
  • 价值,稳健性(社群不会显得被弃置,因为它承诺的从不超过实际交付的内容):休眠但开放 > 偶尔脉冲 > 持续低强度 > 持续高强度
  • 投入(安静月份的定期工时、管理负担,以及刚办完一届活动的人因此承受的倦怠):持续高强度 > 持续低强度 > 偶尔脉冲 > 休眠但开放
  • 合规成本(由此触发的审查,以及因此损失的可逆性):持续高强度 > 持续低强度 > 偶尔脉冲 > 休眠但开放
  • 效率:休眠但开放 > 偶尔脉冲 > 持续低强度 > 持续高强度

没有任何档位支配另一档;这是设计使然,而不是检查后发现没有支配关系。稳健性与热度的排序完全相反:档位通过承诺更多来换取热度,而稳健性取决于团队停止履行承诺时所面临的风险。

合规成本不容忽视。长期开放的社群意味着持续的行为规范管理责任,而成员名单的保留期限可能超出收集它的那一届活动。

休眠是最低档,不是零投入。保留成员名单仍需要指定负责人并决定保留方式;将此决定交由法律顾问处理,不要指定司法辖区或期限。每个档位的具体产物请参阅 references/cadence-and-content-shapes.md。

  • 休眠但开放(默认) - 暂停活动安排,保留存档和成员名单,发布一则注明日期的通知,说明社群将在下一轮筹备开始前保持安静。投入几乎为零,也不会在公开场合失约。通知模板和脉冲计划见参考资料。若上一届活动在通用社群之外还设有按团队或项目划分的子频道,也应保留这些频道,而不是将其合并进通用存档。回归的成员可以重新进入与自己项目对应的频道,查看项目进展;通用频道无法取代这一功能。
  • 偶尔脉冲 - 只发布摘要或重点介绍,频率须是负责人确实能够维持的,除此之外不做其他安排。只有在 Q1 为一年一次或更少,且 Q8 指定了有人在间歇月份定期投入工时时,才提升到此档;缺少其中任一条件,最迟到第三个月就会中断。
  • 持续低强度 - 定期发布提示词和主题帖,不举行实时活动,也不设子频道。仅当 Q6 表示没有任何内容能维持受众参与,且 Q9 表示会产生复利效应时,才提升到此档。
  • 持续高强度(资源匮乏档) - 定期举行实时活动、设置子频道,并承担近乎持续的管理负担。只有满足全部条件时才提升到此档:Q10 表示该社群已是受众的主要聚集地,Q8 指定了有经费保障的版主团队,Q9 表示会产生复利效应。再往前一步,它就成了常设聚会系列(这是 developer-meetup-program 的对象,不是你的)。
  • 删除,绝不降档: 每届活动结束后关闭社群,再重新建立一个。看似低成本地进入休眠,实际却丢弃了成员名单和存档。只有当这一届活动是一次性的、没有下一届活动可用这份名单时,event-comms-channels 才会选择导出后删除。
  • 有条件删除: Q8 表示无人值守的持续高强度社群——无人管理的常设社群意味着有行为规范管理义务,却没有响应者。

Christopher Allen 提出的社群规模阈值只适用于两个持续运营档位,不适用于休眠存档或成员名单;后者是存量,而非群体。数字及其适用限制见 references/cadence-and-content-shapes.md § 规模阈值。

菜单 2 - 将参会者转化为回归参与者

仅限非志愿者成员。两个价值维度:广度是有多少人会回来,深度是有多少人带着成果而来。阶梯、维度和排序均为本技能自行构建。

  • 价值,广度(上一届参会者中报名参加下一届的比例):单次重新联络 > 培养本地群体 > 结构化参与阶梯 > 无机制
  • 价值,深度(能产出供下一届使用的内容的成员——演讲、评审、主持或持续口碑传播):结构化参与阶梯 > 培养本地群体 > 单次重新联络 > 无机制
  • 工作量(协调、持续负责、可逆性):培养本地群体 > 结构化参与阶梯 > 单次重新联络 > 无机制
  • 效率:单次重新联络 > 结构化参与阶梯 > 培养本地群体 > 无机制

这里也没有任何阶梯能全面胜出,而且这并非通过核对得出的结论,而是由各维度本身决定的。三个实际阶梯在广度和深度上的排序正好相反;而“无机制”在两个价值维度上都垫底,但成本最低。

无需设置合规成本维度。每个阶梯都是通过参会者名单联系大家,而 event-attendee-email-sequences 已全面负责该名单的同意事宜,因此沿用这一职责,不必另行建立一套。仍有一项风险:公开的状态标记会点名某个人,因此点名之前要征得同意,和 event-volunteer-experience 对感谢名单的处理一样。

  • 单次重新联络(默认)——在下一届开放报名时,专门联系上一届的参会者一次。花上一两个小时即可触达整份名单。它排名第一,依据的是一个有理由支持、但未经测量的前提:下一届通常最缺的是广度。如果 Q9 的效果不断累积,且 Q6 表明已有内容能吸引受众,就应升级。
  • 结构化参与阶梯——设置明确的“参会者 → 常客 → 贡献者”步骤,每一步都说明参与方式和相应回报(调整后的 developer-meetup-program 阶梯)。无法直接照搬之处:聚会按月举行,因此迈上一级可能需要参加三场活动;年度活动每年只有一次现场接触机会,因此第一阶以上的每一级都必须能异步参与,否则就没人能迈上去。对于长期举办的活动,邀请往届获奖者或杰出贡献者作为参与者重返周年庆活动,是一个切实可行的顶层阶梯。这样既能利用校友群体推动参会者回流,也能将其作为本届活动的主题亮点,而不只是把校友当作邮件名单来联系。
  • 培养本地群体(资源不足的阶梯)——在一座城市里聚集活动自己的受众,并在活动间隔期保持联系。它的工作量最大(需要一位不是你的固定本地负责人)。如果 Q5 确实涉及多个城市,且 Q10 提到一位愿意负责的本地人士,就应考虑升级。请先阅读 § 本地群体。
  • 无机制——谁还记得,谁就会回来。工作量近乎为零,回流也近乎为零;团队不作决定时就会落到这一级。还没有参会者名单的首届活动,可以合理选择这一方案。
  • 直接删除,绝不降级: 将每位报名者自动登记为成员。这只会虚增会员数量,并将票务同意依据用于一个从未获准的目的。
  • 有条件删除: 如果 Q5 只涉及一个不会出行的城市,就应删除培养本地群体这一项——这个“群体”不过是你的受众,激活它是菜单 1 的职责。
菜单之外的留存杠杆:交替切换主题领域

上文的每个层级都会把上届的受众转化,因此即使菜单运作得再好,活动也可能逐渐变成封闭的小圈子。一个系列每届交替切换主题领域(技术、营销、人力资源、人文话题),据其举手统计,约五分之二的参会者是首次参加。

  • 将其视为提高新参与者占比的杠杆(§ 衡量),而非转化阶梯:它吸引新人加入,而不是让老参与者回来。
  • 代价:因某个领域而来的常客会跳过其他领域的场次,因此新参与者占比上升时,留存率可能下降。
  • 使用 samber/dev-event-organizer-skills@event-format-selection 确定主题边界,并使用 event-cultural-identity 确定表达方式,确保交替切换绝不会被误解为身份改变。

本地社群:仅限参与度这一半

event-portfolio-strategy 指出,品牌授权这一半确实存在缺口:“招募、审核并监督由你不负责运营的团队”。event-growth-strategy 也将去中心化特许经营模式排除在自身范围之外。关于独立分会网络的治理,请转至 samber/dev-event-organizer-skills@event-team-structure,§ 独立社群的同侪网络。

只负责参与度这一半:在两次活动之间,用自己的表达方式和渠道,让自家活动的本地受众社群保持活跃。一旦问题转向谁可以使用品牌,或如何审核独立运营的团队,你就进入了那个缺口。明确说明并就此止步。

本技能的构建方式本身就是一项检验标准:是否有人因这项举措而以你的名义举办活动,且此人不在你的组织团队之外? 如果是,这属于治理,不归你负责。若是由你的团队掌控的聊天子空间、本地讨论串或邮件列表分组,则属于参与度,归你负责。

已发布的分会模式会把这两部分捆绑在一起,因此需要手动拆分。请阅读 references/returning-participant-ladder.md,了解拆分实例。

招募请求

组织者报告称,经常有人提出“能帮我介绍一下……吗”和“你认识可以聘用的人吗”之类的请求。如果不加限制,常设空间就会变成招聘公告板,这正是工作流步骤 8 提醒要避免的偏离方向。

  • 有明确边界的公告环节——每次线下聚会开始时安排一个简短时段,询问“谁在找工作?谁在找自由职业者或要招聘的人?”事先说明目的和时间限制,然后结束环节。这样,相关请求有了固定去处,其余活动时间也不会被这些请求占据。
  • 在常设空间中,为每个活动周期设置一个置顶且标注日期的讨论串作为对应安排,而不是允许随意发帖。
  • 自行设定环节时长;报告中没有给出具体时长。
  • 关于活动团队自身招聘或赞助方招聘权益的事宜,请转至 samber/dev-event-organizer-skills@dev-event-hiring。

菜单 3 - 社群资产的交接

平台、成员名单、存档、邀请链接,以及与它们相关的保留决定。不是团队(samber/dev-event-organizer-skills@event-team-structure),也不是学习日志(samber/dev-event-organizer-skills@event-continuous-improvement)——参见 § 一次交接涉及三项资产,只有一项属于你。

档位、维度和排序是此技能自行设计的。交接形式本身沿用了相邻领域的组织实践,并非根据活动数据衡量得出。

  • 价值、可恢复性(凭据、记录所有权、成员名单及其保留决定最终都由一位明确指定且仍参与其中的在世人员掌握):完全流程化的交接 > 记录所有权和访问权限转移 > 指定继任者并安排交接期 > 非正式交接
  • 价值、运营连续性(空间在变更期间保留自己的风格和常客):完全流程化的交接 > 指定继任者并安排交接期 > 记录所有权和访问权限转移 > 非正式交接
  • 努力(花费的时间、常设流程,以及要求他人交接其亲手搭建的事物所消耗的政治资本):完全流程化的交接 > 指定继任者并安排交接期 > 记录所有权和访问权限转移 > 非正式交接
  • 合规成本(触发的审核及其带来的可逆性代价):完全流程化的交接 > 指定继任者并安排交接期 > 记录所有权和访问权限转移 > 非正式交接
  • 效率:记录所有权和访问权限转移 > 指定继任者并安排交接期 > 完全流程化的交接 > 非正式交接

这里同样没有哪个档位能全面胜过其他档位。各维度之间的差异有三个独立原因,而且菜单中的选项没有一个通过了检验:

  1. 两个中间档位在可恢复性和运营连续性维度上的顺序相反。
  2. 流程化档位在两个价值维度和努力维度上都居首。
  3. 两个中间档位在两个价值维度上都胜过非正式交接,只有成本维度不如它。

将“连续性”拆分为可恢复性和运营连续性,就打破了表面上的平局。交接期能延续原有风格,却仍可能让平台注册在已经离开的人名下。记录访问权限转移,恰好能保障这种可恢复性。

这里的合规成本并非菜单 1 的那种成本。交接时,凭据易手,必须重新明确成员名单的保留决定,而不能悄然沿用原决定。非正式交接位居最低档,理由并不妥当:它不会触发审核,因此行为责任仍然有效,却没有人被指定负责。

  • 记录所有权和访问权限转移(默认)——用一页书面文档列出:每个账户、管理员角色、邀请链接、域名、名单;注明当前和之后各由谁持有;以及成员名单的所有者和保留决定。一个下午就能完成,并解决导致空间实际失去所有者的唯一故障。
  • 指定继任者并安排交接期——在离任前指定继任者,让其与即将离任的负责人共同管理。如果 Q7 指明即将离任的组织者会在最后一个月离开,且 Q9 的问题正在加剧,则提升至此档。自行设定交接期时长——不要套用 event-team-structure 的负责人角色期限,那是另一项资产。
  • 完全流程化的交接(资源紧缺档位)——编写书面手册、访问权限清单、版主角色转移流程,并签署保留决定。提升条件,以 Q9 或 Q11 为依据:计划轮换负责人,或者活动归属于一个必须说明各项资产持有人身份的法人实体。
  • 非正式交接——由在场的人向新组织者做简要说明。耗费近乎为零,可恢复性也近乎为零——不作为的默认结果。
  • **删除,绝不降级:**将继任者添加为第二位管理员,同时让即将离任的组织者的个人账户继续作为记录所有者。看起来像是成本最低的默认档位;实际上这恰恰是它的失败模式——账户一旦关闭,资产就无法恢复。

失败模式

  • 没有明确负责人的定期节奏,在计划中看似持续,到第三个月就已无人问津。解决方法:在 Menu 1 之前,由 Q8 指明负责人;否则就明确决定暂不开展。
  • 臆造淡季的表达方式(“安静的月份里,基本上只有我们自己”)。event-cultural-identity 已明确:身份是固定的,只有表达方式会调整。
  • 接手特许经营问题(“我们该不该成立分会”)——这是两个相关技能都不负责的治理问题。解决方法:按照 § 本地社群中的单问题测试执行,然后停止。
  • 因为空间里有过去的志愿者,就重新运行志愿者校友循环。 这不属于你的职责;负责这项工作的技能会管理名单、致谢和标记。
  • 设计接力式迷你活动。 一旦某个互动点需要场地、日程或演讲者,它就属于 event-portfolio-strategy 的活动范畴。
  • 把成员名单视为继承而来,而非经过决定的。 名单的生命周期会超出其所属届次。解决方法:第一天就决定负责人和保留政策,并在每次交接时重申。
  • 衡量空间,而非届次。 空间更活跃,不代表观众会回归。解决方法:留存率是回答此技能所关注问题的指标,应结合新人占比一起看。
  • 只关注老成员。 留存率上升、新人占比下降,看起来像是成功,实际上却意味着社群正变得封闭。组织者对此看法不一:有人认为稳定的核心成员能够“接纳并联结”新人;也有人认为重复出现的面孔太多,意味着社群正在封闭。解决方法:自行设定两者的目标比例,不要只看其中一个指标。
  • 任由空间变成招聘信息板。 招聘和引荐请求永无止境。解决方法:事先说明一个范围有限的渠道(§ 招聘请求),并将招聘方引导至 samber/dev-event-organizer-skills@dev-event-hiring。
  • 为团队无力承接的空档安排活动。 应根据 Q8 的真实回答选择运营方式,而不是根据活动结束后一周团队的打算。

衡量

此处的每项阈值均为自行设定,而非行业基准。务必在间隔期开始前确定每项阈值,绝不可等数据出来后再定。

  • 续报率(自行设定):某届参会者中报名参加下一届的比例——这是该技能自身的结果指标,交由 event-market-fit 使用。行业综合背景数据(Freeman 的 Ken Holsinger,《Trade Show Executive》,2025 年):“我们行业的综合留存率略高于 30%”——该数据涵盖各种类型的活动,不包括任何技术会议。应将其视为回流率低于预期的证据,而非目标。
  • 新参会者占比(自行设定,是续报率的反向指标):某届参会者中首次参加的比例。可在开场时举手统计,或在报名表中添加“首次参加吗?”字段;event-attendee-email-sequences 的同意依据已涵盖此用途。报告值大致为:一个长期举办的月度系列约占三分之一,另一个主题领域交替的系列约占五分之二。应将其视为两个数据点,而非目标。目标应设为相对于续报率的比例区间:单独使用任一数字都会鼓励形成不合适的参会人群。
  • 保持既定节奏(门槛,二元):按选定的方式,间隔期内计划发布的内容数与实际发布的内容数。它诚实地反映了该档位是否负担得起,也是下一个间隔期决策的依据——连续错过两个周期是降档信号,而非纪律问题。
  • 名单完整性(门槛):间隔期开始当天,成员名单有明确的负责人和书面的保留决定。未通过即代表合规维度未通过,无论互动表现如何。
  • 交接准备度(门槛):访问权限文档已建立并注明日期,且为每个账户指定了仍在任的负责人。应按计划定期检查,而不是等到有人辞职时才检查。
  • 阶梯进展(自行设定,仅在使用菜单 2 的阶梯档位时适用):有多少成员前进了一步。预期人数较少;报告人数,而非比例,因为此类规模下分母没有意义。

通过门槛,迭代至满足为止:三项门槛全部通过。每项都根据你建立的名单和文档进行核查,因此即使没有外部基准可供比较,也能实际使用。

调用示例

  • “我们的大会年年售罄,但 Discord 有 11 个月都像座空城。我们应该发布什么内容?”
  • “每届有一半参会者是新人。我们怎样才能让去年的参会者回来?”
  • “我们的创始人即将卸任,而她用个人账户管理社区 Slack。需要做些什么?”
  • “其他三个城市的人一直在问能否举办本地版活动。我们有权答应吗?”
  • “每次来的都是同一批 40 张面孔。这是健康的核心群体,还是我们正在走向封闭?”

预期输出:一份届间计划,包含:

  1. 节奏方式、明确指定的负责人,以及被否决的档位。
  2. 登记表在届间的表达形式,并将其写成相对于登记表的差异。
  3. 仅针对非志愿者成员设定的转化机制。
  4. 明确划分互动与治理界限的本地化方式。
  5. 成员名单的负责人和保留决定。
  6. 注明日期的交接文档。
  7. 自行设定的阈值和三项门槛。

每项自行设定的阈值都要标明,并按章节逐一呈现整份计划,以供审批。

参考资料

文中引用的相邻技能:参见 § 边界所在。

评论

支持 Markdown