
衡量开源项目健康状况
我知道获得一些大的数字并庆祝您的项目达到第一百甚至第一千个星标或 Fork 可能会令人兴奋。虽然受欢迎程度的衡量标准可能有趣且令人兴奋,但它们通常不会提供对项目健康状况的任何真正见解,也不会指出您项目的改进领域。因此,尽情庆祝这些里程碑,但不要陷入认为它们表明您的项目有任何意义的陷阱。
更好的方法是关注项目健康状况,而不是受欢迎程度。项目健康指标可以帮助我们了解项目的哪些特定方面是健康的。如果它们不健康,我们可以进行改进,然后衡量这些改进的影响,以确保它们产生了我们期望的效果,如果不是,我们可以尝试其他方法。同样重要的是,项目健康指标还有助于指示您不需要进行更改的地方。如果您项目的某些领域已经健康且运行良好,那么您最好专注于其他可以改进的领域。
衡量项目健康状况以及一般指标最困难的事情之一是,您可以查看如此多的不同指标,以至于很多人会感到不知所措。为了帮助人们克服这个障碍,我创建了一个初学者项目健康指标模型,其中包含四个简单的指标。该模型及其包含的指标在CHAOSS中定义,这是一个专注于在全球范围内了解开源社区健康状况的开源项目。该指标模型为人们提供了一个起点,他们可以随着时间的推移在此基础上构建。
贡献者数据

此指标通常称为巴士系数或彩票系数,其基于这样的想法:如果一个人中彩票后消失了,您的项目可能不再继续保持健康和可行。此图表可以告诉您几件事。首先,您当前的贡献者情况有多严重?如果一个人做出了大部分贡献,您应该专注于如何分散负载并让更多人参与到项目中。其次,您可能还会发现有些人贡献比您意识到的要多,这也是这个指标有用的另一个原因。这可以帮助您思考可以鼓励谁做出更多贡献,或者可能找到可以担任领导角色的人。联系某人并承认他们的工作,同时鼓励他们做更多的事情,可以帮助您招募更多可以在您的项目中承担更多责任的人。
“项目健康指标绝不应该用来惩罚人,相反,它们应该用来帮助团队进行改进并尽可能健康。”
关于领导角色,您可能会查看那个贡献了百分之十提交的人,并决定他们已准备好成为维护者。提交次数在百分之五到百分之六左右的人可能是导师或成为审阅者的好人选,目的是在他们获得更多经验后让他们成为维护者。
这里的关键以及许多指标的关键是,我们不想只考虑做出代码贡献的人。这是一个好的开始,但您还应该考虑如何将人们提升到领导职位,负责可能不会在 GitHub 或 GitLab 中显示的事情,例如文档、社区管理、营销和其他重要角色。
响应性

对于项目来说,及时响应拉取请求非常重要,因为快速响应可以帮助您留住贡献者,否则如果他们没有及时收到响应,可能会感到沮丧。对贡献者做出及时、周到和友善的响应表明您感谢他们的工作。

虽然快速响应很重要,但跟上变更请求(拉取请求/合并请求)并及时解决它们也很重要,即使响应是关闭将不会合并的请求。很容易积压未处理的贡献,我们有时都会积压,但是不及时处理这些贡献会产生技术债务,并降低它们最终被合并的可能性,因为较旧的变更请求很可能存在太多合并冲突,变得太难接受。
在这两个响应性指标中,重要的是关注趋势。如果响应性已经提高,请继续保持良好的工作。但是,如果您看到响应性下降,那么可能是时候寻找改进方法了,包括为您的项目招募更多贡献者和维护者——可能来自前面讨论的贡献者数据。
发布

最后,重要的是查看发布频率,包括所有版本,即使是很小的点版本。安全更新和错误修复及时发布至关重要,新功能也及时发布也很重要。项目的适当发布频率受项目规模以及您对其他正在发布修复程序的项目的依赖程度的影响。
衡量和使用项目健康数据的注意事项
在查看项目健康状况时,重要的是要记住,每个项目都略有不同,因此请务必根据项目的需求解释指标。项目健康指标绝不应该用来惩罚人,相反,它们应该用来帮助团队进行改进并尽可能健康。请记住,数据和指标仪表板不会是完美的;您会发现不一致和不准确之处,因此您始终需要根据您对项目的了解应用一些常识和现实过滤器。此外,重要的是要考虑项目中和周围发生的所有各种类型的贡献,这些贡献发生在存储库之外,可能不会反映在指标中。请记住,许多指标中都包含实际的人,因此同意以及对数据和结果的道德处理是重要的考虑因素。
总而言之,每个项目都略有不同,因此初学者项目健康指标模型(以及大多数其他指标)中的指标应如何解释将因项目的大小、成熟度以及许多其他因素而异。始终记住,没有哪个指标是完美的,但是如果某些东西看起来不合适,则可能值得调查。
注意:所有内部图像均来自 CHAOSS 项目,并在我们的 repo 中以 MIT 许可证发布:https://github.com/chaoss/wg-metrics-models/blob/main/LICENSE
封面照片由 patricia serna 拍摄于 Unsplash
2 条评论
评论已关闭。