Megatron-LM 开源贡献实战指南Issue 政策、DCO 签名、代码提交规范与 PR 评审流程【免费下载链接】Megatron-LMOngoing research training transformer models at scale项目地址: https://gitcode.com/GitHub_Trending/me/Megatron-LM本文为 NVIDIA Megatron-LM 项目的贡献者技术指南完整梳理官方贡献文档docs/developer/contribute.md定义的 Issue 提交政策、代码提交 Do/Dont 规范与 DCO 签名要求并结合仓库中的 Issue/PR 模板、自动格式化脚本与 CI 工作流讲解从发现问题到 PR 合入main的完整工程流程。读完后你可以按规范提交 Bug/回归/功能请求 Issue、以原子化提交和正确签名通过仓库门禁并理解 PR 从 Draft 到 Final Review、Approved 的自动化评审链路。1. 贡献政策总览先对齐项目方向Megatron-LM 已从一个内部仓库迁移为直接在 GitHub 上开展全部开发的项目任何人都可以参与贡献。官方文档给出的核心原则是变更必须与项目方向一致小型 Bug 修复始终受欢迎如果提议大型架构变更或纯粹风格性修改必须先开一个 Issue 进行讨论参见 docs/developer/contribute.md。这一原则在 PR 模板中同样被反复强调.github/pull_request_template.md明确警告对于主要变更无论是代码行数还是影响面请先与团队分享设计文档如果不确定如何分享请联系NVIDIA/mcore-oncall。也就是说先讨论、后动手不是建议而是仓库层面的硬性流程约束。仓库中还配套了若干自动化工具链支撑这套政策贡献者需要了解的关键文件包括文件/目录作用.github/ISSUE_TEMPLATE/Bug、回归、功能请求、提问四类 Issue 模板.github/pull_request_template.mdPR 描述模板内含自检清单与评审流程说明.github/oncall_schedule.json每周轮换的 oncall 值班表NVIDIA/mcore-oncall团队tools/autoformat.sh自动格式化脚本PR 自检项之一.github/workflows/copyright-check.ymlCI 版权头检查工作流.github/workflows/close-inactive-issue-pr.yml定时清理不活跃 Issue/PR 的 stale 工作流2. Issue 政策模板选择与写作要求2.1 四类 Issue 模板官方文档按场景给出了明确的模板选择规则仓库中 .github/ISSUE_TEMPLATE/ 目录下的四个模板文件与之逐一对应场景官方要求仓库模板自动打标签发现不符合预期的功能使用BUG模板.github/ISSUE_TEMPLATE/bug_report.mdbug速度或精度回归使用REGRESSION模板.github/ISSUE_TEMPLATE/regression.md标题前缀[REGRESSION]请求新功能或修改现有功能使用ENHANCEMENT模板.github/ISSUE_TEMPLATE/feature_request.mdenhancement提问不需要模板但问题要尽量清晰简洁.github/ISSUE_TEMPLATE/question.md标题前缀[QUESTION]值得注意的两个细节空白 Issue 已被禁用。.github/ISSUE_TEMPLATE/config.yml 中设置了blank_issues_enabled: false即贡献者必须选择上述模板之一无法提交无模板的自由文本 Issue。回归模板对证据要求最严格。regression.md 要求提供之前的性能/精度与更新后的性能/精度的量化对比、可复现步骤以及环境信息——包括变更前后两个 Megatron-LM commit ID 和前后 PyTorch 版本。这与官方文档中可复现的 Bug 会得到开发团队最快的响应完全呼应。2.2 Issue 写作纪律官方文档还给出了一条可直接执行的写作清单贡献者应当逐条对照一个 Issue 只报一个 Bug。把多件事塞进同一个 Issue 会让讨论和完成都变得不必要地复杂。可复现的 Bug 最快得到关注——Bug 模板中甚至内置了对最小化 Bug 报告方法的提示要求列出最少的复现步骤或代码片段。使用正确的拼写、语法和标点以权威、技术性的口吻书写。3. 代码提交规范Do / Dont 完整清单官方文档的 Code Submission Policy 一节约束力很强可以拆成提交风格、提交历史与内容边界三个维度。3.1 必须做Do风格一致新代码的风格要与被修改的文件保持一致。Megatron-LM 目前没有尚未风格指南或强制格式化工具跟随文件现状就是规范。docstring 规范使用文档生成器所配置的 docstring 风格——Google 风格注释 MyST 格式。这一点有源码级证据docs/conf.py 中 Sphinx 扩展列表包含myst_parser用于 Markdown 文档和sphinx.ext.napoleonFor google style docstrings即 Google 风格 docstring 解析并设置了myst_heading_anchors 5、autodoc2_render_plugin myst。因此新写 docstring 时用 Google 风格Args:、Returns:等段落是能被文档流水线正确渲染的前提。原子化提交把变更拆分为独立的原子提交即一个 feature 或一个 fix 对应一个 commit。rebase 到main确保你的提交基于main分支 rebase 过。commit message 用祈使句写 Change the default argument for X而不是 Changed the default argument for X。commit message 用规范的英文书写并注意代码、注释与提交信息中的拼写。3.2 禁止做Dont提交与项目 License 不兼容的代码。触碰 PR 声明范围之外的任何内容——包括对与 PR 无关代码的格式化修改。这一条配合 tools/autoformat.sh 使用该脚本默认只处理megatron/core与tests/下相对main分支有变更的.py文件git diff --name-only --merge-base autoformatter-remote/main过滤因此顺手格式化无关文件既违反政策也可能污染 diff。在多个提交间过度迭代你的设计。包含被注释掉的代码。在未先开 Issue 讨论的情况下尝试大型架构变更。3.3 版权头检查PR 模板的自检清单要求 PR 作者声明已对改动做过个人逐行审查而仓库还通过 CI 强制版权头合规.github/workflows/copyright-check.yml 在pull-request/*分支推送和merge_group事件上触发复用统一的版权检查模板作业仓库内另有 tools/check_copyright.py 与 tools/copyright.sh 提供本地等价检查。新建文件时缺少 NVIDIA 版权头会直接被 CI 拦截这也是不要提交与项目 License 不兼容代码这条政策的自动化落地方式。4. 签署你的工作DCO 签名要求官方文档对 DCODeveloper Certificate of Origin签名的要求是硬性门槛任何包含未签署 commit 的贡献都不会被接受。4.1 如何签署提交时使用--signoff或-s选项git commit -s -m Add cool feature.这会在你的 commit message 末尾追加Signed-off-by: Your Name youremail.com4.2 DCO 全文Version 1.1贡献者签署即代表做出以下认证全文引自 docs/developer/contribute.mdDeveloper Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developers Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.其中 (a)/(b)/(c) 分别覆盖原创工作、基于既有开源作品的再创作和原样转交他人已认证工作三种情形(d) 则确认贡献者知悉贡献记录含签名中的个人信息将被无限期保留。5. PR 评审流程从 Draft 到 Approved 的自动化链路官方文档的 QA 部分描述了人工响应约定而仓库中的 .github/pull_request_template.md 进一步揭示了 PR 的完整生命周期。两条信息源合起来可以还原出如下流程所有 PR 一律从 Draft 开始。如果你直接开了非 Draft PR机器人会自动将其转回 Draft模板中明确说明 All PRs start as draft。社区贡献者的 Issue 追踪要求新功能的 PR 必须链接一个已开出的 feature request Issue小型更新Bug 修复、小改进则建议链接 Issue可加速评审。PR 自检清单Pre-checks模板要求逐项确认已添加相关单元测试已添加相关功能测试代码已添加类型标注已添加相关文档已在 PR 上运行过 tools/autoformat.sh。Step 1 — 标记 Ready for Review解决 merge 冲突且 CI 通过后才能标记 Ready此时 oncall 评审人会被自动指派专家评审人根据改动范围被通知由 .github/CODEOWNERS 决定哪些 PR 直接进入下一步。Step 2 — Final Review对修改了megatron/core的 PR在全部专家评审人批准后会自动打上Final Review标签并指派最终评审人megatron/core之外的 PR 跳过此步。Step 3 — Approved所有必需评审人批准后自动打上Approved标签。合入mcore-engineers 团队成员可以将 PR 合入main。模板同时给出了一条效率建议PR 越简单批准和合并越快可以随时消息或评论NVIDIA/mcore-oncall以加速合入。这与第 3 节原子化提交、不触碰范围外代码的纪律一脉相承——PR 的复杂度直接决定其合入速度。6. QA响应时间、求助与 stale 政策6.1 响应时间与求助渠道官方文档承诺Issue 和 PR 应在两个工作日内收到回复。求助和升级渠道统一为NVIDIA/mcore-oncall团队——Issue 模板中也都内置了Tag NVIDIA/mcore-oncall to get oncalls attention的提示。该团队的值班安排由 .github/oncall_schedule.json 维护采用每周轮换制仓库还配有 oncall-rotation.yml、oncall-assign.yml 等工作流自动化轮换与指派。6.2 升级不响应的 Issue/PR两个工作日后仍无响应的 Issue 或 PR直接 tagNVIDIA/mcore-oncall升级。6.3 Stale Issue 与 PR 政策机器人会在 PR60 天未处理后将其标记为 stale。仓库层面这一机制由 .github/workflows/close-inactive-issue-pr.yml 承载该工作流以每日定时任务cron: 30 1 * * *触发复用统一的 close inactive issue/pr 模板作业。项目存在一个可追溯到数年前的 Issue/PR 积压队列分诊triage是从新到旧反向推进的。较旧的、可能仍然相关的 Issue 会收到请用最新代码重新测试的请求若无回应该 Issue 可能被关闭。如需重开直接回复一条评论即可。7. 贡献自查清单速查结合官方文档与仓库自动化配置提交前可用以下清单快速自查大型架构变更/风格性修改是否已先开 Issue 讨论Issue 是否选对了模板BUG / REGRESSION / ENHANCEMENT / 无模板提问且一个 Issue 只含一个问题提交是否为原子化、rebase 到main、commit message 用祈使句且拼写无误docstring 是否为 Google 风格保证 docs/conf.py 的 Sphinx/MyST 流水线可正确渲染是否已运行 tools/autoformat.sh且未触碰 PR 范围外的文件每个 commit 是否都带了Signed-off-bygit commit -sPR 自检清单单测、功能测试、typing、文档、autoformat是否全部勾选且 PR 保持在 Draft 直到 CI 通过、冲突解决按这份清单执行贡献就能以最小摩擦通过 Megatron-LM 的人工评审与 CI 自动化双重门禁。【免费下载链接】Megatron-LMOngoing research training transformer models at scale项目地址: https://gitcode.com/GitHub_Trending/me/Megatron-LM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Megatron-LM 开源贡献实战指南：Issue 政策、DCO 签名、代码提交规范与 PR 评审流程
Megatron-LM 开源贡献实战指南Issue 政策、DCO 签名、代码提交规范与 PR 评审流程【免费下载链接】Megatron-LMOngoing research training transformer models at scale项目地址: https://gitcode.com/GitHub_Trending/me/Megatron-LM本文为 NVIDIA Megatron-LM 项目的贡献者技术指南完整梳理官方贡献文档docs/developer/contribute.md定义的 Issue 提交政策、代码提交 Do/Dont 规范与 DCO 签名要求并结合仓库中的 Issue/PR 模板、自动格式化脚本与 CI 工作流讲解从发现问题到 PR 合入main的完整工程流程。读完后你可以按规范提交 Bug/回归/功能请求 Issue、以原子化提交和正确签名通过仓库门禁并理解 PR 从 Draft 到 Final Review、Approved 的自动化评审链路。1. 贡献政策总览先对齐项目方向Megatron-LM 已从一个内部仓库迁移为直接在 GitHub 上开展全部开发的项目任何人都可以参与贡献。官方文档给出的核心原则是变更必须与项目方向一致小型 Bug 修复始终受欢迎如果提议大型架构变更或纯粹风格性修改必须先开一个 Issue 进行讨论参见 docs/developer/contribute.md。这一原则在 PR 模板中同样被反复强调.github/pull_request_template.md明确警告对于主要变更无论是代码行数还是影响面请先与团队分享设计文档如果不确定如何分享请联系NVIDIA/mcore-oncall。也就是说先讨论、后动手不是建议而是仓库层面的硬性流程约束。仓库中还配套了若干自动化工具链支撑这套政策贡献者需要了解的关键文件包括文件/目录作用.github/ISSUE_TEMPLATE/Bug、回归、功能请求、提问四类 Issue 模板.github/pull_request_template.mdPR 描述模板内含自检清单与评审流程说明.github/oncall_schedule.json每周轮换的 oncall 值班表NVIDIA/mcore-oncall团队tools/autoformat.sh自动格式化脚本PR 自检项之一.github/workflows/copyright-check.ymlCI 版权头检查工作流.github/workflows/close-inactive-issue-pr.yml定时清理不活跃 Issue/PR 的 stale 工作流2. Issue 政策模板选择与写作要求2.1 四类 Issue 模板官方文档按场景给出了明确的模板选择规则仓库中 .github/ISSUE_TEMPLATE/ 目录下的四个模板文件与之逐一对应场景官方要求仓库模板自动打标签发现不符合预期的功能使用BUG模板.github/ISSUE_TEMPLATE/bug_report.mdbug速度或精度回归使用REGRESSION模板.github/ISSUE_TEMPLATE/regression.md标题前缀[REGRESSION]请求新功能或修改现有功能使用ENHANCEMENT模板.github/ISSUE_TEMPLATE/feature_request.mdenhancement提问不需要模板但问题要尽量清晰简洁.github/ISSUE_TEMPLATE/question.md标题前缀[QUESTION]值得注意的两个细节空白 Issue 已被禁用。.github/ISSUE_TEMPLATE/config.yml 中设置了blank_issues_enabled: false即贡献者必须选择上述模板之一无法提交无模板的自由文本 Issue。回归模板对证据要求最严格。regression.md 要求提供之前的性能/精度与更新后的性能/精度的量化对比、可复现步骤以及环境信息——包括变更前后两个 Megatron-LM commit ID 和前后 PyTorch 版本。这与官方文档中可复现的 Bug 会得到开发团队最快的响应完全呼应。2.2 Issue 写作纪律官方文档还给出了一条可直接执行的写作清单贡献者应当逐条对照一个 Issue 只报一个 Bug。把多件事塞进同一个 Issue 会让讨论和完成都变得不必要地复杂。可复现的 Bug 最快得到关注——Bug 模板中甚至内置了对最小化 Bug 报告方法的提示要求列出最少的复现步骤或代码片段。使用正确的拼写、语法和标点以权威、技术性的口吻书写。3. 代码提交规范Do / Dont 完整清单官方文档的 Code Submission Policy 一节约束力很强可以拆成提交风格、提交历史与内容边界三个维度。3.1 必须做Do风格一致新代码的风格要与被修改的文件保持一致。Megatron-LM 目前没有尚未风格指南或强制格式化工具跟随文件现状就是规范。docstring 规范使用文档生成器所配置的 docstring 风格——Google 风格注释 MyST 格式。这一点有源码级证据docs/conf.py 中 Sphinx 扩展列表包含myst_parser用于 Markdown 文档和sphinx.ext.napoleonFor google style docstrings即 Google 风格 docstring 解析并设置了myst_heading_anchors 5、autodoc2_render_plugin myst。因此新写 docstring 时用 Google 风格Args:、Returns:等段落是能被文档流水线正确渲染的前提。原子化提交把变更拆分为独立的原子提交即一个 feature 或一个 fix 对应一个 commit。rebase 到main确保你的提交基于main分支 rebase 过。commit message 用祈使句写 Change the default argument for X而不是 Changed the default argument for X。commit message 用规范的英文书写并注意代码、注释与提交信息中的拼写。3.2 禁止做Dont提交与项目 License 不兼容的代码。触碰 PR 声明范围之外的任何内容——包括对与 PR 无关代码的格式化修改。这一条配合 tools/autoformat.sh 使用该脚本默认只处理megatron/core与tests/下相对main分支有变更的.py文件git diff --name-only --merge-base autoformatter-remote/main过滤因此顺手格式化无关文件既违反政策也可能污染 diff。在多个提交间过度迭代你的设计。包含被注释掉的代码。在未先开 Issue 讨论的情况下尝试大型架构变更。3.3 版权头检查PR 模板的自检清单要求 PR 作者声明已对改动做过个人逐行审查而仓库还通过 CI 强制版权头合规.github/workflows/copyright-check.yml 在pull-request/*分支推送和merge_group事件上触发复用统一的版权检查模板作业仓库内另有 tools/check_copyright.py 与 tools/copyright.sh 提供本地等价检查。新建文件时缺少 NVIDIA 版权头会直接被 CI 拦截这也是不要提交与项目 License 不兼容代码这条政策的自动化落地方式。4. 签署你的工作DCO 签名要求官方文档对 DCODeveloper Certificate of Origin签名的要求是硬性门槛任何包含未签署 commit 的贡献都不会被接受。4.1 如何签署提交时使用--signoff或-s选项git commit -s -m Add cool feature.这会在你的 commit message 末尾追加Signed-off-by: Your Name youremail.com4.2 DCO 全文Version 1.1贡献者签署即代表做出以下认证全文引自 docs/developer/contribute.mdDeveloper Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developers Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.其中 (a)/(b)/(c) 分别覆盖原创工作、基于既有开源作品的再创作和原样转交他人已认证工作三种情形(d) 则确认贡献者知悉贡献记录含签名中的个人信息将被无限期保留。5. PR 评审流程从 Draft 到 Approved 的自动化链路官方文档的 QA 部分描述了人工响应约定而仓库中的 .github/pull_request_template.md 进一步揭示了 PR 的完整生命周期。两条信息源合起来可以还原出如下流程所有 PR 一律从 Draft 开始。如果你直接开了非 Draft PR机器人会自动将其转回 Draft模板中明确说明 All PRs start as draft。社区贡献者的 Issue 追踪要求新功能的 PR 必须链接一个已开出的 feature request Issue小型更新Bug 修复、小改进则建议链接 Issue可加速评审。PR 自检清单Pre-checks模板要求逐项确认已添加相关单元测试已添加相关功能测试代码已添加类型标注已添加相关文档已在 PR 上运行过 tools/autoformat.sh。Step 1 — 标记 Ready for Review解决 merge 冲突且 CI 通过后才能标记 Ready此时 oncall 评审人会被自动指派专家评审人根据改动范围被通知由 .github/CODEOWNERS 决定哪些 PR 直接进入下一步。Step 2 — Final Review对修改了megatron/core的 PR在全部专家评审人批准后会自动打上Final Review标签并指派最终评审人megatron/core之外的 PR 跳过此步。Step 3 — Approved所有必需评审人批准后自动打上Approved标签。合入mcore-engineers 团队成员可以将 PR 合入main。模板同时给出了一条效率建议PR 越简单批准和合并越快可以随时消息或评论NVIDIA/mcore-oncall以加速合入。这与第 3 节原子化提交、不触碰范围外代码的纪律一脉相承——PR 的复杂度直接决定其合入速度。6. QA响应时间、求助与 stale 政策6.1 响应时间与求助渠道官方文档承诺Issue 和 PR 应在两个工作日内收到回复。求助和升级渠道统一为NVIDIA/mcore-oncall团队——Issue 模板中也都内置了Tag NVIDIA/mcore-oncall to get oncalls attention的提示。该团队的值班安排由 .github/oncall_schedule.json 维护采用每周轮换制仓库还配有 oncall-rotation.yml、oncall-assign.yml 等工作流自动化轮换与指派。6.2 升级不响应的 Issue/PR两个工作日后仍无响应的 Issue 或 PR直接 tagNVIDIA/mcore-oncall升级。6.3 Stale Issue 与 PR 政策机器人会在 PR60 天未处理后将其标记为 stale。仓库层面这一机制由 .github/workflows/close-inactive-issue-pr.yml 承载该工作流以每日定时任务cron: 30 1 * * *触发复用统一的 close inactive issue/pr 模板作业。项目存在一个可追溯到数年前的 Issue/PR 积压队列分诊triage是从新到旧反向推进的。较旧的、可能仍然相关的 Issue 会收到请用最新代码重新测试的请求若无回应该 Issue 可能被关闭。如需重开直接回复一条评论即可。7. 贡献自查清单速查结合官方文档与仓库自动化配置提交前可用以下清单快速自查大型架构变更/风格性修改是否已先开 Issue 讨论Issue 是否选对了模板BUG / REGRESSION / ENHANCEMENT / 无模板提问且一个 Issue 只含一个问题提交是否为原子化、rebase 到main、commit message 用祈使句且拼写无误docstring 是否为 Google 风格保证 docs/conf.py 的 Sphinx/MyST 流水线可正确渲染是否已运行 tools/autoformat.sh且未触碰 PR 范围外的文件每个 commit 是否都带了Signed-off-bygit commit -sPR 自检清单单测、功能测试、typing、文档、autoformat是否全部勾选且 PR 保持在 Draft 直到 CI 通过、冲突解决按这份清单执行贡献就能以最小摩擦通过 Megatron-LM 的人工评审与 CI 自动化双重门禁。【免费下载链接】Megatron-LMOngoing research training transformer models at scale项目地址: https://gitcode.com/GitHub_Trending/me/Megatron-LM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考