如何衡量一个开源社区的健康度

这比较复杂。

作为一个经常管理软件开发团队的人，多年来我一直关注度量指标。一次次，我发现自己领导团队使用一个又一个的项目平台（例如 Jira、GitLab 和 Rally）生成了大量可测量的数据。从那时起，我已经及时投入了大量时间从记录平台中提取了有用的指标，并采用了一种我们可以理解的格式，然后使用这些指标对开发的许多方面做出更好的选择。

今年早些时候，我有幸在 Linux 基金会遇到了一个名为开源软件社区健康分析Community Health Analytics for Open Source Software（CHAOSS）的项目。该项目侧重于从各种来源收集和丰富指标，以便开源社区的利益相关者可以衡量他们项目的健康状况。

CHAOSS 介绍

随着我对该项目的基本指标和目标越来越熟悉，一个问题在我的脑海中不断翻滚。什么是“健康”的开源项目，由谁来定义？

特定角色的人认为健康的东西可能另一个角色的人就不会这样认为。似乎可以用 CHAOSS 收集的细粒度数据进行市场细分实验，重点关注对特定角色可能最有意义的背景问题，以及 CHAOSS 收集哪些指标可能有助于回答这些问题。

CHAOSS 项目创建并维护了一套开源应用程序和度量标准定义，使得这个实验具有可能性，这包括：

• 许多基于服务器的应用程序，用于收集、聚合和丰富度量标准（例如 Augur 和 GrimoireLab）。
• ElasticSearch、Kibana 和 Logstash（ELK）的开源版本。
• 身份服务、数据分析服务和各种集成库。

在我过去的一个程序中，有六个团队从事于不同复杂程度的项目，我们找到了一个简洁的工具，它允许我们从简单（或复杂）的 JQL 语句中创建我们想要的任何类型的指标，然后针对这些指标开发计算。在我们注意到之前，我们仅从 Jira 中就提取了 400 多个指标，而且还有更多指标来自手动的来源。

在项目结束时，我们认定这 400 个指标中，大多数指标在以我们的角色做出决策时并不重要。最终，只有三个对我们非常重要：“缺陷去除效率”、“已完成的条目与承诺的条目”，以及“每个开发人员的工作进度”。这三个指标最重要，因为它们是我们对自己、客户和团队成员所做出的承诺，因此是最有意义的。

带着这些通过经验得到的教训和对什么是健康的开源项目的问题，我跳进了 CHAOSS 社区，开始建立一套角色，以提供一种建设性的方法，从基于角色的角度回答这个问题。

CHAOSS 是一个开源项目，我们尝试使用民主共识来运作。因此，我决定使用组成分子constituent这个词而不是利益相关者，因为它更符合我们作为开源贡献者的责任，以创建更具共生性的价值链。

虽然创建此组成模型的过程采用了特定的“目标-问题-度量”方法，但有许多方法可以进行细分。CHAOSS 贡献者已经开发了很好的模型，可以按照矢量进行细分，例如项目属性（例如，个人、公司或联盟）和“失败容忍度”。在为 CHAOSS 开发度量定义时，每个模型都会提供建设性的影响。

基于这一切，我开始构建一个谁可能关心 CHAOSS 指标的模型，以及每个组成分子在 CHAOSS 的四个重点领域中最关心的问题：

• 多样性和包容性
• 演化
• 风险
• 价值

在我们深入研究之前，重要的是要注意 CHAOSS 项目明确地将背景判断留给了实施指标的团队。什么是“有意义的”和“什么是健康的？”的答案预计会因团队和项目而异。CHAOSS 软件的现成仪表板尽可能地关注客观指标。在本文中，我们关注项目创始人、项目维护者和贡献者。

项目组成分子

虽然这绝不是这些组成分子可能认为重要的问题的详尽清单，但这些选择感觉是一个好的起点。以下每个“目标-问题-度量”标准部分与 CHAOSS 项目正在收集和汇总的指标直接相关。

现在，进入分析的第 1 部分！

项目创始人

作为项目创始人，我最关心：

• 我的项目对其他人有用吗？通过以下测量：
  • 随着时间推移有多少复刻？
    • 指标：存储库复刻数。
  • 随着时间的推移有多少贡献者？
    • 指标：贡献者数量。
  • 贡献净质量。
    • 指标：随着时间的推移提交的错误。
    • 指标：随着时间的回归。
  • 项目的财务状况。
    • 指标：随着时间的推移的捐赠/收入。
    • 指标：随着时间的推移的费用。
• 我的项目对其它人的可见程度？
  • 有谁知道我的项目？别人认为它很整洁吗？
    • 指标：社交媒体上的提及、分享、喜欢和订阅的数量。
  • 有影响力的人是否了解我的项目？
    • 指标：贡献者的社会影响力。
  • 人们在公共场所对项目有何评价？是正面还是负面？
    • 指标：跨社交媒体渠道的情感（关键字或 NLP）分析。
• 我的项目可行性程度？
  • 我们有足够的维护者吗？该数字是随着时间的推移而上升还是下降？
    • 指标：维护者数量。
  • 改变速度如何随时间变化？
    • 指标：代码随时间的变化百分比。
    • 指标：拉取请求、代码审查和合并之间的时间。
• 我的项目的多样化 ＆ 包容性如何？
  • 我们是否拥有有效的公开行为准则（CoC）？
    • 度量标准： 检查存储库中的 CoC 文件。
  • 与我的项目相关的活动是否积极包容？
    • 指标：关于活动的票务政策和活动包容性行为的手动报告。
  • 我们的项目在可访问性上做的好不好？
    • 指标：验证发布的文字会议纪要。
    • 指标：验证会议期间使用的隐藏式字幕。
    • 指标：验证在演示文稿和项目前端设计中色盲可访问的素材。
• 我的项目代表了多少价值？
  • 我如何帮助组织了解使用我们的项目将节省多少时间和金钱（劳动力投资）
    • 指标：仓库的议题、提交、拉取请求的数量和估计人工费率。
  • 我如何理解项目创建的下游价值的数量，以及维护我的项目对更广泛的社区的重要性（或不重要）？
    • 指标：依赖我的项目的其他项目数。
  • 为我的项目做出贡献的人有多少机会使用他们学到的东西来找到合适的工作岗位，以及在哪些组织（即生活工资）？
    • 指标：使用或贡献此库的组织数量。
    • 指标：使用此类项目的开发人员的平均工资。
    • 指标：与该项目匹配的关键字的职位发布计数。

项目维护者

作为项目维护者，我最关心：

• 我是高效的维护者吗？
  • 指标：拉取请求在代码审查之前等待的时间。
  • 指标：代码审查和后续拉取请求之间的时间。
  • 指标：我的代码审核中有多少被批准？
  • 指标：我的代码评论中有多少被拒绝或返工？
  • 指标：代码审查的评论的情感分析。
• 我如何让更多人帮助我维护这件事？
  • 指标：项目贡献者的社交覆盖面数量。
• 我们的代码质量随着时间的推移变得越来越好吗？
  • 指标：计算随着时间的推移引入的回归数量。
  • 指标：计算随着时间推移引入的错误数量。
  • 指标：错误归档、拉取请求、代码审查、合并和发布之间的时间。

项目开发者和贡献者

作为项目开发者或贡献者，我最关心：

• 我可以从为这个项目做出贡献中获得哪些有价值的东西，以及实现这个价值需要多长时间？
  • 指标：下游价值。
  • 指标：提交、代码审查和合并之间的时间。
• 通过使用我在贡献中学到的东西来增加工作机是否有良好的前景？
  • 指标：生活工资。
• 这个项目有多受欢迎？
  • 指标：社交媒体帖子、分享和收藏的数量。
• 社区有影响力的人知道我的项目吗？
  • 指标：创始人、维护者和贡献者的社交范围。

通过创建这个列表，我们开始让 CHAOSS 更加丰满了，并且在今年夏天项目中首次发布该指标时，我迫不及待地想看看广泛的开源社区可能有什么其他伟大的想法，以及我们还可以从这些贡献中学到什么（并衡量！）。

其它角色

接下来，你需要了解有关其他角色（例如基金会、企业开源计划办公室、业务风险和法律团队、人力资源等）以及最终用户的目标问题度量集的更多信息。他们关心开源的不同事物。

如果你是开源贡献者或组成分子，我们邀请你来看看这个项目并参与社区活动！

via: https://opensource.com/article/19/8/measure-project

作者：Jon Lawrence 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出