简介

PR 规则

• 我们 较喜欢较小的 PR。
• 使用 graphite 叠加 PR，如果您有写访问权限（在大量的贡献后，就会获得此权限）。
• 如果 PR 包含架构更改，请创建问题或讨论。

开发策略

• 采用面向数据的设计。
• 保持 API 简单且文档齐全。
• 如果实现来自其他项目，请务必提供源的参考。

性能

• 在此项目中，所有性能问题均被视为错误，其中包括所有运行时和编译性能问题。
  • 遵循 Rust 性能手册 的指导。
  • 最大程度减少 regex 板条箱的使用。使用 Rust 迭代器和字符串方法可获得更好的性能。
• 为了减少对开发工作流和下游工具的影响，编译时间必须缩到最短。
  • 最大程度减少第三方依赖关系，以减少编译速度和项目复杂度。
  • 避免使用会降低编译速度的大型宏、泛型或任何 Rust 技术。
  • 我们的 CI 运行 在 3 分钟内完成，任何回归问题都必须修复。

维护策略

• 监视未使用代码的代码覆盖率。目标覆盖率为 99%。
• 积极地对 CI 时间进行监控和缩短，以便提高 PR 合并速度。当前在 GitHub actions 上的 CI 时间约为 3 分钟。
• 文档优先 - 文档应作为真实性的来源。保持文档更新，并分享链接，而不是重复回答同样的问题。查看 GitLab 的handbook-first方法。

传统提交

我们遵循传统提交

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

• fix：这种类型的提交修复代码库中的错误。
• feat：这种类型的提交向代码库中引入新功能。
• 重大更改：在类型/范围后添加!会引入重大的 API 更改，例如 feat(parser)!: new feature。
• 范围是包名称。
• 类型包括feat:、fix:、chore:、ci:、docs:、style:、refactor:、perf:和test:。

行动策略

摘自Astral 的价值观

即使面对不确定性，我们也会偏向于采取行动。我们更倾向于务实的行动，而不是冗长的辩论；我们更倾向于请求原谅而不是许可。我们重视果断 - 即使决策不清晰，特别是当决策是可逆时，更是如此。

偏向于行动并不等同于鲁莽。相反，它偏向于做出负责任的决策，并果断地采取行动，即使存在挥之不去的模糊性或已知未知。