Mojo 開源貢獻全流程指南從 Issue 表明意圖到 Nightly 發布的五個階段【免費下載鏈接】mojoThe Modular Platform (includes MAX Mojo)項目地址: https://gitcode.com/GitHub_Trending/mo/mojo本指南以倉庫中的 contribution-process.md 為骨架系統梳理向 Mojo 提交代碼貢獻的完整流程從確認貢獻區域、在 GitHub Issue 中表明意圖到制定實現計劃、編寫測試與代碼、通過評審最終經由!sync合入并在 Nightly 版本中發布。讀完本文你將掌握 Mojo 社區貢獻的準入條件、每個階段的明確動作與驗收標準以及大型變更應走的提案流程proposal-process.md并能在倉庫中對應找到每一步的落地證據構建命令、測試命令、標簽與機器人注釋等。貢獻流程概覽Mojo 的代碼貢獻被劃分為五個階段文檔 contribution-process.md 依次描述如下階段目標關鍵產物 / 動作Stage 1: Prerequisites前置準備確認貢獻區域開放并表明意圖閱讀貢獻區域說明創建或認領 GitHub IssueStage 2: Planning規劃研究現有實現達成方案共識實現計劃implementation planaccepted標簽Stage 3: Implementation實現提交帶測試的代碼測試覆蓋PR 描述中寫closes #issue-numberStage 4: Review評審社區評審 Modular 團隊批準Modular 團隊成員批準方可合并Stage 5: Merge and release合并與發布同步進內部 monorepo 并隨 Nightly 發布注釋!syncmerged externally/merged internally標簽整個過程與 Mojo/CONTRIBUTING.md、根目錄 CONTRIBUTING.md 相互銜接前者是 Mojo 貢獻者的總覽入口后者補充了 fork、分支、格式化、評審時效與后臺同步機制的細節。階段 1前置準備確認貢獻區域處于開放狀態動手實現之前第一步是確認你想改進的代碼區域是否開放接收貢獻。當前倉庫中 contribution-areas.md 明確給出了各區域的開放情況編譯器Compiler暫不接收貢獻。源碼開放可讀、可構建、可提 Issue但在貢獻流程成熟前不接受針對編譯器的 Pull Request標準庫Standard library目前接收的變更類型包括——帶測試/基準復現的良好文檔化 Bug 修復、不犧牲可讀性與可維護性且附帶基準的性能改進、標準庫文檔改進、測試覆蓋改進、將測試從FileCheck遷移到testing模塊的assert_*函數、以及安全問題修復明確不接收的類型包括無測試的代碼尤其是核心原語、破壞既有 API 或隱式行為語義的變更、為冷門平臺增加支持、向代碼庫添加依賴、大范圍格式化或重構、未經提案流程新增整個模塊等。如果貢獻屬于標準庫后續的開發細節構建、測試、風格見 stdlib-development.md 與 stdlib-code-style.md。通過 Issue 表明意圖確保存在一個描述你打算修復的 Bug 或新增功能的 GitHub Issue。這向其他貢獻者傳遞了這項工作已有人在做的信號避免重復勞動。具體要求創建新 Issue 前先搜索既有 Issue避免重復開 Issue 時遵循 issue-pr-etiquette.md 中的約定。根目錄 CONTRIBUTING.md 對什么樣的變更可以不先開 Issue給出了更細的界定小且明顯的修復文檔/注釋中的拼寫與語法錯誤、一兩行且有明確根因和清晰測試的 Bug 修復、局部文檔澄清可以直接提 PR除此之外——新 API、重構、性能工作、行為變更、觸碰公共接口、或超過約 100 行的改動——都建議先開 Issue 溝通。拿不準時就先開 Issue。階段 2規劃研究現有實現Mojo 團隊認為開源軟件開發帶來的學習機會很有價值建議花時間理解你要修復內容相關的既有代碼。文檔特別注明可以使用 AI 輔助研究代碼庫但在你打開 PR 時應能夠在無人輔助的情況下與團隊就你所提議的變更展開設計層面的討論。這也與倉庫根目錄 AI_TOOL_POLICY.md 以及 issue-pr-etiquette.md 中所有輸出都必須供人類消費你對輸出全權負責的要求一脈相承。制定并發布實現計劃一旦有了解決方案的思路團隊強烈建議在 GitHub Issue 上發布實現計劃發布計劃給了他人評論的機會在投入具體實現前就設計達成共識在高層面評審和調整一個計劃遠比評審一個完成品實現要省時。Modular 團隊在方案達成一致時會給 Issue 打上accepted標簽表示我們已準備好接收對應的 PR。[!NOTE] 你可以在 Issue 被標記accepted之前就提交 PR。但如果你的變更是非平凡non-trivial的且關聯 Issue 尚未被接受該 PR 被評審或批準的可能性會顯著降低。根目錄 CONTRIBUTING.md 進一步說明了維護者的響應機制維護者會通過添加accepted標簽或留言給出可以開始的信號如果你提交了非平凡 PR 卻沒有關聯已獲批準的 Issue團隊可能請你暫停 PR 并先補 Issue以便對齊方案——這不是拒絕而是為了讓你的工作在評審中落地而不是停滯。階段 3實現為變更編寫測試文檔對實現方式本身不做規定We arent prescriptive about how you arrive at your changes但有兩條硬性要求請為新增或修改的代碼提供合理覆蓋的測試。沒有測試的 PR 極不可能被合并如果不確定如何測試可以在 PR 中直接說明例如 I have not added tests, not sure how to test this capability團隊會樂意與你協作。對于標準庫stdlib-development.md 給出了對應的落地命令# 構建標準庫 ./bazelw build //Mojo/stdlib/... # 運行標準庫全部測試 ./bazelw test //Mojo/stdlib/test/... # 只跑某個子目錄的測試 ./bazelw test //Mojo/stdlib/test/math/... # 列出所有測試目標 ./bazelw query tests(//Mojo/stdlib/...)測試構建時斷言是開啟的編譯參數帶-D ASSERTall會激活標準庫中所有debug_assert因此一個在 release 構建中被跳過的斷言也可能導致測試失敗個別測試文件通過其BUILD.bazel中的_DISABLED_ASSERTIONS列表選擇退出。另外如果本地安裝了pixi可以直接用pixi run tests ./stdlib/test/bit/test_bit.mojo運行標準庫測試該腳本會自動執行等價的 bazelw 命令。對每一行代碼負責并在 PR 中關聯 Issue打開 PR 時你應當準備好在技術上全權負責提交的每一行代碼以及 PR 描述本身詳細約定見 issue-pr-etiquette.md在 PR 描述正文中加上closes #issue-number便于維護者一眼看出該 PR 關聯的 GitHub Issue。結合 issue-pr-etiquette.md 中的協作紀律實現階段還應遵守新貢獻者最多同時打開2 個并發 PR每個 PR 盡量小打開 PR 時檢查 GitHub 顯示的修改行數超過 100 行盡量拆分為多個 PR可獨立則更佳不要為了變小而刪掉測試或 docstring。小 PR 帶來的好處包括更高質量的評審、更快的整體評審、避免有效變更被阻塞、更少的合并沖突以及支持評審并行處理。提交前格式化與本地驗證根目錄 CONTRIBUTING.md 要求變更在提交前完成格式化否則 CI 的 lint/格式化檢查會失敗。倉庫根目錄的bazelw包裝腳本見 bazel/docs/usage.md 了解倉庫的 Bazel 用法提供了格式化入口./bazelw run format建議安裝pre-commit鉤子讓每次提交自動格式化pixi x pre-commit install如果在 GitHub UI 上提交導致鉤子未生效可手動執行pixi x pre-commit run --all-files。提交前還應運行受影響區域的測試、在改動涉及共享基礎設施時跑更廣的回歸測試并以維護者的視角審閱自己的 diff。階段 4評審評審過程被視為一種交互式學習的絕佳方式任何有見地的人都可以評審 PR社區成員的 constructive review 受到積極鼓勵評審過程中請保持耐心并遵守 issue-pr-etiquette.md社區評審中的參與要求包括全程以真人身份出席在線互動、假定善意assume positive intent、所有輸出代碼、注釋、實現計劃、評論都必須簡潔清晰、能夠為 diff 中的每一行辯護——即使錯誤來自 AI責任也在你自身。[!IMPORTANT]任何 PR 合并進代碼庫之前都必須獲得 Modular 團隊成員的批準。關于評審時效根目錄 CONTRIBUTING.md 給出了明確的承諾存在高貢獻量、維護者休假等例外情況PR 首次評審提交后 3 周內給出首次評審或反饋通常可能更快后續評審貢獻者回應反饋后通常在 5 個工作日內復審新 Issue提交后 10 天內完成標記與確認提案Proposal團隊在提交后 6 周內完成評審與討論。階段 5合并與發布這是 Mojo 特有的外部倉庫 內部 monorepo雙軌合并機制。當 PR 獲得批準后Modular 團隊成員在 PR 上注釋!sync該 Issue 被打上merged externally標簽modular/modular上的 PR 被關閉一個對應的 PR 在 Modular 的內部 monorepo 中打開通過內部 CI 后合并合并后添加merged internally標簽你的提交隨下一個 nightly 版本出現在modular/modular上。根目錄 CONTRIBUTING.md 的 Behind the scenes 部分補充了這一機制的實現細節可與上述流程相互印證倉庫使用Copybara工具在內部與外部倉庫之間同步變更你會看到名為 Modularbot 的機器人評論 PR 狀態Synced internally變更已同步進內部倉庫、Merged internally已在內部倉庫合并、Merged externally已隨最新 nightly 上線到main分支你的 GitHub 用戶名與 PR 號通過提交元數據保留例如ORIGINAL_AUTHOR...、PUBLIC_PR_LINK...本倉庫幾乎每天在 ET 時間約凌晨 2 點與內部倉庫同步一次因此main分支可能比內部倉庫滯后最多約 24 小時阻塞性發布失敗時可能更久合并后的變更通常會在合并后一兩天內出現在下一個 nightly 構建或文檔站點中。大型變更走提案流程如果你的變更不在 contribution-areas.md 所列的我們接受的變更范圍內即屬于重大變更第一步應當是提交書面提案proposal。根據 proposal-process.md一份提案就是一個向倉庫proposals/目錄新增文檔的 GitHub PR——倉庫中已存在大量歷史提案如value-ownership.md、pattern-matching.md、enums.md等可作為格式參考按 contribution-process.md 打開提案 PR并在討論中遵循 issue-pr-etiquette.md提案由 Mojo 標準庫負責人leads裁決負責人批準、所有阻塞性問題已決定、相關決定已納入后提案 PR 即可合并若被推遲或拒絕負責評審的 lead 會說明原因并關閉 PR提案評審比普通代碼變更耗時更長團隊目標是在提交后 6 周內完成評審與討論。提案流程的價值在于讓最廣泛的社區成員有機會反饋同時作為過去提案及其決策理由的審計日志。相關文檔導航圍繞貢獻流程倉庫 Mojo/docs/contributing/ 下還有以下配套文檔可按需深入contribution-areas.md哪些代碼區域接收貢獻、各區域接收哪些類型的變更issue-pr-etiquette.mdIssue/PR 互動規范、AI 輔助貢獻規則與 PR 大小要求proposal-process.md重大變更的提案流程與裁決機制stdlib-development.md標準庫開發環境搭建、構建與測試stdlib-code-style.md 與 docstring-style-guide.md標準庫代碼風格與 API 文檔docstring寫作規范compiler/README.md編譯器貢獻文檔入口指向 WorkingInOSRepo.md、testing.md 等編譯器的構建、測試與調試資料根目錄 CONTRIBUTING.mdfork、分支、PR 創建、評審時效與后臺同步機制的全流程細節以及 CODE_OF_CONDUCT.md 與 AI_TOOL_POLICY.md 兩項必須事先閱讀的規范。一句話總結先確認 contribution-areas.md 中你的目標區域開放與否通過 Issue 表明意圖并與維護者達成accepted共識然后帶測試地實現小而有質量的 PR遵守評審紀律最終你的代碼將以!sync為起點經由內部 monorepo 的 CI 校驗后隨下一個 nightly 與所有 Mojo 用戶見面。【免費下載鏈接】mojoThe Modular Platform (includes MAX Mojo)項目地址: https://gitcode.com/GitHub_Trending/mo/mojo創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Mojo 開源貢獻全流程指南：從 Issue 表明意圖到 Nightly 發布的五個階段
Mojo 開源貢獻全流程指南從 Issue 表明意圖到 Nightly 發布的五個階段【免費下載鏈接】mojoThe Modular Platform (includes MAX Mojo)項目地址: https://gitcode.com/GitHub_Trending/mo/mojo本指南以倉庫中的 contribution-process.md 為骨架系統梳理向 Mojo 提交代碼貢獻的完整流程從確認貢獻區域、在 GitHub Issue 中表明意圖到制定實現計劃、編寫測試與代碼、通過評審最終經由!sync合入并在 Nightly 版本中發布。讀完本文你將掌握 Mojo 社區貢獻的準入條件、每個階段的明確動作與驗收標準以及大型變更應走的提案流程proposal-process.md并能在倉庫中對應找到每一步的落地證據構建命令、測試命令、標簽與機器人注釋等。貢獻流程概覽Mojo 的代碼貢獻被劃分為五個階段文檔 contribution-process.md 依次描述如下階段目標關鍵產物 / 動作Stage 1: Prerequisites前置準備確認貢獻區域開放并表明意圖閱讀貢獻區域說明創建或認領 GitHub IssueStage 2: Planning規劃研究現有實現達成方案共識實現計劃implementation planaccepted標簽Stage 3: Implementation實現提交帶測試的代碼測試覆蓋PR 描述中寫closes #issue-numberStage 4: Review評審社區評審 Modular 團隊批準Modular 團隊成員批準方可合并Stage 5: Merge and release合并與發布同步進內部 monorepo 并隨 Nightly 發布注釋!syncmerged externally/merged internally標簽整個過程與 Mojo/CONTRIBUTING.md、根目錄 CONTRIBUTING.md 相互銜接前者是 Mojo 貢獻者的總覽入口后者補充了 fork、分支、格式化、評審時效與后臺同步機制的細節。階段 1前置準備確認貢獻區域處于開放狀態動手實現之前第一步是確認你想改進的代碼區域是否開放接收貢獻。當前倉庫中 contribution-areas.md 明確給出了各區域的開放情況編譯器Compiler暫不接收貢獻。源碼開放可讀、可構建、可提 Issue但在貢獻流程成熟前不接受針對編譯器的 Pull Request標準庫Standard library目前接收的變更類型包括——帶測試/基準復現的良好文檔化 Bug 修復、不犧牲可讀性與可維護性且附帶基準的性能改進、標準庫文檔改進、測試覆蓋改進、將測試從FileCheck遷移到testing模塊的assert_*函數、以及安全問題修復明確不接收的類型包括無測試的代碼尤其是核心原語、破壞既有 API 或隱式行為語義的變更、為冷門平臺增加支持、向代碼庫添加依賴、大范圍格式化或重構、未經提案流程新增整個模塊等。如果貢獻屬于標準庫后續的開發細節構建、測試、風格見 stdlib-development.md 與 stdlib-code-style.md。通過 Issue 表明意圖確保存在一個描述你打算修復的 Bug 或新增功能的 GitHub Issue。這向其他貢獻者傳遞了這項工作已有人在做的信號避免重復勞動。具體要求創建新 Issue 前先搜索既有 Issue避免重復開 Issue 時遵循 issue-pr-etiquette.md 中的約定。根目錄 CONTRIBUTING.md 對什么樣的變更可以不先開 Issue給出了更細的界定小且明顯的修復文檔/注釋中的拼寫與語法錯誤、一兩行且有明確根因和清晰測試的 Bug 修復、局部文檔澄清可以直接提 PR除此之外——新 API、重構、性能工作、行為變更、觸碰公共接口、或超過約 100 行的改動——都建議先開 Issue 溝通。拿不準時就先開 Issue。階段 2規劃研究現有實現Mojo 團隊認為開源軟件開發帶來的學習機會很有價值建議花時間理解你要修復內容相關的既有代碼。文檔特別注明可以使用 AI 輔助研究代碼庫但在你打開 PR 時應能夠在無人輔助的情況下與團隊就你所提議的變更展開設計層面的討論。這也與倉庫根目錄 AI_TOOL_POLICY.md 以及 issue-pr-etiquette.md 中所有輸出都必須供人類消費你對輸出全權負責的要求一脈相承。制定并發布實現計劃一旦有了解決方案的思路團隊強烈建議在 GitHub Issue 上發布實現計劃發布計劃給了他人評論的機會在投入具體實現前就設計達成共識在高層面評審和調整一個計劃遠比評審一個完成品實現要省時。Modular 團隊在方案達成一致時會給 Issue 打上accepted標簽表示我們已準備好接收對應的 PR。[!NOTE] 你可以在 Issue 被標記accepted之前就提交 PR。但如果你的變更是非平凡non-trivial的且關聯 Issue 尚未被接受該 PR 被評審或批準的可能性會顯著降低。根目錄 CONTRIBUTING.md 進一步說明了維護者的響應機制維護者會通過添加accepted標簽或留言給出可以開始的信號如果你提交了非平凡 PR 卻沒有關聯已獲批準的 Issue團隊可能請你暫停 PR 并先補 Issue以便對齊方案——這不是拒絕而是為了讓你的工作在評審中落地而不是停滯。階段 3實現為變更編寫測試文檔對實現方式本身不做規定We arent prescriptive about how you arrive at your changes但有兩條硬性要求請為新增或修改的代碼提供合理覆蓋的測試。沒有測試的 PR 極不可能被合并如果不確定如何測試可以在 PR 中直接說明例如 I have not added tests, not sure how to test this capability團隊會樂意與你協作。對于標準庫stdlib-development.md 給出了對應的落地命令# 構建標準庫 ./bazelw build //Mojo/stdlib/... # 運行標準庫全部測試 ./bazelw test //Mojo/stdlib/test/... # 只跑某個子目錄的測試 ./bazelw test //Mojo/stdlib/test/math/... # 列出所有測試目標 ./bazelw query tests(//Mojo/stdlib/...)測試構建時斷言是開啟的編譯參數帶-D ASSERTall會激活標準庫中所有debug_assert因此一個在 release 構建中被跳過的斷言也可能導致測試失敗個別測試文件通過其BUILD.bazel中的_DISABLED_ASSERTIONS列表選擇退出。另外如果本地安裝了pixi可以直接用pixi run tests ./stdlib/test/bit/test_bit.mojo運行標準庫測試該腳本會自動執行等價的 bazelw 命令。對每一行代碼負責并在 PR 中關聯 Issue打開 PR 時你應當準備好在技術上全權負責提交的每一行代碼以及 PR 描述本身詳細約定見 issue-pr-etiquette.md在 PR 描述正文中加上closes #issue-number便于維護者一眼看出該 PR 關聯的 GitHub Issue。結合 issue-pr-etiquette.md 中的協作紀律實現階段還應遵守新貢獻者最多同時打開2 個并發 PR每個 PR 盡量小打開 PR 時檢查 GitHub 顯示的修改行數超過 100 行盡量拆分為多個 PR可獨立則更佳不要為了變小而刪掉測試或 docstring。小 PR 帶來的好處包括更高質量的評審、更快的整體評審、避免有效變更被阻塞、更少的合并沖突以及支持評審并行處理。提交前格式化與本地驗證根目錄 CONTRIBUTING.md 要求變更在提交前完成格式化否則 CI 的 lint/格式化檢查會失敗。倉庫根目錄的bazelw包裝腳本見 bazel/docs/usage.md 了解倉庫的 Bazel 用法提供了格式化入口./bazelw run format建議安裝pre-commit鉤子讓每次提交自動格式化pixi x pre-commit install如果在 GitHub UI 上提交導致鉤子未生效可手動執行pixi x pre-commit run --all-files。提交前還應運行受影響區域的測試、在改動涉及共享基礎設施時跑更廣的回歸測試并以維護者的視角審閱自己的 diff。階段 4評審評審過程被視為一種交互式學習的絕佳方式任何有見地的人都可以評審 PR社區成員的 constructive review 受到積極鼓勵評審過程中請保持耐心并遵守 issue-pr-etiquette.md社區評審中的參與要求包括全程以真人身份出席在線互動、假定善意assume positive intent、所有輸出代碼、注釋、實現計劃、評論都必須簡潔清晰、能夠為 diff 中的每一行辯護——即使錯誤來自 AI責任也在你自身。[!IMPORTANT]任何 PR 合并進代碼庫之前都必須獲得 Modular 團隊成員的批準。關于評審時效根目錄 CONTRIBUTING.md 給出了明確的承諾存在高貢獻量、維護者休假等例外情況PR 首次評審提交后 3 周內給出首次評審或反饋通常可能更快后續評審貢獻者回應反饋后通常在 5 個工作日內復審新 Issue提交后 10 天內完成標記與確認提案Proposal團隊在提交后 6 周內完成評審與討論。階段 5合并與發布這是 Mojo 特有的外部倉庫 內部 monorepo雙軌合并機制。當 PR 獲得批準后Modular 團隊成員在 PR 上注釋!sync該 Issue 被打上merged externally標簽modular/modular上的 PR 被關閉一個對應的 PR 在 Modular 的內部 monorepo 中打開通過內部 CI 后合并合并后添加merged internally標簽你的提交隨下一個 nightly 版本出現在modular/modular上。根目錄 CONTRIBUTING.md 的 Behind the scenes 部分補充了這一機制的實現細節可與上述流程相互印證倉庫使用Copybara工具在內部與外部倉庫之間同步變更你會看到名為 Modularbot 的機器人評論 PR 狀態Synced internally變更已同步進內部倉庫、Merged internally已在內部倉庫合并、Merged externally已隨最新 nightly 上線到main分支你的 GitHub 用戶名與 PR 號通過提交元數據保留例如ORIGINAL_AUTHOR...、PUBLIC_PR_LINK...本倉庫幾乎每天在 ET 時間約凌晨 2 點與內部倉庫同步一次因此main分支可能比內部倉庫滯后最多約 24 小時阻塞性發布失敗時可能更久合并后的變更通常會在合并后一兩天內出現在下一個 nightly 構建或文檔站點中。大型變更走提案流程如果你的變更不在 contribution-areas.md 所列的我們接受的變更范圍內即屬于重大變更第一步應當是提交書面提案proposal。根據 proposal-process.md一份提案就是一個向倉庫proposals/目錄新增文檔的 GitHub PR——倉庫中已存在大量歷史提案如value-ownership.md、pattern-matching.md、enums.md等可作為格式參考按 contribution-process.md 打開提案 PR并在討論中遵循 issue-pr-etiquette.md提案由 Mojo 標準庫負責人leads裁決負責人批準、所有阻塞性問題已決定、相關決定已納入后提案 PR 即可合并若被推遲或拒絕負責評審的 lead 會說明原因并關閉 PR提案評審比普通代碼變更耗時更長團隊目標是在提交后 6 周內完成評審與討論。提案流程的價值在于讓最廣泛的社區成員有機會反饋同時作為過去提案及其決策理由的審計日志。相關文檔導航圍繞貢獻流程倉庫 Mojo/docs/contributing/ 下還有以下配套文檔可按需深入contribution-areas.md哪些代碼區域接收貢獻、各區域接收哪些類型的變更issue-pr-etiquette.mdIssue/PR 互動規范、AI 輔助貢獻規則與 PR 大小要求proposal-process.md重大變更的提案流程與裁決機制stdlib-development.md標準庫開發環境搭建、構建與測試stdlib-code-style.md 與 docstring-style-guide.md標準庫代碼風格與 API 文檔docstring寫作規范compiler/README.md編譯器貢獻文檔入口指向 WorkingInOSRepo.md、testing.md 等編譯器的構建、測試與調試資料根目錄 CONTRIBUTING.mdfork、分支、PR 創建、評審時效與后臺同步機制的全流程細節以及 CODE_OF_CONDUCT.md 與 AI_TOOL_POLICY.md 兩項必須事先閱讀的規范。一句話總結先確認 contribution-areas.md 中你的目標區域開放與否通過 Issue 表明意圖并與維護者達成accepted共識然后帶測試地實現小而有質量的 PR遵守評審紀律最終你的代碼將以!sync為起點經由內部 monorepo 的 CI 校驗后隨下一個 nightly 與所有 Mojo 用戶見面。【免費下載鏈接】mojoThe Modular Platform (includes MAX Mojo)項目地址: https://gitcode.com/GitHub_Trending/mo/mojo創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考