“亲爱的GitHub” —— 致GitHub的一封公开信

最近，一个由开源项目（包括一些最流行的项目）维护者组成的团体逐渐壮大起来。该团体联署了一封致 GitHub 的公开信，以表达他们的挫折感以及他们的抱怨——他们感觉遭到了 GitHub 的忽视和无视。几天内，签署者的个数就增加到了数百（不过公平地说，其中一些明显是“假的签署者”）。其中包括 jQuery、React Native、node.js 和很多其他的成功开源项目的维护者。

该团体主要的抱怨在于，GitHub 缺少足够的支持和一种恰当的、双向的沟通渠道。他们坚称，他们的质询得到的唯一回应是“空白的回应或者根本没有回应”，证据就是 GitHub 一直没有能力或没有意愿解决的问题个数。在和 InfoQ 的对话中，作为这封公开信的发起人之一的 James Kyle 说，在他编写这封信的时候，他从全体参与者中收集到一个由大量改进建议组成的清单。但是，他们决定在最终的文稿中重点突出其中的三点。

由于缺少定制化功能，通过“问题跟踪器”报告问题很难用。这可以通过提供诸如自定义字段和基本的校验机制来确保问题带着所有必要的信息（例如，复现问题的步骤和测试所针对的版本）被记录在案；
“问题跟踪器”的评论系统中有太多的“噪音”，主要是由于没有实质内容的那种“+1”评论。这种评论对于项目维护者了解问题的普遍性是有帮助的，然而却给维护者们制造了太多的“噪音”。这可以通过“一级投票机制”来解决；
难以获取符合“CONTRIBUTING.md”指南的问题和拉取请求。这被认为是由于“贡献者指南”链接到的 GitHub 所展示的内容不够显眼的造成的。可能的解决方式是，允许项目维护者来配置要在新问题/拉取请求的顶部显示的文件。

InfoQ 采访了 James Kyle 以便更多地了解这封公开信的出现和意图。

问：您能描述一下这封“致 GitHub 的公开信”是怎样诞生的及其完成过程吗？

这一切开始于一群比较活跃的开源项目维护者在 twitter 上的讨论。后来，我建议给 GitHub 写一封公开信。我创建了一个 Google doc，并把他们都邀请进来。我写了几段，列出了这封信的大纲，然后把它发给其他人，让他们把自己的关切补充到信里。最初有一个很长的、有改进建议组成的清单，后来被精简到三个左右）。

问：您认为写公开信是你们表达对 GitHub 的抱怨的最佳方式吗？您期望 GitHub 给您怎样的答复呢？

我认为写公开信是我们向 GitHub 表达关切的仅存的唯一方式。参加签名的所有作者都向 GitHub 写信反映过他们对新特性的想法和产品存在的问题，但是没有得到任何实质性的答复。
GitHub 是一个伟大的产品，但显然不是完美无瑕的产品。所有参与公开信的人都维护着大量的项目，他们在很大程度上忍受着 GitHub 的缺点。我认为，对开源来说 GitHub 是最大的贡献者之一，因为事实上 GitHub 的用户不是一小撮人。

问：除了公开信中提到的主要的三点以外，在 GitHub 和开源开发社区之间存在着结构性的问题。您认为，如果有意愿解决这个问题，难度有多大？

这件事对 GitHub 是一个巨大的机会。根据 GitHub 自己的分析，“dear-github”这个代码库有超过 55000 个独立的访客。需要说明的是，这篇发表在“Hacker News”上的文章在整个历史上受欢迎的文章中排名第 19 位（而且还在攀升）。有超过 800 个签名，而且如果你快速浏览一下这些签署者的话，你会发现其中包含很多 GitHub 上的著名项目。
对我来说，很显然某些东西引起了 GitHub 用户群的共鸣。个人认为，GitHub 应将此视为机会。
希望 GitHub 会以某种形式回应我们，但是我一定不愿意一直等待。我私下里从 GitHub 以前的员工和现在的员工听到的消息并不乐观。过去三四年中，GitHub 的停滞不前让我愕然，开源社区严重依赖于它，它应该像其他产品一样持续改进。

“亲爱的 GitHub”激起了另一群开源开发者的快速回应，他们联署了另一封公开信“谢谢你，GitHub”，而且当前后者已经有 200 多个签名。Ruby on Rails 的核心开发者和“谢谢你，GitHub”最初的支持者，澄清说，后者虽然是对前者的回应，但其本身和前者并不太相关。