mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
TSL
This commit is contained in:
Xingyu Wang
parent
64d619f0b5
commit
d4fe6de5bc
@ -1,202 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to measure the health of an open source community)
|
||||
[#]: via: (https://opensource.com/article/19/8/measure-project)
|
||||
[#]: author: (Jon Lawrence https://opensource.com/users/the3rdlaw)
|
||||
|
||||
How to measure the health of an open source community
|
||||
======
|
||||
It's complicated.
|
||||
![metrics and data shown on a computer screen][1]
|
||||
|
||||
As a person who normally manages software development teams, over the years I’ve come to care about metrics quite a bit. Time after time, I’ve found myself leading teams using one project platform or another (Jira, GitLab, and Rally, for example) generating an awful lot of measurable data. From there, I’ve promptly invested significant amounts of time to pull useful metrics out of the platform-of-record and into a format where we could make sense of them, and then use the metrics to make better choices about many aspects of development.
|
||||
|
||||
Earlier this year, I had the good fortune of coming across a project at the [Linux Foundation][2] called [Community Health Analytics for Open Source Software][3], or CHAOSS. This project focuses on collecting and enriching metrics from a wide range of sources so that stakeholders in open source communities can measure the health of their projects.
|
||||
|
||||
### What is CHAOSS?
|
||||
|
||||
As I grew familiar with the project’s underlying metrics and objectives, one question kept turning over in my head. What is a "healthy" open source project, and by whose definition?
|
||||
|
||||
What’s considered healthy by someone in a particular role may not be viewed that way by someone in another role. It seemed there was an opportunity to back out from the granular data that CHAOSS collects and do a market segmentation exercise, focusing on what might be the most meaningful contextual questions for a given role, and what metrics CHAOSS collects that might help answer those questions.
|
||||
|
||||
This exercise was made possible by the fact that the CHAOSS project creates and maintains a suite of open source applications and metric definitions, including:
|
||||
|
||||
* A number of server-based applications for gathering, aggregating, and enriching metrics (such as Augur and GrimoireLab).
|
||||
* The open source versions of ElasticSearch, Kibana, and Logstash (ELK).
|
||||
* Identity services, data analysis services, and a wide range of integration libraries.
|
||||
|
||||
|
||||
|
||||
In one of my past programs, where half a dozen teams were working on projects of varying complexity, we found a neat tool which allowed us to create any kind of metric we wanted from a simple (or complex) JQL statement, and then develop calculations against and between those metrics. Before we knew it, we were pulling over 400 metrics from Jira alone, and more from manual sources.
|
||||
|
||||
By the end of the project, we decided that out of the 400-ish metrics, most of them didn’t really matter when it came to making decisions _in our roles_. At the end of the day, there were only three that really mattered to us: "Defect Removal Efficiency," "Points completed vs. Points committed," and "Work-in-Progress per Developer." Those three metrics mattered most because they were promises we made to ourselves, to our clients, and to our team members, and were, therefore, the most meaningful.
|
||||
|
||||
Drawing from the lessons learned through that experience and the question of what is a healthy open source project?, I jumped into the CHAOSS community and started building a set of personas to offer a constructive approach to answering that question from a role-based lens.
|
||||
|
||||
CHAOSS is an open source project and we try to operate using democratic consensus. So, I decided that instead of stakeholders, I’d use the word _constituent_, because it aligns better with the responsibility we have as open source contributors to create a more symbiotic value chain.
|
||||
|
||||
While the exercise of creating this constituent model takes a particular goal-question-metric approach, there are many ways to segment. CHAOSS contributors have developed great models that segment by vectors, like project profiles (for example, individual, corporate, or coalition) and "Tolerance to Failure." Every model provides constructive influence when developing metric definitions for CHAOSS.
|
||||
|
||||
Based on all of this, I set out to build a model of who might care about CHAOSS metrics, and what questions each constituent might care about most in each of CHAOSS’ four focus areas:
|
||||
|
||||
* [Diversity and Inclusion][4]
|
||||
* [Evolution][5]
|
||||
* [Risk][6]
|
||||
* [Value][7]
|
||||
|
||||
|
||||
|
||||
Before we dive in, it’s important to note that the CHAOSS project expressly leaves contextual judgments to teams implementing the metrics. What’s "meaningful" and the answer to "What is healthy?" is expected to vary by team and by project. The CHAOSS software’s ready-made dashboards focus on objective metrics as much as possible. In this article, we focus on project founders, project maintainers, and contributors.
|
||||
|
||||
### Project constituents
|
||||
|
||||
While this is by no means an exhaustive list of questions these constituents might feel are important, these choices felt like a good place to start. Each of the Goal-Question-Metric segments below is directly tied to metrics that the CHAOSS project is collecting and aggregating.
|
||||
|
||||
Now, on to Part 1 of the analysis!
|
||||
|
||||
#### Project founders
|
||||
|
||||
As a **project founder**, I care **most** about:
|
||||
|
||||
* Is my project **useful to others?** Measured as a function of:
|
||||
|
||||
* How many forks over time?
|
||||
**Metric:** Repository forks.
|
||||
|
||||
* How many contributors over time?
|
||||
**Metric:** Contributor count.
|
||||
|
||||
* Net quality of contributions.
|
||||
**Metric:** Bugs filed over time.
|
||||
**Metric:** Regressions over time.
|
||||
|
||||
* Financial health of my project.
|
||||
**Metric:** Donations/Revenue over time.
|
||||
**Metric:** Expenses over time.
|
||||
|
||||
* How **visible** is my project to others?
|
||||
|
||||
* Does anyone know about my project? Do others think it’s neat?
|
||||
**Metric:** Social media mentions, shares, likes, and subscriptions.
|
||||
|
||||
* Does anyone with influence know about my project?
|
||||
**Metric:** Social reach of contributors.
|
||||
|
||||
* What are people saying about the project in public spaces? Is it positive or negative?
|
||||
**Metric:** Sentiment (keyword or NLP) analysis across social media channels.
|
||||
|
||||
* How **viable** is my project?
|
||||
|
||||
* Do we have enough maintainers? Is the number rising or falling over time?
|
||||
**Metric:** Number of maintainers.
|
||||
|
||||
* Do we have enough contributors? Is the number rising or falling over time?
|
||||
**Metric:** Number of contributors.
|
||||
|
||||
* How is velocity changing over time?
|
||||
**Metric:** Percent change of code over time.
|
||||
**Metric:** Time between pull request, code review, and merge.
|
||||
|
||||
* How [**diverse & inclusive**][4] is my project?
|
||||
|
||||
* Do we have a valid, public, Code of Conduct (CoC)?
|
||||
**Metric:** CoC repository file check.
|
||||
|
||||
* Are events associated with my project actively inclusive?
|
||||
**Metric:** Manual reporting on event ticketing policies and event inclusion activities.
|
||||
|
||||
* Does our project do a good job of being accessible?
|
||||
**Metric:** Validation of typed meeting minutes being posted.
|
||||
**Metric:** Validation of closed captioning used during meetings.
|
||||
**Metric:** Validation of color-blind-accessible materials in presentations and in project front-end designs.
|
||||
|
||||
* How much [**value**][7] does my project represent?
|
||||
|
||||
* How can I help organizations understand how much time and money using our project would save them (labor investment)
|
||||
**Metric:** Repo count of issues, commits, pull requests, and the estimated labor rate.
|
||||
|
||||
* How can I understand the amount of downstream value my project creates and how vital (or not) it is to the wider community to maintain my project?
|
||||
**Metric:** Repo count of how many other projects rely on my project.
|
||||
|
||||
* How much opportunity is there for those contributing to my project to use what they learn working on it to land good jobs and at what organizations (aka living wage)?
|
||||
**Metric:** Count of organizations using or contributing to this library.
|
||||
**Metric:** Averages of salaries for developers working with this kind of project.
|
||||
**Metric:** Count of job postings with keywords that match this project.
|
||||
|
||||
|
||||
|
||||
|
||||
### Project maintainers
|
||||
|
||||
As a **Project Maintainer,** I care **most** about:
|
||||
|
||||
* Am I an **efficient** maintainer?
|
||||
**Metric:** Time PR’s wait before a code review.
|
||||
**Metric:** Time between code review and subsequent PR’s.
|
||||
**Metric:** How many of my code reviews are approvals?
|
||||
**Metric:** How many of my code reviews are rejections/rework requests?
|
||||
**Metric:** Sentiment analysis of code review comments.
|
||||
|
||||
* How do I get **more people** to help me maintain this thing?
|
||||
**Metric:** Count of social reach of project contributors.
|
||||
|
||||
* Is our **code quality** getting better or worse over time?
|
||||
**Metric:** Count how many regressions are being introduced over time.
|
||||
**Metric:** Count how many bugs are being introduced over time.
|
||||
**Metric:** Time between bug filing, pull request, review, merge, and release.
|
||||
|
||||
|
||||
|
||||
|
||||
### Project developers and contributors
|
||||
|
||||
As a **project developer or contributor**, I care most about:
|
||||
|
||||
* What things of value can I gain from contributing to this project and how long might it take to realize that value?
|
||||
**Metric:** Downstream value.
|
||||
**Metric:** Time between commits, code reviews, and merges.
|
||||
|
||||
* Are there good prospects for using what I learn by contributing to increase my job opportunities?
|
||||
**Metric:** Living wage.
|
||||
|
||||
* How popular is this project?
|
||||
**Metric:** Counts of social media posts, shares, and favorites.
|
||||
|
||||
* Do community influencers know about my project?
|
||||
**Metric:** Social reach of founders, maintainers, and contributors.
|
||||
|
||||
|
||||
|
||||
|
||||
By creating this list, we’ve just begun to put meat on the contextual bones of CHAOSS, and with the first release of metrics in the project this summer, I can’t wait to see what other great ideas the broader open source community may have to contribute and what else we can all learn (and measure!) from those contributions.
|
||||
|
||||
### Other roles
|
||||
|
||||
Next, you need to learn more about goal-question-metric sets for other roles (such as foundations, corporate open source program offices, business risk and legal teams, human resources, and others) as well as end users, who have a distinctly different set of things they care about when it comes to open source.
|
||||
|
||||
If you’re an open source contributor or constituent, we invite you to [come check out the project][8] and get engaged in the community!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/8/measure-project
|
||||
|
||||
作者：[Jon Lawrence][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/the3rdlaw
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/metrics_data_dashboard_system_computer_analytics.png?itok=oxAeIEI- (metrics and data shown on a computer screen)
|
||||
[2]: https://www.linuxfoundation.org/
|
||||
[3]: https://chaoss.community/
|
||||
[4]: https://github.com/chaoss/wg-diversity-inclusion
|
||||
[5]: https://github.com/chaoss/wg-evolution
|
||||
[6]: https://github.com/chaoss/wg-risk
|
||||
[7]: https://github.com/chaoss/wg-value
|
||||
[8]: https://github.com/chaoss/
|
||||
@ -0,0 +1,164 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to measure the health of an open source community)
|
||||
[#]: via: (https://opensource.com/article/19/8/measure-project)
|
||||
[#]: author: (Jon Lawrence https://opensource.com/users/the3rdlaw)
|
||||
|
||||
如何衡量一个开源社区的健康度
|
||||
======
|
||||
|
||||
> 这比较复杂。
|
||||
|
||||
![metrics and data shown on a computer screen][1]
|
||||
|
||||
作为一个经常管理软件开发团队的人，多年来我一直关注度量指标。一次又一次，我发现自己领导团队使用一个又一个的项目平台（例如 Jira、GitLab 和 Rally）生成了大量可测量的数据。从那时起，我已经及时投入了大量时间从记录平台中提取有用的指标，并采用我们可以理解它们的格式，然后使用这些指标对开发的许多方面做出更好的选择。
|
||||
|
||||
今年早些时候，我有幸遇到了 [Linux 基金会][2]的一个名为<ruby>[开源软件社区健康分析][3]<rt>Community Health Analytics for Open Source Software</rt></ruby>（CHAOSS）的项目。该项目侧重于从各种来源收集和丰富指标，以便开源社区的利益相关者可以衡量他们项目的健康状况。
|
||||
|
||||
### CHAOSS 介绍
|
||||
|
||||
随着我对该项目的基本指标和目标越来越熟悉，一个问题在我的脑海中不断翻滚。什么是“健康”的开源项目，由谁来定义？
|
||||
|
||||
特定角色的人认为健康的东西可能另一个角色的人就不会这样认为。似乎有机会拿到 CHAOSS 收集的细粒度数据并进行市场细分实验，重点关注对特定角色可能最有意义的背景问题，以及 CHAOSS 收集哪些指标可能有助于回答这些问题。
|
||||
|
||||
使得这个实验具有可能性的是，CHAOSS 项目创建并维护了一套开源应用程序和度量标准定义，包括：
|
||||
|
||||
* 许多基于服务器的应用程序，用于收集、聚合和丰富度量标准（例如 Augur 和 GrimoireLab）。
|
||||
* ElasticSearch、Kibana 和 Logstash（ELK）的开源版本。
|
||||
* 身份服务、数据分析服务和各种集成库。
|
||||
|
||||
在我过去的一个程序中，有六个团队从事于不同复杂程度的项目，我们找到了一个简洁的工具，它允许我们从简单（或复杂）的 JQL 语句中创建我们想要的任何类型的度量，然后针对这些指标开发计算。在我们知道它之前，我们仅从 Jira 中就提取了400多个指标，而且还有更多指标来自手动来源。
|
||||
|
||||
在项目结束时，我们认定这 400 个指标中，大多数指标在*以我们的角色*做出决策时并不重要。最终，只有三个对我们非常重要：“缺陷去除效率”、“已完成点数与已提交点数”，以及“每个开发人员的工作进度”。这三个指标最重要，因为它们是我们对自己、客户和团队成员所做出的承诺，因此是最有意义的。
|
||||
|
||||
带着这些通过经验得到的教训和对什么是健康的开源项目的问题，我跳进了 CHAOSS 社区，开始建立一套角色，以提供一种建设性的方法，从基于角色的角度回答这个问题。
|
||||
|
||||
CHAOSS 是一个开源项目，我们尝试使用民主共识来运作。因此，我决定使用*组成分子*这个词而不是利益相关者，因为它更符合我们作为开源贡献者的责任，以创建更具共生性的价值链。
|
||||
|
||||
虽然创建此组成模型的过程采用了特定的目标-问题-度量方法，但有许多方法可以进行细分。CHAOSS 贡献者已经开发了很好的模型，可以按照矢量进行细分，例如项目属性（例如，个人、公司或联盟）和“容忍失败”。在为 CHAOSS 开发度量定义时，每个模型都会提供建设性的影响。
|
||||
|
||||
基于这一切，我开始构建一个可能关心 CHAOSS 指标的模型，以及每个组成分子在 CHAOSS 的四个重点领域中最关心的问题：
|
||||
|
||||
* [多样性和包容性][4]
|
||||
* [进化][5]
|
||||
* [风险][6]
|
||||
* [价值][7]
|
||||
|
||||
在我们深入研究之前，重要的是要注意 CHAOSS 项目明确地给实施指标的团队留下了背景判断。什么是“有意义的”和“什么是健康的？”的答案预计会因团队和项目而异。CHAOSS 软件的现成仪表板尽可能地关注客观指标。在本文中，我们关注项目创始人、项目维护者和贡献者。
|
||||
|
||||
### 项目组成分子
|
||||
|
||||
虽然这绝不是这些组成分子可能认为重要的问题的详尽清单，但这些选择感觉是一个好的起点。以下每个目标-问题-度量标准部分与 CHAOSS 项目正在收集和汇总的指标直接相关。
|
||||
|
||||
现在，进入分析的第 1 部分！
|
||||
|
||||
#### 项目创始人
|
||||
|
||||
作为**项目创始人**，我**最**关心：
|
||||
|
||||
* 我的项目**对其他人有用吗？**作为以下函数测量：
|
||||
* 随着时间推移有多少复刻？
|
||||
* **指标：**存储库复刻数。
|
||||
* 随着时间的推移有多少贡献者？
|
||||
* **指标：**贡献者数量。
|
||||
* 贡献净质量。
|
||||
* **指标：**随着时间的推移提交的错误。
|
||||
* **指标：**随时间的回归。
|
||||
* 项目的财务状况。
|
||||
* **指标：**随着时间的推移的捐赠/收入。
|
||||
* **指标：**随着时间的推移的费用。
|
||||
* 我的项目对其它人的**可见**程度？
|
||||
* 有谁知道我的项目？别人认为它很整洁吗？
|
||||
* **指标：**社交媒体上的提及、分享、喜欢和订阅的数量。
|
||||
* 有影响力的人是否了解我的项目？
|
||||
* **指标：**贡献者的社交范围。
|
||||
* 人们在公共场所对项目有何评价？是正面还是负面？
|
||||
* **指标：**跨社交媒体渠道的情感（关键字或 NLP）分析。
|
||||
* 我的项目**可行**程度？
|
||||
* 我们有足够的维护者吗？该数字是随着时间的推移而上升还是下降？
|
||||
* **指标：**维护者数量。
|
||||
* 改变速度如何随时间变化？
|
||||
* **指标：**代码随时间的变化百分比。
|
||||
* **指标：**拉取请求、代码审查和合并之间的时间。
|
||||
* 我的项目的[多样化 ＆ 包容性][4]如何？
|
||||
* 我们是否拥有有效的公开行为准则（CoC）？
|
||||
* **度量标准：** 检查存储库中的 CoC 文件。
|
||||
* 与我的项目相关的活动是否积极包容？
|
||||
* **指标：**关于活动的票务政策和活动包容性活动的手动报告。
|
||||
* 我们的项目在可访问性上做的如好不好？
|
||||
* **指标：**验证发布的文字会议纪要。
|
||||
* **指标：**验证会议期间使用的隐藏式字幕。
|
||||
* **指标：**验证在演示文稿和项目前端设计中色盲可访问的素材。
|
||||
* 我的项目代表了多少[价值][7]？
|
||||
* 我如何帮助组织了解使用我们的项目将节省多少时间和金钱（劳动力投资）
|
||||
* **指标：**仓库的议题书、提交书、拉取请求书和估计人工费率。
|
||||
* 我如何理解项目创建的下游价值的数量以及维护我的项目对更广泛的社区的重要性（或不重要）？
|
||||
* **指标：**依赖我的项目的其他项目数。
|
||||
* 为我的项目做出贡献的人有多少机会使用他们学到的东西来找到合适的工作岗位以及在哪些组织（即生活工资）？
|
||||
* **指标：**使用或贡献此库的组织数量。
|
||||
* **指标：**使用此类项目的开发人员的平均工资。
|
||||
* **指标：**与该项目匹配的关键字的职位发布计数。
|
||||
|
||||
### 项目维护者
|
||||
|
||||
作为**项目维护者**，我**最**关心：
|
||||
|
||||
* 我是**高效的**维护者吗？
|
||||
* **指标：**拉取请求在代码审查之前等待的时间。
|
||||
* **指标：**代码审查和后续拉取请求之间的时间。
|
||||
* **指标：**我的代码审核中有多少被批准？
|
||||
* **指标：**我的代码评论中有多少被拒绝或返工？
|
||||
* **指标：**代码审查的评论的情感分析。
|
||||
* 我如何让**更多人**帮助我维护这件事？
|
||||
* **指标：**项目贡献者的社交覆盖面数。
|
||||
* 我们的**代码质量**随着时间的推移变得越来越好吗？
|
||||
* **指标：**计算随着时间的推移引入的回归数量。
|
||||
* **指标：**计算随着时间推移引入的错误数量。
|
||||
* **指标：**错误归档、拉取请求、代码审查、合并和发布之间的时间。
|
||||
|
||||
### 项目开发者和贡献者
|
||||
|
||||
作为**项目开发者或贡献者**，我**最**关心：
|
||||
|
||||
* 我可以从为这个项目做出贡献中获得哪些有价值的东西，以及实现这个价值需要多长时间？
|
||||
* **指标：**下游价值。
|
||||
* **指标：**提交、代码审查和合并之间的时间。
|
||||
* 通过使用我在贡献中学到的东西来增加工作机是否有良好的前景？
|
||||
* **指标：**生活工资。
|
||||
* 这个项目有多受欢迎？
|
||||
* **指标：**社交媒体帖子、分享和收藏的数量。
|
||||
* 社区有影响力的人知道我的项目吗？
|
||||
* **指标：**创始人、维护者和贡献者的社交范围。
|
||||
|
||||
通过创建这个列表，我们刚刚开始对 CHAOSS 的上下文进行抨击，并且在今年夏天项目中首次发布该指标时，我迫不及待地想看看广泛的开源社区可能有什么其他伟大的想法，以及我们还可以从这些贡献中学到什么（并衡量！）。
|
||||
|
||||
### 其它角色
|
||||
|
||||
接下来，你需要了解有关其他角色（例如基金会、企业开源计划办公室、业务风险和法律团队、人力资源等）以及最终用户的目标问题度量集的更多信息。他们关心开源的不同事物。
|
||||
|
||||
如果你是开源贡献者或组成分子，我们邀请你[来看看这个项目][8]并参与社区活动！
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/8/measure-project
|
||||
|
||||
作者：[Jon Lawrence][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/the3rdlaw
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/metrics_data_dashboard_system_computer_analytics.png?itok=oxAeIEI- (metrics and data shown on a computer screen)
|
||||
[2]: https://www.linuxfoundation.org/
|
||||
[3]: https://chaoss.community/
|
||||
[4]: https://github.com/chaoss/wg-diversity-inclusion
|
||||
[5]: https://github.com/chaoss/wg-evolution
|
||||
[6]: https://github.com/chaoss/wg-risk
|
||||
[7]: https://github.com/chaoss/wg-value
|
||||
[8]: https://github.com/chaoss/
|
||||
Loading…
Reference in New Issue
Block a user