PRのルールとポリシー

PRのルール

• 小さなPRを好む。
• 書き込みアクセスがある場合は、graphite を使って積み重ねる形のPRを試してみてください。多くの貢献がなされると、あなたに書き込みアクセスが与えられます。
• 修正内容にアーキテクチャ的な変更がある場合は、必ずイシューまたはディスカッションを作成してください。

開発ポリシー

• データ指向設計を採用する。
• APIはシンプルで、しっかり文書化されていること。
• 実装が他のプロジェクトから来ている場合は、常に元となるソースへの参照を提示する。

パフォーマンス

• このプロジェクトでは、すべてのパフォーマンスに関する問題はバグとみなされる。これは、実行時およびコンパイル時のパフォーマンス問題を含む。
  • Rustのパフォーマンス本のガイドラインに従う。
  • regex クレートの使用を最小限に抑える。より高いパフォーマンスを得るために、Rustのイテレーターや文字列メソッドを使用する。
• コンパイル時間を最小限に抑え、開発ワークフローおよび下流ツールへの影響を軽減する。
  • 第三者依存関係を最小限に抑えることで、コンパイル速度とプロジェクトの複雑さを削減する。
  • 重いマクロやジェネリック、またはコンパイルを遅くしたりバイナリサイズを増加させる可能性のあるすべてのRust技術を避ける。
  • 当社のCI実行は3分以内に完了する。すべてのパフォーマンス劣化は速やかに修正しなければならない。

メンテナンスポリシー

• 使用されていないコードを検出するためにコードカバレッジを監視する。目標は99%のコードカバレッジ。
• 時間のかかるCIの時間短縮を積極的に監視し、プルリクエストのマージを迅速化する努力を続ける。現在のGitHub ActionsでのCI時間は約3分程度。
• ドキュメント第一：ドキュメントは真実の情報源として機能すべきである。ドキュメントを常に最新状態に保ち、同じ質問を繰り返し答える代わりにリンクを共有する。GitLabのハンドブック第一のアプローチを参照。
• 一貫したインポート順序：「最も遠い」ものから「最も近い」ものへ。
  • std
  • 外部クレート
  • Oxcクレート
  • ローカルクレート (crate)
  • super
  • mod

標準コミット

私たちは標準コミットに従っています：

コミットには以下の構造的要素が含まれており、利用者に対して意図を明確に伝える：

• fix: fixタイプのコミットは、コードベース内のバグを修正します。
• feat: featタイプのコミットは、コードベースに新しい機能を導入します。
• BREAKING CHANGE: type/scope の後に ! を追加し、破壊的なAPI変更を示します。例: feat(parser)!: new feature。
• スコープはクレート名です。
• タイプは feat:、fix:、chore:、ci:、docs:、style:、refactor:、perf:、test: です。

行動ポリシー

Astralの価値観より抜粋：

不確実性があっても、行動を優先する。長期間の議論よりも現実的な行動を重視する。許可を得るよりも、許しを請うことを好む。決定力——特に判断が明確でないとき、そして特に決定が逆転可能なとき——を重視する。

行動を優先することは、無謀さとは異なる。むしろ、責任ある意思決定を行い、その決定を緊急事態のように迅速に実行する傾向であり、あいまいさや既知の未知要因が残ったままでも構わない。