貢獻者指南¶

如果您正在閱讀本文，您可能對貢獻 Requests 專案感興趣。非常感謝您！開源專案的存續仰賴於來自他人的支持，而您甚至考慮為 Requests 專案做出貢獻，這對我們來說是非常慷慨的舉動。

本文檔闡述了為此專案做出貢獻的指南和建議。如果您正在考慮貢獻，請先閱讀本文檔，並了解如何為此專案做出貢獻。如果您有任何疑問，請隨時聯繫主要維護者：Nate Prewitt、Ian Cordasco 或 Seth Michael Larson。

本指南根據您考慮做出的貢獻類型分為幾個部分，其中一個部分涵蓋了所有貢獻者的一般準則。

保持友善¶

保持友善，否則請離開。 —Kenneth Reitz

Requests 有一條非常重要的規則，適用於所有形式的貢獻，包括回報錯誤或請求功能。這條黃金法則就是「保持友善，否則請離開」。

我們歡迎所有貢獻，前提是所有參與者都受到尊重。

儘早取得回饋¶

如果您正在做出貢獻，不必等到您的貢獻完美無瑕才提交。盡可能早地尋求回饋對所有參與者都有幫助。提交早期、未完成的貢獻版本以徵求回饋，絕不會影響您的貢獻被接受的機會，並且可以避免您在不適合專案的貢獻上投入大量工作。

貢獻的適用性¶

我們的專案維護者對貢獻是否適用於 Requests 擁有最終決定權。所有貢獻都會經過仔細考慮，但有時貢獻會因為不符合專案當前目標或需求而被拒絕。

如果您的貢獻被拒絕，請不要灰心！只要您遵循這些準則，您下次的貢獻將更有可能被接受。

程式碼貢獻¶

提交程式碼的步驟¶

當貢獻程式碼時，您需要遵循此檢查清單

在 GitHub 上 Fork 此儲存庫。
執行測試以確認它們在您的系統上全部通過。如果沒有通過，您需要調查它們失敗的原因。如果您無法自行診斷，請按照本文檔中的指南提出錯誤報告：錯誤報告。
編寫測試來示範您的錯誤或功能。確保它們失敗。
進行您的變更。
再次執行整個測試套件，確認所有測試都通過，包括您剛剛新增的測試。
向主儲存庫的 main 分支發送 GitHub Pull Request。GitHub Pull Request 是此專案上預期的程式碼協作方法。

以下子章節將更詳細地介紹上述某些要點。

程式碼審查¶

貢獻在經過程式碼審查之前不會被合併。您應該實作任何程式碼審查回饋，除非您強烈反對。如果您反對程式碼審查回饋，您應該清楚且冷靜地說明您的理由。如果在這樣做之後，回饋仍然被認為適用，您必須應用回饋或撤回您的貢獻。

程式碼風格¶

Requests 使用一系列工具來確保程式碼庫在成長過程中保持一致的風格。我們使用一個名為 pre-commit 的工具來協調這些工具。這可以在本地安裝並在您開啟 PR 之前對您的變更執行，並且也將在變更合併之前作為 CI 批准流程的一部分執行。

您可以在 Requests 頂層目錄的 .pre-commit-config.yaml 中找到指定的完整格式要求列表。

新貢獻者¶

如果您是開源新手或相對新手，歡迎您！Requests 旨在成為進入開源世界的溫和入門。如果您擔心如何最好地做出貢獻，請考慮發送郵件給維護者（上面列出）並尋求幫助。

另請查看儘早取得回饋章節。

文件貢獻¶

我們隨時歡迎改進文件！文件檔案位於程式碼庫的 docs/ 目錄中。它們以 reStructuredText 撰寫，並使用 Sphinx 生成完整的文件套件。

當貢獻文件時，請盡力遵循文件檔案的風格。這表示您的文字檔案寬度軟限制為 79 個字元，並且採用半正式但友好且平易近人的散文風格。

當呈現 Python 程式碼時，請使用單引號字串（'hello' 而不是 "hello"）。

錯誤報告¶

錯誤報告非常重要！但在您提出錯誤報告之前，請先查看 GitHub issues，包括開放和已關閉的，以確認該錯誤之前沒有被報告過。重複的錯誤報告會大量消耗其他貢獻者的時間，應盡可能避免。

功能請求¶

Requests 處於永久功能凍結狀態，只有 BDFL 可以新增或批准新功能。維護者認為 Requests 目前是一個功能完備的軟體。

在維護一個廣泛使用的開源專案時，最重要的技能之一是學會對建議的變更說「不」，同時保持開放的耳朵和心態。

如果您認為缺少某個功能，請隨時提出功能請求，但請注意，您的功能請求極有可能不會被接受。