PyTorch 治理 | 機制#
建立日期: 2019年3月11日 | 最後更新日期: 2025年4月16日
摘要#
PyTorch 採用分層的技術治理結構。
一個由 **貢獻者** 組成的社群，他們提交 issue、進行 pull request 併為專案做出貢獻。
一小群 **模組維護者** 負責驅動 PyTorch 專案的每個模組。
他們由 **核心維護者** 監督，後者負責驅動專案的整體發展方向。
核心維護者中有一位 **首席核心維護者**，他是最終的決策者。
所有維護者都應強烈遵循 PyTorch 的設計理念。
除了維護者之外，社群還被鼓勵積極貢獻、提交 issue、提出建議、審查 pull request 並積極參與社群。憑藉貢獻和投資意願，任何人都可以被接納為維護者，並獲得程式碼庫部分內容的寫許可權或所有權。
技術治理與業務治理嚴格分開。將技術治理與業務治理分開，可以確保任何個人或公司都無法透過“金錢購買”來影響專案的技術指導。此外，參與技術治理過程的成員是 **個人**，而非公司。也就是說，沒有為特定公司預留的席位，成員資格與個人相關聯，而不是與僱傭該個人的公司相關聯。
模組維護者#
模組定義為 PyTorch org 中的 GitHub 倉庫，或核心倉庫 pytorch/pytorch 中的目錄。每個模組將擁有自己的維護者團隊。維護者團隊負責審查和批准提交、改進設計以及更改模組的範圍。每個維護者團隊可以採納自己的決策規則和程式（預設以多數票制）。模組維護者有權對其他模組維護者做出的決定提出異議——特別是當這些決定影響到他們時。當出現異議時，模組維護者團隊應提供對異議、相關論點和解決方案的合理且公開的解釋。在模組維護者無法自行達成一致的特殊情況下，他們將升級到核心維護者進行審查。升級的請求將由核心維護者根據其規則和程式進行解決。
每個維護者團隊都應公開其模組的溝通訊息（願景、大致路線圖、設計文件、任何異議和異議解決方案），以便貢獻者和其他感興趣的各方瞭解專案的未來發展方向並參與討論。
維護者的職責包括
對模組的高優先順序 issue 進行分類
對模組的高優先順序 pull request 進行分類、審查和合並
支援與模組相關的公共文件
執行公開的開發者會議
核心維護者#
核心維護者應深入瞭解 PyTorch 的程式碼庫和設計理念。他們的職責包括：
闡述專案連貫的長期願景
以各方都能接受的方式協商和解決有爭議的問題
接收來自 PyTorch 各利益相關者的廣泛變更請求，並進行評估/接受（小範圍的模組級請求由模組維護者處理）
核心維護者團隊作為一個整體，有權否決在模組維護者層面做出的任何決定。核心維護者有權根據自己的判斷解決爭議。核心維護者應公開闡述其決策過程，併為其決定、否決和爭議解決方案提供清晰的理由。
核心維護者是 PyTorch GitHub Org 的管理員，並在 維護者 列表中列出。
首席核心維護者 (BDFL)#
在某些情況下，核心維護者可能無法達成共識。為了做出這些艱難的決定，核心維護者之中會指定一名公開宣佈的首席核心維護者，這在開源治理模型中通常被稱為 BDFL（Benevolent Dictator for Life，終身仁慈的獨裁者）。
首席核心維護者應公開闡述其決策過程，併為其決定提供清晰的理由。首席核心維護者還負責確認或移除核心維護者。
提名、確認和移除維護者#
原則#
模組維護者團隊的成員資格是基於 **個人** 的 **功績**，在他們透過貢獻、審查和討論證明了對該元件的強大專業知識，並與該元件在 PyTorch 整體方向中的定位一致後授予。
要成為維護者團隊的成員，個人必須表現出與 PyTorch 整體原則的強大且持續的一致性。
模組維護者或核心維護者沒有任期限制。
如果維護者長時間不活躍，可以採用較寬鬆的標準將其移至“榮譽”狀態。每個模組維護者團隊可以定義適合該模組的不活躍期限。
成員資格是針對個人的，而非公司。
提名流程#
每個模組都有自己的流程。請聯絡模組維護者獲取更多資訊。但是，如果沒有明確的流程，您可以透過提交 此表格 向核心維護者提出請求。核心維護者每三個月開會一次。
如果您向核心維護者提交請求，請求中必須包含以下資訊：
被提名人在該模組的程式碼、審查和設計貢獻的深度和廣度。
關於被提名人與維護者、使用者和社群互動的評價（正面和負面）。
來自維護者的總體支援評價。
核心維護者隨後評估所有資訊，並做出確認或拒絕提名的最終決定。核心維護者的決定必須得到充分的闡述，並且是公開的。
移除流程#
與提名流程類似，社群中的任何人都可以提名某人從模組維護者或核心維護者職位上移除。
個人也可以自我提名移除。
核心維護者（排除有利益衝突的人員）將請求或整理有關以下方面的更多資訊：
他們在專案中的活躍度（或不活躍度）。
他們在該領域不斷變化的思維方式，導致與專案整體方向衝突。
其他使他們不適合擔任維護者的資訊，例如違反行為準則的問題，他們在專案範圍之外的活動與專案價值觀相沖突。
利益衝突：親屬或浪漫關係。
核心維護者隨後評估所有資訊，並做出確認或拒絕移除的最終決定。核心維護者的決定必須得到充分的闡述，並且是公開的。
提名核心維護者#
任何核心維護者或模組維護者都可以提名某人成為核心維護者。
首席維護者（BDFL）負責評估提名。
首席維護者請求或整理有關候選人成為核心維護者實力的更多資訊。
來自其他核心維護者和模組維護者的支援信。
來自 PyTorch 社群內利益相關者的總體支援信。
任何新的、與候選資格相關的資訊。
首席維護者評估所有資訊，並做出確認或拒絕提名的最終決定，並對其決策理由進行清晰的公開闡述。
移除首席核心維護者和提名新首席核心維護者#
核心維護者中的絕大多數（75%）可以選擇移除首席核心維護者。
在首席核心維護者被移除後，或在不可預見的情況下（例如首席核心維護者永久性不可用），核心維護者將透過排序選擇投票方法選舉新的首席核心維護者。
新增、移除和重新定義模組和專案#
核心維護者共同負責決定在 PyTorch org 中新增、移除和重新定義新模組，無論是作為 PyTorch GitHub org 中的新倉庫，還是作為 pytorch/pytorch 倉庫中的資料夾。
他們邀請社群成員（包括他們自己）就這些變更提出建議。這些建議是開放的，但需要進行一些基本的工作來提出令人信服的變更理由。以下是此流程的一個示例方法：
採訪研究人員/利益相關者，與社群交流，收集 issue；
閱讀論文，參加會議，根據經驗構建示例管道；
建立“現狀”分析——確保此變更的必要性，例如，新增新專案或模組是否值得維護成本；或者移除專案或模組是否會從 PyTorch 中移除過多價值；
建立提案；提案涵蓋在批准後對維護、開發和社群的計劃。
核心維護者對提案做出最終決定，並公開闡述決策理由。
決策制定#
無爭議的變更#
主要工作透過 GitHub 上的 issue 和 pull request 進行。維護者應避免直接將更改推送到 PyTorch 倉庫，而應依賴 pull request。由核心維護者或模組維護者批准 pull request，即可將其合併，無需進一步流程。如 維護者 頁面和 CODEOWNERS 中列出的核心和模組維護者最終批准這些更改。
通知相關專家有關 issue 或 pull request 的資訊非常重要。強烈優先考慮來自相關領域專家的審查，尤其是在 pull request 批准方面。未能這樣做可能會導致更改被相關專家撤銷。
有爭議的決策流程#
給定領域內的重大變更需要開啟一個 GitHub issue 進行討論。這包括：
對 PyTorch 框架或庫的任何語義或語法更改。
對 Python 或 C++ API 的向後不相容的更改。
向核心框架或庫新增內容，包括在現有庫中新增實質性的新功能。
移除核心功能或平臺支援。
核心和模組維護者最終批准這些更改。
專案通用政策#
PyTorch 已成立為 LF Projects, LLC 的一部分。適用於 PyTorch 和 PyTorch 參與者的政策，包括商標使用指南，位於 https://www.lfprojects.org/policies/。
PyTorch 參與者承認，所有新貢獻的版權將保留在版權持有者手中，作為獨立的創作作品，並且任何貢獻者或版權持有者都無需將版權轉讓給專案。除下文所述外，對專案的所有程式碼貢獻必須使用此處提供的 3 條款 BSD 許可證（“專案許可證”）：https://opensource.org/licenses/BSD-3-Clause。所有出站程式碼都將根據專案許可證提供。維護者可以例外性地批准使用替代性開放許可證或多個許可證用於入站或出站貢獻。
常見問題解答#
問：如果我想擁有（或部分擁有）專案的一部分，例如一個功能領域或領域庫，例如 線性代數 **或** Torch Vision **，該怎麼辦？ 這是完全可能的。第一步是開始為現有專案領域做出貢獻，並支援其健康發展和成功。除此之外，您可以透過 GitHub issue 提交關於新功能或改進專案領域的提案。
問：如果我是一家公司，想在內部使用 PyTorch 進行開發，能否授予或購買一個董事會席位來驅動專案方向？ 不行，PyTorch 專案嚴格遵循維護者專案理念，並明確區分技術治理與業務治理。但是，如果您想參與贊助和支援，您可以參與 PyTorch 基金會 (PTF) 和透過其進行贊助。您也可以讓您的工程師嘗試成為維護者，但這不被保證，並且是基於功績的。
問：PyTorch 專案是否支援資助或以其他方式支援使用或貢獻專案的獨立開發者？ 目前不支援。但是，我們正在探索更好地支援 PyTorch 周圍獨立開發者社群的方法。如果您有建議或意見，請在 PyTorch 論壇上提出討論。
問：如何為專案貢獻程式碼？ 如果更改相對較小，可以直接在 GitHub 上開啟 pull request 以供專案提交者審查和合並。對於較大的更改，請先開啟一個 issue 來提出提案進行討論。請參閱 PyTorch 貢獻者 Wiki 以獲取貢獻指南。
問：我能否成為專案提交者？ 不幸的是，目前 PyTorch 的提交流程涉及與 Facebook 基礎設施的互動，這隻能由 Facebook 員工觸發。然而，我們正在探索將提交者基礎擴充套件到 Facebook 以外的個人，並在工具允許時提供更新。
問：如果我想在會議或其他場合提供 PyTorch 教程，我需要“正式”成為提交者才能做到嗎？ 不需要，我們鼓勵社群成員在任何他們可以的地方展示他們的工作。請聯絡 marketing@pytorch.org 獲取市場營銷支援。
