我们在构建贡献者关系管理系统 Measure 中学到的 6 个教训

从本质上讲， Measure 可以说是一个贡献者关系管理系统。Measure 由易于理解的小部件组成，这些小部件可以任意显示以构建仪表板。它允许您可视化和理解个人和组织如何与 GitHub 上的开源项目进行交互。它生成的指标不仅关注代码，还关注贡献者。

在未来的专栏中，我将介绍为什么我认为这是一个重要的话题，但在本期“队列”中，我想介绍我们在构建 Measure 时学到的六个教训。

1. 命名事物很难

正如已经 指出的那样，命名事物很难。这是众所周知的。一个好的名字应该是令人回味的，并且一旦你听到它几乎是显而易见的，但它不能太明显或太常见以至于其他人已经在使用它，或者太通用以至于它根本没有任何意义。然而，我们在 Measure 的背景下学到的是一个稍微不同的教训。在项目启动时，两位创始人中的一位喜欢这个名字，而另一位不喜欢。今天仍然是这种情况；但这仅仅是因为每位创始人现在的意见都与项目启动时相反。随着项目的增长，我们的看法发生了变化，这种细微差别只是证实并加剧了“命名事物很难”。

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

早期收到的一个功能请求是通知系统。这看起来像是有用的功能，而且足够简单，所以我们同意了。一旦我们开始实施，我们很快意识到，虽然通知本身确实很简单，但为这种性质的开源项目添加全面的通知系统实际上并非如此。一方面，定义您想要收到通知的内容的灵活但全面的配置方法并非易事。另一方面，您不仅要决定您将支持哪些通知方法（有电子邮件、推送通知和无数更多），还要决定每种方法的哪些实现（这就是复杂性膨胀的地方）。简而言之，“当达到此阈值时，我想通过 SMTP 发送电子邮件”很容易。“我想通过这种任意方法获得关于这种任意事物的通知”则不然。在您同意某项功能之前，仔细考虑实施细节非常重要。

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

像大多数开源项目一样，Measure 构建在许多其他开源项目之上。其中之一是 GHCrawler。在项目早期，我们意识到 GHCrawler 缺少我们需要的功能，因此我们打开了一个拉取请求 (PR) 并添加了它。这看起来很简单，但通常情况下，更快捷或更容易的方法是在您的 fork 中添加功能并继续前进。“我会尽快清理它并将其提交到上游，”您对自己想。而且您确实打算这样做；但很容易忘记并继续前进。将我们的更改贡献回去不仅为所有人改进了 GHCrawler，而且下次我们有反馈时，开发人员非常乐于接受。我们通过我们的贡献建立了融洽关系，并成为社区的一份子。

4. 您的错误路径至少与工作部分同等重要

这是另一个人人都凭直觉知道和理解但很容易忽视的问题。不可避免地，在有人下载您的软件到他们使其正常工作之间，会有一些时候它无法按预期工作。如果您的错误消息没有解释发生了什么以及原因——以允许纠正错误的方式——许多潜在用户将会离开。我们都经历过它们，但模糊不清或不存在的错误消息真的令人沮丧。尤其是在最初，用户对您的项目的印象更多来自它如何处理错误和失败，而不是来自一切正常时它的工作方式。

5. 营销很重要，营销一个项目与编写它一样是一项技能

在开源软件社区中，营销可能有点像一个肮脏的词。并且不要误会，不正确的营销可能会令人毛骨悚然或发出错误的氛围。但是，如果您制造出更好的捕鼠器，世界不会为您铺路。不要再以为会这样了。您需要确保其他人知道您的伟大项目，以便他们可以开始使用它。

6. 拥有一个理念

当我们启动该项目时，我们写下了五个理念，并在仓库中明确了它们

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

除了项目描述之外，此列表还允许人们轻松理解 Measure 是什么、它做什么以及它是为谁服务的。但它还做了另外两件重要的事情。它明确了 Measure 不适合哪些人，并且如果功能请求或 PR 不符合该理念，它使我们更容易说“不”。说“不”从来都不是一件容易的事，但是就原因制定明确的指导方针，并以尊重的方式这样做，会大有帮助。虽然说“是”可能更容易，但尝试合并每个 PR；由于您可能会在遥远的将来解决它们而使问题或 PR 悬而未决；或者让您的项目尝试做太多超出其核心重点的事情都是导致不良结果的因素。

这些是我们在构建 Measure 时学到的（或在某些情况下重新学到的）六个教训。您在维护开源项目时学到了哪些教训？