介绍

🌐 Introduction

公关规则

🌐 PR Rules

• 我们更喜欢较小的PR。
• 如果你有写入权限，可以尝试使用 graphite 的堆叠 PR，当你作出大量贡献时会获得该权限。
• 如果该 PR 包含架构更改，请创建一个问题或讨论。

发展政策

🌐 Development Policy

• 拥抱以数据为导向的设计。
• 保持 API 简单且文档完善。
• 如果实现来自其他项目，请始终提供来源参考。

性能

🌐 Performance

• 本项目中所有性能问题均视为 bug，包括所有运行时和编译性能问题。
  • 请遵循《Rust 性能指南》中的指导（Rust performance book）。
  • 尽量减少使用 regex crate。使用 Rust 的迭代器和字符串方法以获得更好的性能。
• 必须尽量减少编译时间，以降低对开发工作流程和下游工具的影响。
  • 尽量减少第三方依赖，以提高编译速度并降低项目复杂性。
  • 避免使用大量宏、泛型或任何会降低编译速度或增加二进制大小的 Rust 技术。
  • 我们的CI 流程在 3 分钟内完成，任何回归都需要修复。

维护政策

🌐 Maintenance Policy

• 监控未使用代码的代码覆盖率。目标是达到 99% 的代码覆盖率。
• 积极监控并努力减少 CI 时间，以加快 PR 的合并速度。GitHub Actions 上当前的 CI 时间大约为 3 分钟。
• 文档优先——文档应作为信息的唯一来源。保持文档更新，并分享链接，而不是重复回答相同的问题。参见 GitLab 的 handbook-first 方法。
• 一致的导入顺序：从“最远的”到“最近的”。
  • std
  • 外部包
  • 牛箱
  • 本地包 (crate)
  • super
  • mod

常规提交

🌐 Conventional Commits

我们遵循 conventional commits：

🌐 We follow conventional commits:

该提交包含以下结构元素，用于向使用者传达意图：

🌐 The commit contains the following structural elements, to communicate intent to the consumers:

• fix：一种类型为 fix 的提交，会修复你代码库中的一个错误。
• feat：类型为 feat 的提交会向代码库引入新功能。
• 重大更改：a 在类型/范围后追加 !，引入了破坏性的 API 更改，例如 feat(parser)!: new feature。
• 这些作用域是 crate 名称。
• 类型有 feat:、fix:、chore:、ci:、docs:、style:、refactor:、perf: 和 test:。

行动政策

🌐 Action Policy

摘自Astral 的数值:

🌐 Taken from Astral's values:

即使在不确定的情况下，我们也倾向于行动。我们更喜欢务实的行动而不是长时间的争论；我们更倾向于事后求原谅而不是事前请示。我们重视果断——尤其是在决策并非明显清晰的时候，尤其是在决策可逆的情况下。

行动倾向并不等同于冒险行为。相反，这是一种倾向，即做出负责任的决策并以紧迫感执行，即使我们面临持续的不确定性或已知的未知因素。