注意
此頁面已棄用。請參閱 PyTorch Wiki 上的貢獻指南。
PyTorch 貢獻指南¶
PyTorch 是一個 GPU 加速的 Python 張量計算軟體包，使用基於磁帶的自動微分系統構建深度神經網路。
貢獻流程¶
PyTorch 組織由PyTorch 治理管理，技術貢獻指南可在CONTRIBUTING.md中找到。
PyTorch 開發過程包含核心開發團隊和社群之間大量開放討論。
PyTorch 的運作方式與 GitHub 上的大多數開源專案相似。但是，如果您以前從未為開源專案做過貢獻，這裡是基本流程。
找出您要開展的工作。 大多數開源貢獻來自人們解決自己的痛點。但是，如果您不知道自己想做什麼，或者只是想更熟悉該專案，以下是一些尋找合適任務的建議
確定您變更的範圍，如果是大型變更，請在 GitHub issue 上尋求設計評論。 大多數拉取請求都很小；在這種情況下，無需讓我們知道您想做什麼，直接開始即可。但如果變更很大，通常最好先透過提交 RFC獲取一些設計評論。
一些功能新增非常標準化；例如，很多人向 PyTorch 新增新的運算子或最佳化器。這些情況下的設計討論主要歸結為“我們是否需要此運算子/最佳化器？” 提供其有用性的證據，例如在同行評審論文中的使用或在其他框架中的存在，對於支援此論點有所幫助。
通常不接受新增來自最新研究的運算子/演算法，除非有壓倒性證據表明這項新發表的工作具有開創性成果，並且最終將成為該領域的標準。如果您不確定您的方法屬於哪種情況，請在實現 PR 之前先開一個 issue。
核心變更和重構可能很難協調，因為 PyTorch 主分支的開發速度很快。對於基礎性或跨領域的變更，請務必聯絡我們；我們通常可以提供有關如何將此類變更分階段為更易於評審的塊的指導。
編寫程式碼！
有關技術形式的 PyTorch 工作建議，請參閱CONTRIBUTING.md檔案。
開啟拉取請求。
如果您尚未準備好進行拉取請求評審，請先建立草稿拉取請求 - 之後可以透過按“Ready for review”（準備好評審）按鈕將其轉換為完整 PR。您也可以在 PR 標題前新增“[WIP]”（工作進行中），以便其仍處於草稿狀態。我們將在評審過程中忽略草稿 PR。如果您正在處理複雜變更，最好先從草稿開始，因為您需要花時間檢視 CI 結果以瞭解情況是否順利。
為您的變更找到合適的評審者。我們有一些人定期檢查 PR 佇列並嘗試評審所有內容，但如果您恰好知道受您補丁影響的給定子系統的維護者是誰，請隨時將其直接包含在拉取請求中。您可以從關注人士中瞭解更多可能評審您程式碼的人。
迭代拉取請求直到被接受！
我們將盡最大努力減少評審往返次數，並且只在存在重大問題時阻止 PR。對於拉取請求中最常見的問題，請檢視常見錯誤。
一旦拉取請求被接受且 CI 透過，您無需再做任何事情；我們將為您合併 PR。
入門¶
提出新功能¶
新功能想法最好在特定 issue 上討論。請儘可能多地包含資訊、任何隨附資料以及您提出的解決方案。PyTorch 團隊和社群經常評審新的 issue 和評論，並在認為能提供幫助時進行回覆。如果您對自己的解決方案充滿信心，請直接實現。
實現功能或修復錯誤¶
如果您想修復特定問題，最好在該問題下方評論說明您的意圖。但是，除了與開發者合作過的情況外，我們不會鎖定或分配問題。最好在 issue 上展開對話，討論您提出的解決方案。PyTorch 團隊可以提供指導，從而節省您的時間。
標記為 first-new-issue、low 或 medium priority 的問題是最佳的切入點，非常適合入門。
新增教程¶
pytorch.org 上的許多教程都來自社群本身，我們歡迎額外貢獻。要了解如何貢獻新教程，您可以在這裡瞭解更多資訊：GitHub 上的 PyTorch.org 教程貢獻指南
參與線上討論¶
您可以在使用者使用的PyTorch 討論論壇以及開發者和維護者使用的PyTorch 開發者討論論壇上找到活躍的討論。
提交拉取請求以修復開放問題¶
您可以在此處檢視所有開放問題的列表。評論問題是引起團隊注意的好方法。您可以在此處分享您的想法以及您計劃如何解決問題。
對於更具挑戰性的問題，團隊將提供反饋和指導，說明如何最好地解決問題。
如果您自己無法解決問題，評論並分享您是否可以重現問題可以幫助團隊識別問題區域。
評審開放的拉取請求¶
我們感謝您幫助評審和評論拉取請求。我們的團隊努力將開放拉取請求的數量保持在可管理的範圍內，如果需要更多資訊，我們會快速響應，我們會合並我們認為有用的 PR。但是，由於高水平的關注，我們總是歡迎更多人評審拉取請求。
提高程式碼可讀性¶
提高程式碼可讀性對每個人都有益。提交少量更改少數檔案的拉取請求通常比提交大量更改許多檔案的拉取請求更好。在 PyTorch 論壇 此處 或與您的改進相關的 issue 上發起討論是最好的入門方式。
新增測試用例以使程式碼庫更健壯¶
我們感謝額外的測試覆蓋。
推廣 PyTorch¶
您在您的專案、研究論文、文章、部落格或網際網路上的日常討論中使用 PyTorch 有助於提高人們對 PyTorch 和我們不斷壯大的社群的認識。請透過 marketing@pytorch.org 聯絡我們以獲得市場支援。
問題分類¶
如果您認為某個問題可以受益於特定的標籤或複雜度級別，請在該問題下評論並分享您的看法。如果您認為某個問題分類不當，請評論並告知團隊。
關於開源開發¶
如果這是您第一次為開源專案做貢獻，開發過程的某些方面可能對您來說不尋常。
沒有辦法“認領”問題。 人們通常希望在決定處理問題時“認領”它，以確保在其他人最終處理同一問題時不會浪費工作。這在開源中不太有效，因為某人可能決定處理某事，但最終沒有時間。您可以隨意提供建議資訊，但最終，我們將接受可執行的程式碼和大致共識以快速向前推進。
新功能有很高的門檻。 與企業環境不同，在企業環境中，編寫程式碼的人隱式地“擁有”它，並且在程式碼的生命週期內可以期望他們負責維護它，一旦拉取請求合併到開源專案中，它立即成為專案所有維護者的集體責任。當我們合併程式碼時，我們是說我們，維護者，可以評審後續更改並對程式碼進行錯誤修復。這自然導致更高的貢獻標準。
常見錯誤¶
您是否添加了測試？（或者如果變更難以測試，您是否描述瞭如何測試您的變更？）
我們要求新增測試有幾個原因
幫助我們判斷以後是否會破壞它
幫助我們判斷補丁本身是否正確（是的，我們評審了它，但正如 Knuth 所說，“謹防以下程式碼，因為我沒有執行它，只是證明了它的正確性”）
什麼時候可以不新增測試？有時，變更無法方便地進行測試，或者變更非常明顯正確（並且不太可能被破壞），因此可以不進行測試。相反，如果變更似乎可能（或已知可能）被意外破壞，花時間制定測試策略就很重要。
您的 PR 是否太長？
對於我們來說，評審和合並小型 PR 更容易。評審 PR 的難度與其大小呈非線性關係。
什麼時候可以提交大型 PR？如果在 issue 中有相應的設計討論，並得到了將評審您差異的人的簽字同意，這會很有幫助。我們還可以提供有關如何將大型變更分解為可單獨交付的部分的建議。同樣，如果 PR 內容有完整描述，這也有幫助：如果我們知道程式碼內部是什麼，評審程式碼會更容易！
對微妙之處的評論？ 如果您的程式碼行為微妙，請包含額外的評論和文件，以便我們更好地理解您的程式碼意圖。
您是否添加了臨時解決方案？ 有時，正確的答案是臨時解決方案。但通常，我們需要討論它。
您想觸及核心元件嗎？ 為了防止重大回歸，觸及核心元件的拉取請求會受到額外審查。在進行重大更改之前，請確保您已與團隊討論過您的更改。
想新增新功能嗎？ 如果您想新增新功能，請在相關 issue 上評論您的意圖。我們的團隊會嘗試評論並向社群提供反饋。在構建新功能之前，最好與團隊和社群其他成員進行公開討論。這有助於我們瞭解您正在開展的工作，並增加其合併的機會。
您是否更改了與 PR 無關的程式碼？ 為了方便程式碼評審，請僅在您的拉取請求中包含與您的更改直接相關的檔案。
常見問題解答¶
我如何作為評審者做貢獻？ 如果社群開發者重現問題、嘗試新功能或以其他方式幫助我們識別或排除問題，這非常有價值。在任務或拉取請求上評論並提供您的環境詳細資訊非常有用且受到讚賞。
CI 測試失敗了，是什麼意思？ 也許您的 PR 基於一個損壞的主分支？您可以嘗試在最新的主分支之上 rebase 您的更改。您也可以在https://hud.pytorch.org/檢視主分支 CI 的當前狀態。
哪些是最高風險的更改？ 任何涉及構建配置的區域都是高風險區域。除非您事先與團隊討論過，否則請避免更改這些內容。
嘿，我的分支上出現了一個提交，這是怎麼回事？ 有時，其他社群成員會為您的拉取請求或分支提供補丁或修復。這通常是為了使 CI 測試透過所必需的。
關於文件¶
Python 文件¶
PyTorch 文件由 Python 原始碼使用 Sphinx 生成。生成的 HTML 會複製到 pytorch.github.io 主分支的 docs 資料夾中，並透過 GitHub Pages 提供服務。
C++ 文件¶
對於 C++ 程式碼，我們使用 Doxygen 生成內容檔案。C++ 文件在專用伺服器上構建，生成的 檔案複製到https://github.com/pytorch/cppdocs 倉庫，並透過 GitHub Pages 提供服務。
教程¶
PyTorch 教程是用於幫助理解如何使用 PyTorch 完成特定任務或理解更全面的概念的文件。教程使用 Sphinx-Gallery 從可執行的 Python 原始碼檔案或 restructured-text (rst) 檔案構建。
教程構建概覽¶
對於教程，拉取請求會觸發使用 CircleCI 重新構建整個站點，以測試更改的效果。此構建被分片到 9 個工作程序構建中，總共需要約 40 分鐘。同時，我們使用 make html-noplot 進行 Netlify 構建，它在不渲染筆記本輸出到頁面的情況下構建站點，以便快速評審。
PR 接受後，站點將使用 GitHub Actions 重新構建和部署。
