Introduction
PR Rules
- We prefer smaller PRs.
- Try stacked PRs with graphite if you have write access, which will be given to you when you contribute a lot.
- Please create an issue or discussion if the PR contains architectural changes.
Development Policy
- All performance issues (runtime and compilation speed) are considered as bugs in this project.
- Embrace data-oriented design.
- APIs should be simple and well-documented.
- Third-party dependencies should be minimal.
- Avoid the
regexcrate when possible. Regex is slow, most of them can be rewritten in a performant way by using Rust iterator and string methods. - Avoid heavy macros or generics or any Rust techniques that would penalize compilation speed.
- Always reference the source if the implementation comes from elsewhere.
Maintenance Policy
- Monitor code coverage for unused code. Aim for 99% code coverage.
- CI time should be actively monitored and reduced to speed up merging of PRs. The current CI time on GitHub actions is around 3 minutes.
Conventional Commits
We follow conventional commits:
The commit contains the following structural elements, to communicate intent to the consumers:
fix: a commit of the type fix patches a bug in your codebase.feat: a commit of the type feat introduces a new feature to the codebase.- BREAKING CHANGE: a appends a
!after the type/scope, introduces a breaking API change, e.g.feat(parser)!: new feature. - the scopes are crate names.
- the types are
feat:,fix:,chore:,ci:,docs:,style:,refactor:,perf:andtest:.
Action Policy
Taken from Astral's values:
We bias towards action, even in the face of uncertainty. We favor pragmatic doing over prolonged debating; we favor asking for forgiveness over permission. We value decisiveness — especially when a decision isn’t clear cut, and especially when a decision is reversible.
A bias towards action is not the same as recklessness. Rather, it’s a bias towards making responsible decisions and acting on them with urgency, even if we’re left with lingering ambiguity or known unknowns.