我在 GitHub 上和其他地方维护着许多的开源项目（截止本文写作时超过 160 个）。在过去几年里，我已经合并 以及/或者 关闭了上千个 Pull Requests (PRs) 和补丁，现在想在这里总结一下我不合并许多 PRs 的原因。
我的几个项目都有协同维护者，但是大多数只有我一个人维护。因此巴士系数是很低的，但我通过授予非常开放的许可证和鼓励 fork 来抵消。我还花了一定的时间（平均为 5-10 小时/周）对我的 OSS 项目进行维护，并且有约 1000 美元/年的个人预算，用于支持项目的基础设施（这比那些使用我项目盈利的公司投入到 OSS 的还多，心塞）
我不喜欢在没合并的情况下关闭 PR，因为 PR 意味着有人喜欢我的项目，值得贡献。但有些时候这是有必要的。我不想成为一个混蛋（我通常会首先感谢贡献者以尝试减轻一个关闭的 PR 给贡献者带去的打击），之所以这样做只是为了保证项目的持续健康。下面是一些我维护项目背后的原则，希望大家通过阅读它们，能更了解为什么我选择关闭 PR 而不是合并它们。
评估 Pull Requests 的原则
对于我维护的项目（事实上大多数是我工作中使用的软件），我认为以下的原则是最重要的，如果一个项目不坚守这些原则，我通常会选择关闭 PR。
一切都应该通过自动化测试
几乎每个我维护的项目都至少全面覆盖了通过 Travis CI，Jenkins 或其他 CI 系统的 'happy path'。If You Breaka My Tests I Breaka You Face。但也会有少数例外的情况，如果所有测试都不通过，我不会合并 PR。我也不会合并具有大量新的、未测试功能的 PR。我不要求覆盖 100% 的单元测试，但所有的 happy path 应该经过测试。
可维护性 > 完整性
我不会去迎合每一个人，我通常只会满足自己。而且对于 98% 我自己的 OSS 项目，实际上我在使用它们，无论是在生活还是生产中（通常是数十或者数百个项目）。所以通常我都会对它们感到满意。
我不会为我的项目添加给我增加维护负担的东西，除非它是非常引人注目的功能或者是明显的错误修正。我也不会维护一个我自己都完全不明白的系统，所以我喜欢让事情变得更 “轻量” 并砍掉一些边缘情况，而不是增加一些我没有时间偿还的技术债务。
满足 80％ 的用例
我看过很多 PR 的一次性功能，但却从未在别的地方看到过。当然，也许会存在 unicorn 系统需要在一些功能模糊的 app 中配置繁琐的细节……但我不会在我的项目引入这样的代码，因为：
a)我不使用它，所以我不能保证它
b)它增加了维护开销 — 即使它是一个 “简单” 的添加
所以如果你是 unicorns 之一，请 fork 我的项目，我不会觉得被冒犯。我的公共项目几乎都是旨在解决最常见的问题，而且我也在尝试让别人可以更简单地通过 fork 或者是拓展来进一步开发我的项目。
使用正确的语法
通常，我的自动化测试内置了自动化语法审查功能。但如果没有的时候，请确保基本的东西，例如间距、变量命名约定、行结束、空格而不是制表符，等等遵循项目的一般风格。我会经常合并代码然后修改成自己的代码风格，但最好是不必这样做，而且我更愿意合并没有风格怪癖的 PR。
不要改变架构
（除非首先在 issue 中讨论）
我曾经遇到过这样的 PR：整个项目架构或测试架构被交换掉了。我永远不会合并类似这种的 PR，除非它首先在 issue 中已经经过彻底讨论（并被批准）。每样东西以某种方式的存在都有它的理由（事实上是多个理由）。这并不是说我的架构或测试总是正确的，但我不会合并一些使我更难理解我项目是如何工作的东西。
不要在一个 PR 中更改超过 50 行代码
（除非你有很好的理由）
我经常收到有人提交了一个 PR 的通知，我跳过去审查它，然后看到 20 个文件被更改了 800 行代码，添加了 12 次提交。如果这是一个之前在 issue 中讨论的架构更改，我可以理解会有这样一个大型的 PR，我也会花时间去阅读它。但任何超过约 50 行的变化，我的大脑没有能力在不到一个小时的时间内完成一个良好的代码审查。
结论：“No” 是默认的回复
这个过程中最大的讽刺之一是，那些最固执、烦人、难搞的 issue 和 PR 的发起者在我解决了他们项目中出现的问题之后马上就会消失。他们意识到（通常不那么直接）如果他们能够说服我维护他们的 “雪花代码（snowflake code 不用大家约定俗成的写法，刻意使用奇葩的写法）”，就可以减轻自己一直存在的技术负担。
如果贡献者愿意与项目建立长期的关系，我也会愿意放手一些对架构的控制。但他们必须证明我可以相信他们。我刚开始的项目里的最好的贡献者是那些在他们的盈利性工作中使用这些项目的人，他们会每周拿出一个小时或两个小时来帮助处理 issue 队列，关闭无效 issue，以及提交简单 bug 修复的 PR（特别是与他们最熟悉的项目相关部分）。
对于任何维护 OSS 项目的人：确保你有一套完善的原则可以用来评估 PR。而且当 PR 不符合你的标准时，记住要随时 SAY NO！太多的项目由于接受了太多没有为长期可维护性而评估的新特性，导致项目最后不受控制，但这只是一个可以通过简单两个字而避免的问题。
