Archguard 正在慢慢形成自己的社区，我们非常欢迎任何感兴趣的人能够贡献自己的代码。Archguard 社区使用 pull request 的流程进行开发。
在开始之前
为了避免大家的工作返工，我们不建议你在社区不知情的情况下直接发起 pull request，因为可能你的方案刚好跟社区相反，这可能导致在你的 pull request review 的过程中需要做大量的修改。
Contribution 步骤
- 如果你遇到了问题或者想要完成某一个新的功能，请先浏览对应 repo 的 issue 区域；
- 如果你的问题或者想要实现的功能已经有一个类似的 issue，你可以检查该 issue 是否已经有人认领；
- 如果没有的话你可以创建一个新的 issue；
- 然后你可以在这个 issue 中与社区的成员讨论这个问题或功能的实现并认领这个 issue；
- 在开发的过程中请遵循 github workflow 的规范，先在自己的 repo 中开发，之后发起 pull request 等待社区的 review。在未来我们会逐步完善我们的 CI/CD，请确保你的代码修改能够通过所有的 pipeline；
- 在 review 的过程中社区可能会留下一些修改建议和讨论，在修改这些建议的过程中还请确保你的 pull request 持续 rebase 以保持代码的更新；
- 当你的 pull request 被 approve 后代码将被自动合入 repo;
关联 issue 与 pull request
Archguard 社区要求所有的 pull request 都应该关联对应的 issue。
基于此，在 pull request 的描述中应该有一行 通过关键词关联对应的 issue
比如如果你想在在自己的 pull request 合并后自动关闭关联的 issue，那么你可以在 pull request 的描述中加入这样的一行描述：
Issue Number: close #123
而如果你仅仅是想要关联某一个 issue，但还不能解决这个问题，仅仅是想做关联，那么你可以这样写：
Issue Number: ref #456
更多关键词和用法可以查阅 github 官方文档
Commit 规范
这虽然不是必须的，但是请确保你的每一个 commit 都是在做同一件小事。例如：
- 假设你正在解决某一个 bug，那么这个 commit 中就不应该包含新功能的添加；
- 假设你正在重构某一个功能，那么就不应该同时包含 bug 的修复
- 也尽量不要同时在一个 commit 中实现多个功能/修复多个bug
关于测试
坦率来说 Archguard 的测试覆盖率并没有很高，但是我们还是希望改善这个情况，所以测试代码应该是每一个 pull request 的一部分。
你的任何新增功能的代码应该有对应的测试用例保护。如果你修改了已有功能或修复了一个 bug，我们期望你能够同时修改对应的测试代码或者为这个没有考虑到的 bug 加上测试用例。
我们也非常欢迎你的 pull request 只是单纯添加测试用例以提高项目的测试覆盖率。