一個開源項目維護者的筆記 — 為什麼我關閉 PRs

我在 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！太多的項目由于接受了太多沒有為長期可維護性而評估的新特性，導緻項目最後不受控制，但這隻是一個可以通過簡單兩個字而避免的問題。