避免範圍蔓延

當單一貢獻所解決的問題或實現的功能清單大幅超出工作開始時的預期時，就會發生「範圍爬升」。您從一個簡單的問題開始；您發現了一個密切相關的問題，並決定也包含該修正；然後是第三個......在您知道之前，您已經有一個拉取請求，關閉了 5 個問題，並新增了 3 個功能，包括數十個檔案。

Scope creep 會發生在每個人身上。對於經驗豐富的開發人員而言，這是一個再熟悉不過的概念；我們都曾經多次發生過，並經歷過隨之而來的所有問題。

避免範圍擴大有非常實際的理由。貢獻越大，工作就越困難。識別邊緣案例或潛在問題變得更加困難，這意味著貢獻的整體品質可能會降低。當審查員需要處理多種可能毫無關聯的情況時，審查也會變得更具挑戰性。更大的貢獻意味著更多的審查評論，而身為貢獻者，跟蹤多個審查線程可能會變得很困難。甚至您的 GitHub 體驗也會受到影響 - GitHub 的使用者介面會隨著 PR 大小的增加而變慢，這意味著在 GitHub 介面上瀏覽檔案以及嘗試留下審閱評論會變得越來越困難。

任何時候，如果您發現有理由要在您的貢獻中加入任何東西，而這些東西並不是原始提案或錯誤報告中明確的一部分，您就應該考慮您是否正在邁向範圍爬升。是否有兩個不同的功能可以分開實作？一個功能是否可以在已知限制或錯誤的情況下實作，並在後續的拉取請求中修正該錯誤？錯誤修正的一部分是否獨立於另一部分？如果可以在不改變原始貢獻的情況下刪除變更的一部分，那就應該刪除。

開發軟體總是一個逐步改善的過程。每個人的貢獻都應該在合併後讓程式碼基礎處於更好的狀態，但留下錯誤或功能的一部分作為未來改進的工作也是完全可以接受的。這可能意味著將一個 pull request 分成可以獨立檢閱的多個部分，或記錄一個問題，以便其他人可以調查並解決問題。

限制每次貢獻的範圍有助於包括您在內的所有參與者。您的審稿人、甚至您自己，都會很感激。