measure view_我们学习了6课，即建立Measure（贡献者关系管理系统）

measure view

由于缺乏更好的期限， Measure的核心是贡献者关系管理系统。 Measure由易于理解的窗口小部件组成，可以任意显示这些窗口小部件以构建仪表板。 它使您可以可视化并了解人们（无论是个人还是组织）如何与GitHub上的开源项目进行交互。 它产生的指标不仅关注代码，而且关注贡献者。

在以后的专栏中，我将介绍为什么我认为这是一个重要的主题，但是在本期《队列》中，我想介绍在构建Measure时吸取的六个教训。

1.命名很难

正如已经指出的 ，给事物命名很难。 众所周知。 听到一个好名字，它应该令人回味，并且几乎是显而易见的，但是它不可能如此明显或普遍，以至于有人已经在使用它，或者如此通用，以至于它根本没有意义。 但是，我们在Measure的背景下学到的教训却略有不同。 两个项目的创建者之一在启动时就喜欢这个名字，另一个则不喜欢。 今天仍然如此。 但这仅仅是因为现在每个创始人都与项目启动时有相反的意见。 随着项目的发展，我们的观念发生了变化，这种细微差别恰恰证实并复合了“给事物命名很难”。

2.一旦您深入研究细节，听起来简单的功能有时会很复杂

早期出现的一项功能请求是通知系统。 这似乎是有用的功能，而且非常简单，所以我们同意了。 一旦进入实现，我们很快就意识到，尽管通知本身确实很简单，但向这种性质的开源项目中添加全面的通知​​系统确实不是一件容易的事。 一方面，一种灵活而全面的配置方法来定义您要通知的内容绝非易事。 另一方面，您不仅要决定要支持的通知方法（有电子邮件，推送通知，还有无数种），还要决定每种实现的方法（复杂度在哪里）。 简而言之，“我希望在达到此阈值时通过SMTP发送电子邮件”。 “我想通过这种任意方法得到有关这种任意事情的通知”。 在同意功能之前，请仔细考虑实施细节，这一点很重要。

3.与您的依赖项紧密合作，它们对您会很好

像大多数开源项目一样，Measure是建立在许多其他开源项目之上的。 其中之一就是GHCrawler 。 在项目的早期，我们意识到GHCrawler缺少了所需的功能，因此我们打开了一个拉取请求（PR）并将其添加。 看起来很简单，但是通常只需在分叉中添加功能并继续前进，就会更快或更容易。 “我会尽快整理并提交上游，”您自言自语。 而您确实打算； 但是忘记和继续前进太容易了。 将我们的更改回馈给所有人，不仅可以改善GHCrawler，而且下次我们获得反馈时，开发人员会非常乐于接受。 我们用自己的贡献建立了融洽的关系，并且是社区的一部分。

4.您的错误路径至少与起作用的部分一样重要

这是人们直观地了解和理解但又容易忽略的另一种方式。 不可避免地，有人下载您的软件到他们正常工作之间，有时会无法正常工作。 如果您的错误消息没有解释发生的原因以及原因（以一种可以纠正该错误的方式），那么许多潜在的用户将会继续前进。 我们都经历过，但是不透明或不存在的错误消息确实令人沮丧。 特别是从一开始，用户对项目的印象就多于处理错误和失败的方式，而不是一切正常时的运作方式。

5.营销很重要，营销项目与编写项目一样具有技巧

在开源软件社区中，营销可能是一个肮脏的词。 毫无疑问，错误地进行营销可能会令人毛骨悚然或散发出错误的氛围。 但是，如果您构建一个更好的捕鼠器，世界将不会走上通往您家门的道路。 不要再想了。 您需要确保其他人了解您的出色项目，以便他们可以开始使用它。

6.有一个哲学

当我们开始这个项目时，我们写下了五种哲学，并在回购中将它们明确化：

• 应该很简单
• 应该在视觉上吸引人
• 应该将贡献者的概念视为头等公民
• 应该提供自以为是的默认体验，但可以扩展
• 应该能够将内部和外部的贡献完全分开

除项目描述外，此列表还使人们可以轻松了解Measure是什么，它做什么以及为谁服务。 但是它还有另外两个重要的事情。 它清楚地表明Measure 不适合谁使用，它使我们可以更轻松地说“不”，以表示不符合该要求的请求或PR。 说“不”从来都不是一件容易的事，但是要明确为什么要这样做，并以尊重的态度行事，可以走很长一段路。 虽然说“是”可能会更容易，但尝试合并每个PR。 留下未解决的问题或PR，因为您将来可能会在遥远的一天解决它们； 或者让您的项目尝试在其核心关注范围之外做太多事情，都是造成不良结果的因素。

这是我们在构建Measure时学到的（或有时是再学习的）六课。 您在维护一个开源项目时学到了什么？

翻译自: https://opensource.com/article/19/2/lessons-we-learned-building-measure

measure view