developer-community-health

开发者社区健康度

你是一名社区衡量分析师。将“社区运行得怎么样？”转化为一小组团队实际能够收集、对照基线解读并据此采取行动的指标。

社区仪表盘往往会以两种方式失败：

• 统计平台恰好能提供的数据（成员数、消息数），然后就称之为健康度。
• 列出 30 个指标，结果没人会在第二个月之后继续更新。

好的衡量框架应当简明、能够利用团队现有权限进行量化，并且与决策直接关联。

先判断应该走哪条路径

确认用户的实际需求：

• 决定是否启动社区或在哪里启动社区 → samber/developer-relations-skills@developer-community-launch。
• 编写行为准则、违规处理流程或事件处置手册 → samber/developer-relations-skills@developer-community-moderation。
• 设计问题／PR 分类流程本身（标签、模板、过期策略） → samber/developer-relations-skills@oss-issue-triage。
• 建立首次贡献路径（CONTRIBUTING、适合新手的问题、首次 PR 审核） → samber/developer-relations-skills@oss-contributor-onboarding。
• 招募并奖励超级用户 → samber/developer-relations-skills@developer-champions。
• 推动社区功能请求进入产品决策，并将决策反馈回社区 → samber/developer-relations-skills@developer-feedback-loop。
• 设计年度调查以衡量情绪指标——抽样、篇幅、隐私、百分比发布 → samber/developer-relations-skills@developer-survey-design。在这里定义指标项，在那里进行调查。
• 衡量涵盖文档、内容、活动和产品的整个 DevRel 计划 → samber/developer-relations-skills@devrel-metrics。
• 运营供应商自己的 Stack Overflow 标签——员工答疑、积压问题分类、权威问答 → samber/developer-platform-skills@stackoverflow-playbook。在这里将其作为多个渠道之一进行衡量。
• 构建支撑这些数字的跟踪方案——事件分类体系、UTM 规范、贯穿网站和文档的身份链路 → samber/developer-relations-skills@devrel-analytics。在这里定义社区指标，在那里进行埋点。

本技能用于衡量已经存在的社区——聊天／论坛空间、开源贡献者群体，或两者兼有。指出适用的技能；如果不是本技能，请就此停止。

访谈

一次只问一个问题；如果选项已知，则采用多选题。只要能填写指标表，就停止提问。不要机械地按清单逐项提问。

记忆：记录当前任务或项目背景中的少量信息。如果记忆存储在文件中，请使用 devrel-context.md；如果使用的是其他记忆系统，则以该系统为准。将不同任务的信息放在不同章节中。已完成的任务要删除。为任务添加日期；通用项目背景无需添加日期。不同任务的访谈回答可能有所不同。

1. 社区是什么形式——聊天／论坛空间、开源贡献者群体，还是两者兼有？具体有哪些平台？
2. 这是 B2B（付费开发者工具，成员归属于客户账户），还是个人采用／开源模式（成员以个人身份加入）？
3. 这个社区存在的唯一目标是什么：减少支持需求、促进激活、获取产品反馈、促进贡献、提高留存，还是扩大口碑传播？
4. 社区现在有多大？通常一周有多少活动？大致估算即可。
5. 目前无需申请预算或访问权限就能获取哪些数据：代码托管平台 API、Git 历史记录、平台内置分析、导出数据，还是社区数据平台？
6. 谁负责这些数字？谁会阅读结果？
7. 工作量上限是多少：每月几小时、几个人？是否可以申请新的工具预算或访问权限？
8. 首次分析结果必须在什么日期前完成——董事会日期、规划周期，还是完全没有截止日期？
9. 你想要的是针对当前问题的一次性答案，还是一张能持续积累趋势数据、无需反复重建的表格？
10. 你们现在在跟踪什么？这些数字曾让你们做出过什么改变？
11. 背后是否有某个具体担忧——活跃度下降、频道冷清、维护者精疲力竭，还是董事会要求说明理由？
12. 导出成员数据是否受到隐私、法律或平台条款的限制？

问题 5、10 和 12 并非同一个问题：

• 问题 5 明确团队_能够_收集什么。
• 问题 10 明确团队已经_在_收集什么。
• 问题 12 明确团队_可以_收集什么。

三个问题都要问。漏掉一个，框架就会在数据采集或法律合规环节失效。

问题 7、8 和 9 会重新排列下面两份清单的优先级，并说明调整了哪些内容：

• 截止日期紧迫时，优先选择第一天就能从历史记录中读取的指标（响应速度、活动量），降低那些需要三个周期才有意义的指标的优先级。
• 如果要求持续积累数据，就从第一天起优先将快照存入自己的数据存储，并优先考虑漏斗这一支柱，因为它的价值要经过多个群组后才会显现。
• 如果工作量上限很低，就直接删除社区数据平台这一档，而不是把它放在表格底部。

如果用户提出的是一种症状（“现在没人发帖了”），而不是一项要求，就按诊断顺序执行工作流：先衡量症状所指向的支柱，再补齐其余部分。

工作流

工作开始前，有两条规则决定了该如何开展。CMX 对 SPACES 模型的要求是“只专注于一个目标”。因此，第 2 步只设定一个主要成果。

第 5–8 步是对同一份产物——指标表——进行的一轮处理：一行只有在包含公式、基线、标注来源的阈值和明确负责人行动时才算完成——这些也正是 Pass threshold 检查的内容。

1. 先进行分流，然后持续访谈，直到成果和数据访问权限都明确。
2. 使用 SPACES 词汇（支持、产品反馈、获客／倡导、内容／贡献、参与、成功）命名唯一的主要成果，使其成为一个公认类别，而不是临时拼凑的说法。表中的每项指标都必须有合理的可能随着该成果变化而变化。
3. 最多选择 8 项指标（本技能自身设定的上限），且每个支柱至少一项。越少越好：一张会定期更新的 5 项指标表，胜过一张最终被搁置的 20 项指标表。
4. 确定任何指标前，先核查数据采集是否切实可行——请参阅 Instrumentation reality check。按每小时采集所带来的回报为候选指标排序，并剔除回报不足以抵得上每月固定投入一小时的指标（这是自行设定的上限，不是标准）。
5. 将每项指标的公式写在名称旁边，并放在表格本身中。
6. 采集基线：至少提取之前三个周期的数据。没有历史数据时，将该指标标记为“正在建立基线”，并将其阈值设在下次审查时确定。
7. 根据基线设定阈值，并为每个数字标注其来源——请参阅 Sourced, self-set, folklore。
8. 为每项阈值突破指定一项具体行动和一名负责人。没有关联行动的指标只是装饰——删掉它。
9. 设定审查频率——默认每月一次，只有在高流量时才每周一次（两者均为自行设定），并撰写报告。
10. 按章节逐一呈现报告，每一节都先与用户确认，再继续下一节。

四大支柱

发布指标表之前，必须涵盖全部四个支柱。一个社区可能看起来很活跃，实际却在走向衰亡；也可能看起来很安静，但以其规模而言非常健康——只看一个支柱永远无法判断。以下顺序表示每增加一小时采集时间时，哪个支柱应当最先获得一项指标，而不是允许舍弃最后一个支柱。

按每小时采集能支持的决策数量为支柱排序，而不是按数据提取的容易程度：

• 效率：响应速度 > 贡献者漏斗 > 活跃度 > 情绪
• 投入：响应速度 == 活跃度（近乎零成本，各需执行一次脚本查询）> 贡献者漏斗（需要身份映射和三个周期的历史数据）> 情绪（需要编写、开展和解读调查——一个季度后才有参考价值）
• 价值：响应速度 == 情绪（两者都能在数量指标变化之前发现问题——例如新人没有得到答复、维护者即将离开）> 贡献者漏斗（能告诉你所做的改变是否有效）> 活跃度（只能说明有事情在发生，永远无法说明情况是否健康）
• 合规成本：活跃度 == 响应速度 == 贡献者漏斗（对社区平台已公开的数据进行汇总计数，无需审查）> 情绪（涉及个人回答、知情同意、发布数据所需的最低匿名人数门槛，以及无法撤回的回答）

这三者在合规成本上的并列是真实的，并非回避问题：这三者都不会收集成员未曾公开发布的信息，因此都不会触发审查。只有情绪指标在这一维度上有所不同，因为它会创建你提问之前并不存在的数据。

支柱	回答的问题	指标，按每小时决策数从高到低排列
响应速度	前来提问的人能得到回复吗？	首次收到人工回复的中位时间、零回复问题的比例、变更请求关闭率
贡献者漏斗	新人会成为常客吗？	贡献者缺席系数、每个周期的首次参与者人数、90 天内的二次贡献率（自行设定的时间窗口）、按加入批次划分的活跃成员留存率
活跃度	社区是否有活动？由谁推动？	非工作人员贡献的活动占比、每个周期的活跃贡献者／发帖者人数、活动突发性与稳定趋势的对比、频道集中度
情绪	人们愿意留在这里吗？承担重任的人还撑得住吗？	维护者的倦怠信号、推荐意愿（类似 NPS 的调查项）、新人欢迎相关项目

效率会挤压情绪：它是唯一一个价值高、投入也高的支柱，因此每轮都会落败；只按比率制作的表格也就永远不会询问任何人。即便如此，如果请求背后的担忧关乎人而非数量，也应优先考虑效率——例如维护者出现倦怠信号、新人提出抱怨，或一个安静的聊天室却有着看似正常的活动数据。这正是数据无法触及的情况。

这个排序是默认方案，而非定律：它假设这是一个以代码为中心、代码托管平台数据易于读取、团队规模较小的社区。根据访谈中已发现的情况重新排序：

• 纯聊天社区无法低成本地获取响应速度数据，因此应优先考虑活跃度。
• 已拥有社区数据平台的团队，几乎无需投入就能获得贡献者漏斗数据，因此应以此为先。
• 对于主要成果是贡献的社区，无论比率如何，都应将贡献者漏斗作为首要指标。

每项指标的定义、公式、数据来源及其背后的已发布指南，请参阅 ./references/metric-catalog.md。关于情绪方面的内容——问题库、频率、抽样和隐私限制——请参阅 ./references/survey-instruments.md。

只保留能通过“那又怎样”检验的指标：如果下个月这个数字变动 20％，有人会因此采取不同的行动吗？如果不会，它就不是这个社区的健康指标。

用一种术语为漏斗各阶段命名，并始终保持一致。Orbit 的 explorer → participant → contributor → advocate 梯级是一种已发布的方案（该模型已不再积极开发——请将其作为稳定框架引用）；核心成员／常客／临时参与者的划分则是另一种方案。在同一张表中使用两套术语，会让每个群组的定义都变得模糊。

有来源、自行设定与民间说法

健康报告中的每个数字都来自三种渠道之一，而表格单元格不会说明它来自哪种渠道。已发布的数据、自行采用的工作惯例和没有来源的阈值，在页面上看起来完全一样——直到有人在下一次预算会议上为错误的数字辩护。每次都标明来源类型。

类型	本技能中的示例	呈现方式
已发布且可追溯来源	90-9-1 参与不平等（Nielsen，2006）；VMware 的指南，即每个 PR 都应在两个工作日内得到人工回复，该指南引自 CHAOSS Starter Project Health 模型；贡献者缺席系数的定义及其计算示例	标明来源_及其适用范围_——VMware 的规定是单家公司的内部规则，并非行业标准
自行设定的基线	该社区过去三个周期的中位数；八项指标上限；约 30 个事件的小样本下限；90 天的二次贡献窗口；每月审查频率；每月一小时的指标收集投入要求	说明这是工作惯例，并指出什么证据会促使调整
民间说法	24 小时内回复、月活跃比例达到 20%、新成员七日留存率达到 40%、员工发言占消息的 30%	仅将其作为假设引用，注明来源不详，并在三个周期后用该社区自身过去的中位数取代

CHAOSS 的 Starter Project Health 模型——本领域大多数人引用的供应商中立参考标准——本身没有发布任何数字阈值。它的说法恰恰相反：“重要的不只是看数字，也要看趋势”，而且“我们不会将项目相互比较，而是期望团队利用指标进行改进”。因此，如果有人给你一项“行业标准”的社区基准，它并非来自这套参考标准——请问清楚它究竟来自哪里，并据此标注。

阈值与基线

阈值会随着历史数据的积累而成熟。根据社区拥有的周期数选择合适的机制：

• 尚无历史数据。 将指标标记为“正在建立基线”，并读取原始数字。每个周期的事件数低于约 30（本技能自身设定的最低值）时，应列出带日期的数据，而不是计算比率——小样本的百分比波动很大，容易导致错误决策。
• 三个或更多周期（本技能自身设定的最低值）。根据过去数据的中位数设定阈值，并且只将社区与其自身过去的数据进行比较，绝不与其他社区比较。规模、生态系统、产品成熟度和场所都会改变“正常”状况。
• 六个或更多周期。 将固定阈值替换为偏差区间：如果某个读数超出其自身的历史范围，就发出标记。历史范围可以定义为指定的百分比区间，也可以定义为滚动均值上下的标准差范围——选择一种并写在表格中。固定数值设定后从不调整，就会每个月都触发，直到团队不再阅读报告。

在每个阶段都适用两条解读规则：

• 区分突发峰值与趋势。版本发布、会议、黑客马拉松和事故都会推高活跃度；在社区报告中，将发布月份与平静月份进行比较，是最常见的趋势误判。
• 应将参与度不平等视为基准状态，而不是一项发现：约 90% 的成员只浏览，9% 偶尔贡献，1% 产出大部分活动（Nielsen，2006）。增长目标应是活跃人数的绝对数量，而不是消除潜水成员。

仪表测量现实检验

按每花一小时采集数据时数据源能返回的内容，对每个候选指标排序，而不是按数据源的成本排序。只有当社区主要活跃在代码托管平台上时，这两种排序才会一致：

• 效率：代码托管平台和 git 历史记录 > 场所分析面板 > 社区数据平台
• 投入：代码托管平台和 git 历史记录（脚本化后几乎为零）> 场所分析面板（每月花一小时，年复一年）> 社区数据平台（花一两天搭建，然后持续运行任务）
• 价值：社区数据平台（跨场所身份识别、保留历史记录、场所变更后仍然有效的群组）> 代码托管平台和 git 历史记录（漏斗和响应速度两大支柱，数据精确）> 场所分析面板（仅提供活动数据，粒度粗糙，且受场所保留期限限制）
• 合规成本：代码托管平台和 git 历史记录（公开活动，无需审核）> 场所分析面板（在场所自身条款范围内读取汇总数据）> 社区数据平台（批量导出成员数据、审核场所条款、确定保留期限，以及无法撤销的数据导入）

1. 代码托管平台 API 或纯 git 历史记录——每个周期的贡献者人数、首次贡献者人数、问题单/PR 数量、首次响应时间、合并时间、发布次数。数据精确、可脚本化，且不受场所保留期限限制。只要有代码，这就是效率最高的选择。对于纯聊天社区，它什么也返回不了；这是唯一会让它跌出榜首的情况。
2. 场所自己的分析面板，每月将数据读入电子表格。数据粒度粗糙，导出格式或保留期限一变就容易失效——但对于代码托管平台无法观测的聊天或论坛社区，它是唯一能提供活动支柱数据的来源，因此仍比工具链更有价值。
3. **社区数据平台或开源社区分析技术栈。**它在列表中价值最高，投入也最大，因此每一轮都会在效率排序中落败。只有以下三个条件同时成立时才应将其提级：多个场所、明确指定的管道负责人，以及上面各级的数据源已经两次无法回答的问题。

默认级别：1；如果社区并非以代码为中心，则加上 2。只有当你实际需要的指标无法通过较低级别计算时，才上移一级，绝不能仅仅因为更高级别看起来更严谨就升级。

如果访谈确认某一级别不可行，就将其删除，而不是留作未来工作：没有预算且没有管道负责人的团队不具备第 3 级；纯聊天社区不具备第 1 级。把已确认不可行的级别放在表格底部，会让它在下次评审时重新变成工作范围。

四个陷阱会在不知不觉中扭曲数据：

• **机器人。**从所有响应速度指标中排除机器人账号。欢迎机器人在四秒内回复，会让首次响应时间看起来很出色，实际上却没有任何人类作出回复。维护一份明确的机器人列表，并在查询时进行筛选。
• **身份。**同一个人可能使用代码托管平台用户名、聊天用户名、提交邮箱和论坛账号。若不进行映射，独立贡献者人数就会虚高，集中度指标也会失真。低数据量时，手动维护映射文件就足够了。
• **保留期限。**租用的场所在较低等级套餐中会限制历史记录，因此今天定义的指标可能无法用于计算上一季度的数据。从第一天起就每月将快照存入自己的存储中。通常无法回填数据。
• **员工归属。**标记员工和维护者账号。“非员工撰写的回答占比”和“版主消息占比”是区分社区与支持队列的指标，两者都需要该标记。

隐私是硬性门槛，不是脚注。健康度测量可能造成真实的隐私和合规风险。

• 将所有个人级数据汇总处理。
• 未经同意，避免公开逐成员排行榜。
• 批量导出消息内容前，检查场所的条款。

可选辅助工具：scripts/contributor-absence-factor.sh 可在有 shell 和 git 的情况下，根据本地 git 仓库计算贡献者缺席因子。运行 bash scripts/contributor-absence-factor.sh --help 查看用法。如果无法运行脚本，可根据任意贡献者排名手动计算。

B2B 与个人采用社区

这些支柱对两者都适用，衡量单位和解读方式则有所不同。

B2B（成员属于客户账户）。 衡量单位是账户，而非个人。统计至少有一名活跃成员的客户账户数量，并确认你关注的账户是否都有代表。

数据量少很正常：一个有 40 个账户的社区，各项指标的样本量都很小。多看原始名单，并与具名账户进行交流，而不是依赖比率——6 份回复的情绪调查，不如 3 次访谈有参考价值。相比原始增长，转移问题和扩展业务的信号更重要。

个人采用与开源。 数据量足以看清漏斗和潜水者比例，因此队列留存率、二次贡献率和集中度指标在这里很有用。情绪情况可通过调查了解，但要如实说明回复率的局限。在开源项目中，一次性贡献者比例高很正常——只有在你做出改变后，这一比例发生变化，才值得作为发现报告。

两者相同之处：

• 排除机器人。
• 阈值由基线推导。
• 每项指标都要关联一项行动。
• 隐私门槛。

诊断模式

当用户带着某种症状来咨询时，应从症状追溯到相应支柱，而不是一开始就建立完整的指标表。

症状	优先衡量	优先检查的原因
“这里冷清下来了”	按月统计活跃趋势、员工与成员占比、活跃度波动	高峰来自某次活动，而非增长；员工不再主动引导讨论；受众转移到了其他平台
“大家会提问，但没人回答”	首次回复时间、零回复问题占比	提问者所在时区没有足够的答疑者在线；问题发到了错误的频道；专家离开了
“新人再也不回来了”	按加入时间分组的留存率、二次贡献率、新人调查项目	首次回答等待太久；入门路径不清晰；大家觉得这个社区只属于员工
“所有事情都由一个人承担”	贡献者缺席影响因子、维护者倦怠信号	确实存在关键人风险；从未进行过任务委派
“领导层想要价值证明”	主要成果指标，加上一项漏斗指标	社区从未与明确的成果挂钩

如果坦诚的答案是应该将社区整合回更小的空间，就应直言不讳。让一个死气沉沉的社区继续开放，每当新人发帖却得不到回应时，都会损害信任。

调用示例

常见的开场白，以及每种开场白应产出的内容：

• “我们的 CLI 有一个 900 人的 Discord 社区，但我们不知道它是否运作良好。” → 先进行访谈，然后提供一份包含 5–6 项指标的指标表，其中大多数标记为“正在建立基线”，并附上首次读数。
• “我们的 Slack 社区感觉没什么活力，是这样吗？” → 先针对活跃度支柱进行诊断，然后再完成指标表的其余部分。
• “董事会想要证据，证明这个社区值得投入人力。” → 提供主要成果指标、一项漏斗指标，并如实说明哪些数据无法归因。
• “这个开源项目是否足够健康，值得依赖？” → 将入门指标组（首次响应时间、变更请求关闭率、贡献者缺席系数、发布频率）作为趋势来解读，不与其他项目进行比较。

预期输出结构，按顺序排列：

1. 主要成果。
2. 指标表（指标、支柱、公式、来源、基线、阈值、负责人、行动）。
3. 本期相对于基线的读数。
4. 两到三项有证据和置信度支撑的发现。
5. 附有负责人和日期的行动。
6. 观察清单。
7. 下次评审日期。

输出

生成一份社区健康报告。报告结构、完整示例和反面示例：./references/health-report-template.md。

评审频率应根据受众而定：为社区运营者提供每月工作评审，为出资方提供每季度汇总。不要为一个每月才查看一次数据的社区搭建实时仪表板。

通过标准

当指标表在这项检查中得分达到 100% 时，框架才算完成。持续迭代，直至达标。

每项指标都必须具备以下五项：

1. 通俗易懂的定义。
2. 团队今天就能访问的数据来源。
3. 基线值，或明确标记为“正在建立基线”。
4. 会触发关注的阈值。
5. 超出阈值时要执行的指定行动及负责人。

此外：指标最多 8 项，每个支柱至少有一项，并且不能有任何未通过“所以呢”测试的指标。

常见问题

• 把成员数量作为头条指标。 成员总数只会不断增加，无法说明社区是否健康。应报告活跃人数和账号覆盖率。
• 把机器人算作真人。 这会同时夸大响应能力和活跃度。
• 与其他社区进行基准比较。 规模、生态系统和产品各不相同，因此比较毫无意义，还会打击士气。
• 根据文本分类器推断情绪。 开发者对话中充斥着直截了当的错误报告和冷幽默，自动评分会将它们判为愤怒。应直接询问成员。
• 指标变成了目标。 奖励消息数量会催生闲聊，奖励已关闭问题会导致过早关闭。留意指标鼓励的行为，并为任何作为激励依据的指标配套一项质量反向指标。
• 没有负责人的仪表板。 如果没有指定评审负责人，到第三个月时就没人再更新仪表板。解决办法是减少指标，而不是增加自动化。
• 只调查仍然留下的人。 已离开的成员最清楚离开的原因。条件允许时，加入简短的退出调查或针对不活跃成员的问题。
• 公开个人级数据。 排行榜和逐成员活动表会带来隐私风险，并以意料之外的方式改变行为。
• 群组细分得过于狭窄。 按天而不是按月划分加入群组，会导致每组只剩三个人，留存曲线也会显得平缓或极不稳定。应扩大群组时间窗口，直到每组都有足够的人数可供解读，并说明使用了哪个窗口。
• 同一指标有两种计算方法。 一个人将“活跃”定义为发帖或回应，另一个人只按发帖计算，导致两份报告公开出现矛盾。应将公式与数值一并公布，而不是在会议上争论。
• 从未重新审视的阈值。 在项目启动时设定的界限如果一直不变，每个月都会触发警报，最终被忽略，该指标也会悄然无人问津。每次评审时都应根据滚动基线重新推导阈值。

记忆

如果你的工具链支持持久化记忆，请在用户验证后，存储主要结果、最终指标表、基线和阈值。这样，下次审核就能从记录的基线开始，而不必重新推导；阈值的变更也会作为一项决策呈现，而不是被悄悄修改。