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