簡介

PR 規則

• 我們偏好較小的 PR。
• 如果您有寫入權限，請嘗試使用 graphite 的堆疊 PR，當您做出大量貢獻時，您將獲得寫入權限。
• 如果 PR 包含架構變更，請建立問題或討論。

開發政策

• 採用資料導向設計。
• 保持 API 簡潔且有完善的文件。
• 如果實作來自另一個專案，請務必提供來源參考。

效能

• 在此專案中，所有效能問題都被視為錯誤，包括所有執行時間和編譯效能問題。
  • 請遵循 Rust 效能書籍 中的指南。
  • 盡量減少使用 regex crate。使用 Rust 迭代器和字串方法以獲得更好的效能。
• 必須盡量縮短編譯時間，以減少對開發工作流程和下游工具的影響。
  • 盡量減少第三方依賴，以降低編譯速度和專案複雜度。
  • 避免使用大量的巨集、泛型或任何會減慢編譯速度的 Rust 技術。
  • 我們的 CI 執行在 3 分鐘內完成，任何效能退化都需要修正。

維護政策

• 監控程式碼覆蓋率以尋找未使用的程式碼。目標是 99% 的程式碼覆蓋率。
• 積極監控並努力減少 CI 時間，以加速 PR 的合併。目前在 GitHub actions 上的 CI 時間約為 3 分鐘。
• 文件優先 - 文件應作為事實來源。保持文件更新，並分享連結，而不是重複回答相同的問題。請參閱 GitLab 的 handbook-first 方法。

Conventional Commits

我們遵循 conventional commits

提交包含以下結構元素，以向消費者傳達意圖

• fix：類型為 fix 的提交會修補程式碼庫中的錯誤。
• feat：類型為 feat 的提交會向程式碼庫引入新功能。
• BREAKING CHANGE：在類型/範圍後附加一個 !，表示引入了破壞性的 API 變更，例如 feat(parser)!: 新功能。
• 範圍是 crate 名稱。
• 類型為 feat:、fix:、chore:、ci:、docs:、style:、refactor:、perf: 和 test:。

行動政策

取自 Astral 的價值觀

即使面對不確定性，我們也傾向於採取行動。我們偏好務實的行動而非長時間的辯論；我們偏好請求原諒而非許可。我們重視果斷 — 尤其是當決策不明確時，而且尤其是當決策可逆時。

傾向於行動並不等同於魯莽。相反地，它是傾向於做出負責任的決策並以迫切的態度執行，即使我們仍然存在揮之不去的模糊性或已知未知數。