我在 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（最持久的|煩人的|困難的 PR） 的人，通常是那些希望解決他們自己專案中某個問題的人，但在程式碼被合併之後會立即消失。他們意識到（通常不是很明確）如果他們能夠說服我維護他們的 “雪花程式碼（snowflake code）”，就可以減輕自己一直存在的技術負擔。
如果貢獻者願意與專案建立長期的關係，我也會願意放手一些對架構的控制。但他們必須證明我可以相信他們。我剛開始的專案裡的最好的貢獻者是那些在他們的盈利性工作中使用這些專案的人，他們會每週拿出一個小時或兩個小時來幫助處理 issue 佇列，關閉無效 issue，以及提交簡單 bug 修復的 PR（特別是與他們最熟悉的專案相關部分）。
對於任何維護 OSS 專案的人：確保你有一套完善的原則可以用來評估 PR。而且當 PR 不符合你的標準時，記住要隨時 SAY NO！太多的專案由於接受了太多沒有為長期可維護性而評估的新特性，導致專案最後不受控制，但這只是一個可以通過簡單兩個字而避免的問題。