跳转至

MindYOLO 贡献指南

贡献者许可协议

首次向 MindYOLO 社区提交代码前,需签署 CLA。

个人贡献者请参考 ICLA 在线文档 了解详细信息。

入门指南

贡献流程

代码风格

请遵循此风格,以便 MindYOLO 易于审查、维护和开发。

  • 编码指南

MindYOLO 社区使用 Python PEP 8 编码风格 建议的 Python 编码风格和 Google C++ 编码指南 建议的 C++ 编码风格。 CppLintCppCheckCMakeLintCodeSpellLizardShellCheckPyLint 用于检查代码格式,建议在 IDE 中安装这些插件。

  • 单元测试指南

MindYOLO 社区使用 pytest 建议的 Python 单元测试风格和 Googletest Primer 建议的 C++ 单元测试风格。测试用例的设计意图应该通过其注释名称来体现。

  • 重构指南

我们鼓励开发人员重构我们的代码以消除 代码异味。所有代码都应符合编码风格和测试风格的需求,重构代码也不例外。Lizard 对 nloc(无注释的代码行数)的阈值为 100,对 cnc(循环复杂度数)的阈值为 20,当您收到 Lizard 警告时,您必须重构要合并的代码。

  • 文档指南

我们使用 MarkdownLint 检查 markdown 文档的格式。MindYOLO CI 根据默认配置修改了以下规则。

  • MD007(无序列表缩进):indent**参数设置为**4,表示无序列表中的所有内容都需要使用四个空格进行缩进。
  • MD009(行末空格):br_spaces**参数设置为**2,表示行末可以有0个或2个空格。
  • MD029(有序列表的序号):style**参数设置为**ordered,表示有序列表的序号按升序排列。

具体请参见RULES

Fork-Pull开发模式

  • Fork MindYOLO仓库

在向MindYOLO项目提交代码之前,请确保该项目已经fork到你自己的仓库。这意味着MindYOLO 仓库和你自己的仓库之间会并行开发,所以要小心避免两者不一致。

  • 克隆远程仓库

如果要将代码下载到本地机器,git 是最好的方式:

# 对于 GitHub
git clone https://github.com/{insert_your_forked_repo}/mindyolo.git
git remote add upper https://github.com/mindspore-lab/mindyolo.git
  • 本地开发代码

为避免多个分支之间不一致,SUGGESTED 建议签出到新分支:

git checkout -b {new_branch_name} origin/master

以 master 分支为例,MindYOLO 可能会根据需要创建版本分支和下游开发分支,请先修复上游的 bug。 然后你可以任意更改代码。

  • 将代码推送到远程仓库

更新代码后,应以正式方式推送更新:

git add .
git status # 检查更新状态
git commit -m "您的提交标题"
git commit -s --amend #添加提交的具体描述
git push origin {new_branch_name}
  • 将请求拉取到 MindYOLO 仓库

最后一步,您需要将新分支与 MindYOLO master 分支进行比较。完成拉取请求后,Jenkins CI 将自动设置为构建测试。您的拉取请求应尽快合并到上游主分支中,以降低合并风险。

报告问题

为项目做出贡献的一种好方法是在遇到问题时发送详细报告。我们始终欣赏写得好、详尽的错误报告,并会为此感谢您!

报告问题时,请参考以下格式:

  • 您使用的是哪个版本的环境(MindSpore、os、python、MindYOLO 等)?
  • 这是错误报告还是功能请求?
  • 什么类型的问题,请添加标签以在问题仪表板上突出显示它。
  • 发生了什么?
  • 您期望发生什么?
  • 如何重现它?(尽可能简短和准确)
  • 给审阅者的特别说明?

问题咨询:

  • 如果您发现一个未关闭的问题,而这正是您要解决的问题, 请在该问题上发表一些评论,告诉其他人您将负责该问题。
  • 如果问题打开了一段时间, 建议贡献者在解决该问题之前进行预检查。
  • 如果您解决了自己报告的问题, 也需要在关闭该问题之前通知其他人。
  • 如果您希望问题尽快得到回复, 请尝试为其添加标签,您可以在 标签列表 上找到各种标签

提出 PR

  • GitHub 上以 issue 形式提出您的想法

  • 如果是需要大量设计细节的新功能,还应提交设计提案。

  • 在问题讨论和设计提案审查中达成共识后,完成分叉仓库的开发并提交 PR。

  • 任何 PR 都必须收到来自批准者的 2+ LGTM 才能被允许。请注意,批准者不得在自己的 PR 上添加 LGTM

  • PR 经过充分讨论后,将根据讨论结果进行合并、放弃或拒绝。

PR 建议:

  • 应避免任何不相关的更改。
  • 确保您的提交历史记录有序。
  • 始终让您的分支与主分支保持一致。
  • 对于错误修复 PR,请确保所有相关问题都已链接。