運営原則
AI エンジニアリンググループの運営原則です。これらの原則は、長期的な保守性を犠牲にすることなく、タイトな期日のもとで信頼できる機能を提供するために、私たちがどのように協働するかを定義しています。
目的
新機能をタイムリーに実装しながら、DAP コードベースの安定性、予測可能性、品質を改善することです。これらの原則は、長期的な保守性を犠牲にすることなく、タイトな期日のもとで信頼できる機能を提供するために、私たちがどのように協働するかを定義しています。
運営原則の短い要約
レビューとマージ規律
- すべての MR は関連分野から2人のレビュアーを得ます。S1 レベルの状況を除き、シングルレビューマージは行いません。
思い込みより品質
- 何かが間違っているまたは不明瞭に見えたら、止まって質問する。黙って大丈夫だろうと仮定するのではなく、助けを求めます。
テストカバレッジの徹底
- カバレッジジョブは FE と BE の変更で必ずパスする必要があります。例外なし。
レビュアープロセス中の圧力禁止
- レビュープロセスが始まったら、「これ ASAP で必要」とレビュアーを急かしたり促したりしないでください。期日が守れない場合は、レビュー品質を下げるのではなくエスカレーションしてください。
スピードから安定性へのシフト
- 急ぐことから安定性へシフトします。小さく、クリーンで、最小限の変更が、大きくリスクのある変更に勝ります。
リスクの早期シグナル
- 遅延、スコープクリープ、不明瞭な要件、ブロッカーを見つけたらすぐに提起します。
厳格な AI 支援コーディング規律
- AI はヘルパーであり権威ではありません。実装をシンプルに保ちます。マージするすべての行を理解します。
高帯域コミュニケーション
- 複雑さを予見した、レビューできない、改善する価値があると感じたら、すぐに声を上げます。
後方互換性
- AI ゲートウェイやエディター拡張機能など、GitLab インスタンス外の変更も、引き続き後方互換性ガイドラインに従う必要があります。
原則
レビューとマージ規律
- コードが安定化したと見なされる（別途評価対象）まで、すべてのマージリクエストは関連分野（BE または FE）から少なくとも2人のレビュアーを必要とします。
- 高重大度（S1）修正として明示的に承認された場合を除き、シングルレビューマージは行いません。すべての MR は、その MR の主要な機能分野（フロントエンドおよび／またはバックエンド）について2つの承認を得る必要があります。例:
- MR がフロントエンドと UX の両方のレビューを必要とする場合、フロントエンドレビュー2件と UX レビュー1件が期待されます（プロダクトデザイナーを含むチームの MR の場合）
- MR がバックエンドとフロントエンドの両方のレビューを必要とする場合、フロントエンドレビュー2件とバックエンドレビュー2件が期待されます
思い込みより品質
- MR の中で何かが正しくない、不明瞭、または疑わしく見える場合は、立ち止まってエスカレーションしてください。疑問があれば質問し、スレッドを始めるか、主要なプロダクトまたはエンジニアリングのステークホルダーを会話に巻き込みます。
- 完全に理解できない、または擁護できないコードを決してマージしないでください。
- レビューするコードは常にローカルでテストし、後から変更があった場合は再度テストします。
テストカバレッジの徹底
- カバレッジジョブはすべての MR で実行されなければなりません。
レビュアープロセス中の圧力禁止
- レビュアーがレビューを開始した後、「早くレビューして」「ASAP でマージして」「とにかく承認して進められるように」とレビュアーに圧力をかけないでください。
- 時間的圧力はレビュー品質を下げる正当化には決してなりません。
- タイムラインが本当に守れない場合は、個々のレビュアーにその圧力をかけるのではなく、テクニカルリーダーシップやエンジニアリングマネジメントを通じてエスカレーションしてください。
- レビューは明確さ、安全性、正しさを保つペースで行われなければなりません。
- ただし、私たちのドキュメントで定義されているように、適時にレビューが開始されていない場合に、アサインされたレビュアー／メンテナーを促すことは許容されます。
スピードから安定性へのシフト
- 初期フェーズでは出荷量を優先しました。
- 今後は、堅牢性、明確性、正しさが優先事項です。
- 「Less is more」が当てはまります: 小さく、フォーカスが明確で、信頼性のある変更は、広範でリスクのある変更よりも優れています。
リスクの早期シグナル
- リスクが現れたらすぐに伝えます:
- 遅延
- スコープクリープ
- 不明瞭な要件
- 進捗をブロックする依存関係
- 不確実性を早期に表面化することで、後で複合的な失敗が起きるのを防ぎます。
- リスクが現れたらすぐに伝えます:
厳格な AI 支援コーディング規律
- AI はツールであり権威ではありません。
- AI をコードに使用する場合:
- 簡潔で明示的なシンプルな実装を求めます。
- 生成されたすべての行を検証します。
- 不明瞭または魔法のようなロジックを問いただします。
- 自分自身がエンドツーエンドで理解し、合意したものだけをブランチにプッシュします。
高帯域コミュニケーション
- タスクの複雑さを予見したら: 声を上げてください。
- MR を迅速にレビューできない場合: 声を上げてください。
- 簡略化や改善の機会に気付いた場合: 声を上げてください。
- 黙った不確実性は、間違った初期仮定よりも有害です。
後方互換性
- AI ゲートウェイやエディター拡張機能など、GitLab インスタンス外の変更は、引き続き GA 機能向けの一般的な 後方互換性ガイドライン に準拠する必要があります
- ベータ機能は、少なくとも GitLab の直近3つのマイナーバージョンと後方互換性がなければなりません
- 疑問がある場合は、自己管理インスタンスの古いバージョンで、変更が後方互換性を破壊しないことを検証してください。専用インスタンスへのアクセスは こちら から取得できます。
