活跃度
活跃度用来描述一个开源社区或者项目的活跃程度。
为了使一个开源项目持续发展,必须在首次发布后进行持续的维护和改进。活跃度展示了一个项目随着时间的推移持续展开的工作有多少。高活跃度的社区可能表明该项目是可持续的,低活跃度的社区可能表明该项目面临风险。
评估模型中的指标
贡献者数量
- 定义:过去 90 天中活跃的代码提交者、Pull Request 作者、代码审查者、Issue 作者和 Issue 评论者的数量。
- 权重:18.01%
- 阈值:2000
- 注:当一个人在多个仓库中有多个不同角色的贡献时,例如代码提交者和 Issue 作者,我们只算一次。
在这个模型,我们把代码托管平台对于该项目的所有类型的贡献者全部囊括在内。因为我们认为项目的活跃度是由所有类型的贡献行为构成的,而且活跃贡献者数量越多,越表明项目的重要程度越高。
代码提交频率
- 定义:过去 90 天内平均每周代码提交次数。
- 权重:18.01%
- 阈值:1000
作为这个模型的结果性指标,它标识项目贡献的持续性和数量。指代项目的整体工作量大小。
更新于
- 定义:确定每个代码仓自上次更新以来的平均时间 (月份),即多久没更新了。
- 权重:-12.74%
- 阈值:0.25 个月
这个指标用来指代该项目的更新频率。它标识协作开发指数优秀的社区,会进行高频率的迭代式开发,以此来促进软件质量得到持续的改进。但是软件项目所属行业和领域不同,也决定了它的迭代频率并不是一味得越高越好,例如一些 Linux 发行版项目展现了非常典型的伴随版本规划的周期性的代码迭代规律。这里我们关注得是每个周期内该项目的趋势变化,以及与同类型项目相比较而得到的相对性结果。
组织数量
- 定义:过去 90 天内活跃的代码提交者所属组织的数目
- 权重:11.50%
- 阈值:10
越多的组织参与项目的持续贡献,代表越多的组织深度依赖这个项目。这样会极大几率促使生态的建立和繁荣。
创建于
- 定义:确定代码仓自创建以来存在了多长时间 (月份)。
- 权重:7.77%
- 阈值:120 个月
- 注:它是一个单调递增函数,所以我们考虑删除这个指标。
我们用这个指标来观察这个项目的存活时间,时间越长,表明该项目抵御来自内部或者外部干扰,自我恢复的能力越高。
Issue 评论频率
- 定义:过去 90 天内新建 Issue 的评论平均数(不包含机器人和 Issue 作者本人评论)。
- 权重:7.77%
- 阈值:5
我们希望看到社区鼓励参与者围绕具体的 Bug 或者需求,通过 Issue 的方式进行公开和透明的讨论。这样 Issue 的相应结论也可以做为知识储备积累下来,同时为更多人所能看到。
代码审查评论频率
- 定义:过去 90 天内新建 PR 的评论平均数量(不包含机器人和 PR 作者本人评论)。
- 权重:4.92%
- 阈值:8
我们希望代码审查能够通过 PR review 的方式展示出来,让大家看到社区对于代码质量,安全方面管理的重视程度,同时为新人快速成长提供帮助。
更新 Issue 数量
- 定义:过去 90 天 Issue 更新的数量。
- 权重:4.92%
- 阈值:2500
有两个原因促使我们选择使用 Issue 更新的数量而不是统计关闭或者解决 Issue 的数量。首先,Issue 有很多不同的类型,比如 bug、功能需求、用户咨询和 CVEs。只有特定类型的问题必须很快得到解决,比如 CVEs。对于其余类型的问题, 并不追求 Issue 的快速解决,我们需要与问题创建者进行多次沟通,以更好地了解详细信息。如果是功能需求,从接受到解决,是按照发布计划进行的,这类场景可能也需要几个月的时间。其次,从 Issue 更新的数量来看,我们可以监控 Issue 处理的活跃度。问题更新还可以包括重开问题,表明对问题理解的变化的关注度。
最近版本发布次数
- 定义:过去 12 个月版本发布的数量
- 权重:3.18%
- 阈值:12
高频率的版本发布,表明软件制品在快速迭代,来相应用户的需求。当然软件项目所属行业和领域不同,也决定了它的迭代频率并不是一味得越高越好,例如大型平台类软件项目的发布周期是半年到一年。
维护者数量
- 过去 90 天活跃的维护者数量
- 权重:2.090%
- 阈值:100
- 注:尚未就绪。
一个项目的代码维护者是这个项目代码质量和技术迭代的直接负责人,活跃的维护者预示着项目的高质量维护的可能性越高。
会议数量
- 定义:过去 90 天内举行会议的次数。
- 权重:2.090%
- 阈值:100
- 注:尚未就绪。
与会者数量
- 定义:确定过去 90 天内每次会议的与会者平均人数。
- 权重:2.090%
- 阈值:10
- 注:尚未就绪。
关闭 Issue 数量
- 定义:过去 90 天内关闭 Issue 的数量。
- 权重:4.92%
- 阈值:2500
- 注:它与“更新 Issue 数量”重复,正在考虑从模型中删除。
评估模型算法
权重
我们使用 AHP 来计算每个指标的权重。
AHP 输入数据
指标名称 | 贡献者数量 | 代码提交频率 | 更新于 | 组织数量 | 创建于 | Issue 评论频率 | 代码审查评论频率 | 关闭 Issue 数量 | 更新 Issue 数量 | 最近版本发布次数 | 维护者数量 | 会议数量 | 与会者数量 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
贡献者数量 | 1 | 1 | 2 | 2 | 3 | 3 | 4 | 4 | 4 | 5 | 6 | 6 | 6 |
代码提交频率 | 1 | 1 | 2 | 2 | 3 | 3 | 4 | 4 | 4 | 5 | 6 | 6 | 6 |
更新于 | 0.5 | 0.5 | 1 | 2 | 2 | 2 | 3 | 3 | 3 | 4 | 5 | 5 | 5 |
组织数量 | 0.5 | 0.5 | 0.5 | 1 | 2 | 2 | 3 | 3 | 3 | 4 | 5 | 5 | 5 |
0.333 | 0.333 | 0.5 | 0.5 | 1 | 1 | 2 | 2 | 2 | 3 | 4 | 4 | 4 | |
Issue 评论频率 | 0.333 | 0.333 | 0.5 | 0.5 | 1 | 1 | 2 | 2 | 2 | 3 | 4 | 4 | 4 |
代码审查评论频率 | 0.25 | 0.25 | 0.333 | 0.333 | 0.5 | 0.5 | 1 | 1 | 1 | 2 | 3 | 3 | 3 |
0.25 | 0.25 | 0.333 | 0.333 | 0.5 | 0.5 | 1 | 1 | 1 | 2 | 3 | 3 | 3 | |
更新 Issue 数量 | 0.25 | 0.25 | 0.333 | 0.333 | 0.5 | 0.5 | 1 | 1 | 1 | 2 | 3 | 3 | 3 |
最近版本发布次数 | 0.2 | 0.2 | 0.25 | 0.25 | 0.333 | 0.333 | 0.5 | 0.5 | 0.5 | 1 | 2 | 2 | 2 |
维护者数量 | 0.167 | 0.167 | 0.2 | 0.2 | 0.25 | 0.25 | 0.333 | 0.333 | 0.333 | 0.5 | 1 | 1 | 1 |
会议数量 | 0.167 | 0.167 | 0.2 | 0.2 | 0.25 | 0.25 | 0.333 | 0.333 | 0.333 | 0.5 | 1 | 1 | 1 |
与会者数量 | 0.167 | 0.167 | 0.2 | 0.2 | 0.25 | 0.25 | 0.333 | 0.333 | 0.333 | 0.5 | 1 | 1 | 1 |
AHP 分析结果
指标名称 | 特征向量 | 权重 |
---|---|---|
贡献者数量 | 2.341 | 18.009% |
代码提交频率 | 2.341 | 18.009% |
更新于 | 1.657 | -12.742% |
组织数量 | 1.495 | 11.501% |
1.010 | 7.768% | |
Issue 评论频率 | 1.010 | 7.768% |
代码审查评论频率 | 0.639 | 4.919% |
0.639 | 4.919% | |
更新 Issue 数量 | 0.639 | 4.919% |
最近版本发布次数 | 0.413 | 3.177% |
维护者数量 | 0.272 | 2.090% |
会议数量 | 0.272 | 2.090% |
与会者数量 | 0.272 | 2.090% |
一致性检验结果
最大特征根 | CI 值 | RI 值 | CR 值 | 一致性检验结果 |
---|---|---|---|---|
13.303 | 0.025 | 1.560 | 0.016 | 通过 |
阈值
我们选择的阈值是基于不同类型开源项目的大数据观测。
参考文献
贡献者
前端
- Shengxiang Zhang
- Feng Zhong
- Chaoqun Huang
- Huatian Qin
- Xingyou Lai
后端
- Yehui Wang
- Chenqi Shan
- Shengbao Li
- Huatian Qin
评估模型
- Yehui Wang
- Jun Zhong
- Chenqi Shan
- Matt Germonprez
- Kevin Lumbard
- Vinod Ahuja