GitHub 考慮賦予維護者禁用合併請求的權力

背景

GitHub 官方近期在社群討論區提案，計畫賦予專案維護者完全禁用拉取請求（Pull Requests, PRs）的權限。這項功能旨在解決長期以來維護者面臨的無效貢獻壓力，讓公開倉庫能以唯讀或僅限發布的形式存在，而不必強制開啟協作入口。

社群觀點

在 Hacker News 的討論中，絕大多數維護者對此功能表示熱烈歡迎，認為這項控制權早該在十年前就推出。支持者指出，許多公開專案並非為了尋求社群協作，而僅僅是作為代碼鏡像、個人作品展示或單向的軟體發布管道。目前維護者若不想處理 PR，往往只能透過第三方機器人自動關閉，或是在說明文件中苦口婆心要求使用者不要提交，但效果有限。尤其在 AI 生成內容氾濫的當下，低質量的「垃圾 PR」數量激增，許多為了刷簡歷或完成課程作業的開發者，會針對熱門專案提交毫無意義的修改，這對義務勞動的維護者造成了巨大的心理與時間負擔。

然而，這項提案也引發了關於開源本質的激烈辯論。反對者認為，PR 不僅是提交代碼的工具，更是發現專案分支與修復方案的重要索引。如果維護者關閉 PR 功能，普通使用者將難以發現其他開發者已經做好的修復或改進。一位參與討論的使用者批評，這種做法對使用者並不友善，甚至帶有一種「懶惰與小氣」的敵意，因為維護者完全可以選擇忽視 PR，而不必徹底封鎖他人表達意見與分享解決方案的管道。他主張，既然選擇將代碼託管在 GitHub 這種具備社交屬性的平台，就應承擔一定的公共責任，而非將其視為單純的免費硬碟。

針對這種「權利與責任」的衝突，維護者群體反駁道，開源（Open Source）並不等同於開放貢獻（Open Contribution）。像 SQLite 這樣成功的專案便是典型的「開源但封閉貢獻」模式。維護者強調，他們並沒有義務為不付費的使用者提供審閱服務，更不應被強加社交壓力。部分留言者提到，目前的 PR 機制帶有一種道德綁架的色彩，當 PR 堆積如山時，維護者常被指責不作為，這正是導致許多優秀開發者燃盡（Burnout）的主因。

除了支持與反對的兩極觀點，社群也提出了一些折衷的技術建議。例如，GitHub 應該強化「分支網路」的可視化，讓使用者即使在 PR 被禁用的情況下，也能輕易找到其他活躍的衍生版本。也有人建議引入更細緻的門檻限制，例如要求貢獻者必須先獲得認證，或是在該專案有過一定貢獻紀錄後才能開啟 PR，而非一刀切地全面禁用。這種「門檻式協作」或許能過濾掉大部分 AI 產生的垃圾內容，同時保留真正的社群協作火種。

延伸閱讀

• Repo Lockdown: 一個可以自動關閉並鎖定 GitHub 議題與 PR 的 GitHub Action 工具。
• The Four Freedoms (Free Software): 理查·斯托曼關於自由軟體定義的論述，常被用來釐清代碼自由與維護責任的邊界。
• XZ Utils Backdoor Story: 討論中提到的案例，說明了社交工程如何利用維護者的心理壓力來滲透開源專案。
• GitHub Community Discussion #185387: 官方發起的原始討論串，內有 GitHub 產品經理的初步回應。