通过持续的追踪项目，帮助社区运营人员作出最佳决策，从而让开源项目迈向成功。
Section 1 为何要度量所有?
数据，只有在花心思去运用它的时候，才能发挥出其该有的功效。所以，作为一名开源项目的维护者，要去有效的利用数据来助自己一臂之力。
当开源社区和项目运行了一段时间之后，就可获取到一些有用的信息，有了这些数据就可以做很多事，比如：
尝试理解用户对一个新开发的功能是如何反应的？
- 搞清楚新用户是从哪里来的
- 鉴别，并且决定是否支持一个跑偏的使用场景或者功能
- 量化开源项目的流行程度
- 项目是如何被人们使用的
- 通过赞助商或接受赞赏来挣点小钱
举个例子，Homebrew 利用谷歌数据来进行分析，从而帮助他们对工作进行了优先级的区分：
Homebrew 是免费的，完全由志愿者在业余时间维护。所以，我们没有资源去做详细的 Hemobrew 用户调查，从而决定如何更好的设计未来的新功能以及对当前的工作分出优先级。匿名的聚合用户数据分析让我们基于用户如何，何地，何时使用 Homebrew 来优先考虑某些补丁和功能。
流行程度并不能代表一切。每个人都是因为不同的原因参与到开源项目中来，如果你做项目维护者的原因是展示你的工作成果，公开你的代码，又或者只是为了好玩，那么度量标准可能对你来说就不是那么的重要。
如果你想对自己的项目有一个深层次的了解，那么请继续阅读下文所介绍的分析项目活跃度的方法。
Section 2 发现项目
在有人能够使用或者回馈你的项目之前，他们得知道是否有这样的项目存在，问问你自己：人们都在寻找这样项目吗？
如果你的项目是托管在 GitHub 上的话， 你可以访问 获取诸如多少人访问过你的项目，他们从哪里得知的之类的信息。在你的项目主页，点击”Graphs”, 然后再点击”Traffic”。在这个页面，可以看到:
总浏览量: 项目共被浏览了多少次
总独立访问者: 有多少人浏览了项目
关联网站: 访问者从哪里来的。这个数据能帮助你搞清楚哪里可以接触到你的受众，以及你为推广做出的努力是不是有效的。
受欢迎的内容: 访问者都查看了你项目的那些内容，按照页面访问量和独立访客数。
GitHub stars 可以提供一个基本的衡量流行度的标准。然而GitHub 点赞数并不和下载量、使用量直接挂钩，但是它可以告诉我们有多少人正在关注你的项目。
你也许想要在特定的地方跟踪可发现的内容: 举个例子，Google PageRank，会跟踪来自你项目网站的流量，或者跟踪来自其他开源项目或者网站的流量。
Section 3 使用项目
人们在这个广袤而且疯狂的我们称之为互联网的地方，竟然找到了你的项目，这是太”幸运”了。理想情况下，当他们看到你的项目的时候，他们会情不自禁的做点什么。那么，第二个问题你要问自己的是：人们在使用你的项目吗？
如果你使用一个包管理器，比如说 npm 或者 RubyGems.org，来发布你的项目，你就可以跟踪到下载量。
每个包管理工具可能会对下载量有着大同小异的定义，而且下载量并不直接和安装、使用有关，但是它提供了一个基本的比较标准。尝试使用Libraries.io 来跟踪很多流行包管理工具的使用数据。
如果你的项目是托管在 GitHub 上，再一次切换到”Traffic” 页面，你可以用clone graph看看你的项目在一个给定的日期被克隆了多少次，按照独立克隆者的总克隆数排序。
如果使用项目的数量低于发现项目的数量的话，那么就有两个问题值得考虑。他们是：
- 你的项目没有成功的转化你的受众，或者
- 你吸引了错误的受众
举个例子，如果你的项目占据了 Hacker News 的头版头条，你可能会看到一个流量的高峰，但是与此同时，转化率会比较低，因为 Hacker News 上所有人都看见了你的项目。如果你的 Ruby 项目是在 Ruby 研讨会上宣传的，那么，更有可能从目标受众群体中获得较高的转化率。
努力找出你的受众是从哪里来的，然后在你的项目主页寻求他们的反馈，看看是上述两种情况的哪一种。
一旦知道了都是有那些人在使用你的项目的话，接下来就是看看他们会做些什么，他们是否基于源代码开始构建？为项目增加新的特性？他们将项目用于科研？还是普通业务？
Section 4 留住贡献者
人们找到了你的项目，而且已经在使用了。那么接下来你要问自己的问题就是：人们有对这个项目做贡献吗?
不管什么时候考虑贡献者这个问题都不能算早。没有大众的参与，你就可能会把自己置于一个尴尬的境地，那就是你的项目虽然很 流行（很多人用）但是并不被 支持（维护者没有足够的时间来满足用户的需求）。
保持项目的进展需要贡献者的流动（意思是有进有出），因为之前很活跃的贡献者也可能会去干别的事情。
可能会经常用的衡量社区的指标包括：
- 贡献者的总数和每个贡献者的提交次数： 有多少贡献者，哪些是活跃的，哪些是不活跃。GitHub 上，你可以在 ”Graphs” -> “Contributors” 面板查看这些信息。目前，这个图表只计算了那些往仓库默认分支推送的贡献者。
- 第一次，偶尔为之的，和持续的贡献者： 帮助检测是否有新的贡献者，以及他们是不是会再来。（偶尔的贡献者是那些提交的次数很少的人，当然啦，这个数目是多少取决于你，比如说五次。）如果没有新的贡献者，你的项目就会停滞不前。
- 打开的issue的数目和PR的数目： 如果这些数目太高，就意味着你可能需要有人帮你给issue分类以及做代码审查。
- 所有的打开过的issue和PR： 一个issue被人提出说明你的项目对他来说比较重要。如果这个数目随着时间在增长，这就意味着人们对你的项目感兴趣。
- 不同种类的贡献者： 比如说，提交代码，修复笔误或者bug，或者在issue下面评论。
开源远远不止代码，成功的开源项目包括代码、文档，以及它们在演进过程中的所有讨论。— @arfon, “开源的形态”
Section 5 维护者活跃度
最后，你还需要确定一件事，那就是维护者有足够的能力和时间处理社区的贡献。最后一个问题你要问自己的是：我是不是有足够的时间和精力来维护社区？
没有责任心的维护者绝对是开源项目的灾难。想象一下就知道，假如一位贡献者提交了代码或其他贡献，但从来没有得到过维护者的回应，此位贡献者一定会 100% 感到灰心，受了冷遇，并最终选择离开。
来自Mozilla的研究 说： 维护者的响应是鼓励更多贡献者中非常重要的一环。
考虑记录一下你或者其他的项目维护者对一次贡献（issue或者PR）响应的时间，响应并不需要花多少精力。哪怕只是说一句：“谢谢你的贡献，我下周会查看的。”
你也可以测量一在一个贡献被处理的过程中状态变化的时间。比如：
- 一个 issue 保持打开状态的时间（也就代表一个问题保持没有被解决状态的时间）。
- 一个 issue 是否因为一个 PR 得到了解决。
- 陈旧的 iuuse 是否被及时的关闭（被解决的问题应该关闭）。
- 合并一个PR的时间。
Section 6 使用 来学习关于人本身
理解一些细节能够帮助开源社区的运营者建设活跃的、成长的开源项目。尽管我们无法追踪社区活动的每一个细节，但是可以通过使用上述的框架，可以让我们集中精力到该用力的地方，进而有针对性的推动项目，增加项目成功的几率！加油！
- End -