提供拉取請求審查¶

我們非常樂意收到撰稿人的評論，不論他們的經驗等級為何。

為什麼要審核貢獻？¶

每一份提交的貢獻都需要經過審核，不論它是由核心團隊成員或第一次提交的貢獻者所提交。每個人都有可能遺漏某些東西。審核程序的設立是為了提供額外的安全網。

審查程序的目的是確保所有內容 (包括程式碼和文件) 盡可能沒有錯誤且容易維護。任何您能為此目標所做的貢獻都是值得歡迎的。這可能包括一些簡單的事情，例如糾正一個錯字，或是發現 API 使用中沒有被捕捉到的邊緣情況。您可以找出讓測試制度更健全的方法，或是提出建議，讓變更的整體架構更容易維護或擴充。

我可以複審嗎？¶

是的！您可以對任何在 BeeWare 上開啟的拉取請求提供檢閱。

身為首次貢獻者，您應該隨時檢閱您發現的任何拉取請求，即使它是由核心團隊成員所提交。如果您是新手，您可能會遺漏一些較大的專案背景；但無論您的經驗程度如何，我們的目標都是讓程式碼保持平易近人。如果程式碼中有不合理的地方，這可能表示需要更多的說明文件 (可以是程式碼中的說明文件，也可以是獨立的設計說明文件)。

貢獻一個拉取請求檢閱¶

提供拉取請求審查

歡迎大家檢閱任何對BeeWare專案的貢獻。在開始之前，有一些重要的注意事項。

審閱前請先思考¶

在進行評論之前，請先思考。身為評審員，我們應該考慮我們即將發出的回應是否是：

真實。始終努力提供準確的建議和資訊。
有幫助。我們會就如何改善提交內容提供指導；此指導應明確指出問題的來源或未考慮的使用個案，並最好提供解決或滿足疑慮的未來路徑。
啟發。我們要做的是激勵作者願意按照我們的要求進行修改。
必要時。我們期望作者會閱讀我們張貼的所有內容；我們必須尊重他們的時間和努力，只在必要時才張貼。
親切。有多種方式可以呈現相同的回饋；我們需要確保自己的言詞是善意的、支持性的和建設性的。

在提供有效評論的同時，思考是完全可能的。以上討論的概念並不排除指出您在 PR 中發現的任何問題。如果貢獻者不知道需要改進的地方，他們就沒有機會改進他們的貢獻。重要的是要注意您提出回饋的方式。嘗試將您的評論非個人化。您可以說「這段程式碼有待改進」，而不是「您犯了個錯」。檢閱程式碼，而非作者。

除了找出需要改進的地方之外，記得提供正面的回饋也很重要。舉例來說，如果改動特別有用、做得特別巧妙，或是介紹了您不知道的 API，請讓作者知道！永遠不要低估指出某人做得對或做得好的地方的效果，在這個情況中，您所指出的其他東西都是需要解決的問題。

GitHub 閱讀建議¶

GitHub 的審查介面有一個變更建議機制，您可以提供您所建議的確切變更，以取代現有的內容。請記住，這些建議的變更在被接受並提交之前，是不會經過預提交（pre-commit）和著色（linting）檢查的。因此，此功能應該用於較小的變更，因為建議的變更越大，就越有可能引入問題。