代码贡献规范

说明

若项目无特指无需遵守代码贡献规范或制定了独立的规则，则使用本文档所述规范。
本文档是建议性的，但这并不意味着您可以忽略所有内容。

交流

详见代码条款

提交 BUG

如果你找到了一个 BUG ，请先：

洗把脸清醒一下，看看这个 bug 是不是由别的原因引起的。
确认你正在用一个仍然被支持的版本。
在 Issues 里面搜索有没有其他人遇到过这个问题

如果你准备好这三样了，你就可以提交 Issue 了。提交时，请包含以下内容：

你是怎么触发 bug 的？
版本和环境情况，比如 Java 版本，使用的操作系统
...可能会要你提交更多。

提交后，请留意回复。

提交代码

提交代码是家常便饭，但不规范的提交可能会带来审阅和维护上的困难。
因此，出于项目可维护性的目的，我们建议您做到以下几点：

代码应当简洁易懂，与项目的大体编码风格相一致。这需要你在提交之前稍微观察该项目的大体结构，以及用的库等（比如有 lombok 就别手写 Getter, 标注 @AvailableSince 等等）
非必要，不引入新的依赖，仔细找找是不是要的东西已经有了？引入依赖前要和 Maintainer 或其他 Collaborator 做好沟通。
规范的提交信息以及提交尺寸。（一小件事情一个 Commit ，一大件事情一个 PR）

对于新增功能（比如新的代码模块，组件），应该开一个新的分支和一个 Pull Request，并在标题前打上 [WIP]。

不要擅自更改版本号。
开 PR 时，如果和某个 issue 有关联请考虑命名 issue-xx 并且在 PR 正文中提及 This resolves/closes #xx（这样 GitHub 可以自动关联该 issue）
合并 PR 前必须等待所有 workflow 运行完毕，而且解决所有 Requested Change 以及回复所有 Comment.
每个 PR 的 Assignee 必须要仔细阅读提交的代码才可准备合并。不允许没有 Assignee 的 PR 合并。

提交信息规范

若无特殊说明，我们使用 Angular 提交规范规定 commit 信息格式。

commit 信息要求必须简洁明了地包含做了什么事。

其他注意事项

避免过早优化 把时间花在更有意义的事情上（想想你的一堆 issue?）。如果这部分确实有问题，我们稍后会回来的。
提交大 PR 时请简要介绍自己做了什么改动。
PR Assignee 记得回复感谢。

End