コードレビュー受信トレイアプリのデザイン

コードレビュー受信トレイの構造

このデスクトップアプリのデザインは、GitHubのレビュー依頼・メンション受信トレイを、縦方向に順序付けられたワークスペースとして提示します。左レールは「All 5」で始まり、その後に「Participating」「Mentions」「Review requests 2」が続きます。メインカラムでは、レビュー依頼、CIチェック、担当Issue、アクティビティの順に作業をグループ化します。この順序により、複数のエンジニアリングシグナルが一つのスキャン経路にまとまり、別々のカテゴリーによって、最初に何へ注意を向けるべきかを判断するための十分な文脈も保たれます。

根拠としてのレビュー依頼

最初のレビュー項目はopen-design/webのPR #2371を示し、「feat: orbit briefing card」という名前と、「3 of 5 reviewers approved · waiting on you + cody」という状態を表示します。その下では、ファイルパス「src/components/OrbitBriefingCard.tsx」が、コンパクトな削除行・追加行の差分を導入します。この組み合わせにより、レビュアーは承認状態を具体的な変更に結び付けられます。トレードオフは縦方向の密度です。コード抜粋は有用な文脈を加えますが、最初の項目が2番目の依頼より大幅に縦長になります。

エンジニアリングトリアージのユースケース

このデザインは、複数の異なるタスクを、それらが同じ種類の作業であるかのように扱わずにサポートします。レビュー依頼は返信または承認を求め、CIチェックは検証失敗の状態を示し、担当Issueは所有するバックログ作業を表し、アクティビティは完了した変更を記録します。これらのグループを別々のパネルとして保つことで、タスクの境界が見えるようになります。トレードオフとして、関連するシグナルは一つの汎用スコアに圧縮されず、ページ全体に分散したままになります。

ワークスペースの閲覧フロー

このワークスペースは、同じサイズのダッシュボードタイルではなく、幅広いメインカラムとコンパクトなナビゲーションレールを使用します。提供されたCSSではページ幅の最大値が1280pxに設定されており、表示レイアウトではイベントパネルが水平方向の大部分を占めます。この比率により、各項目を別々のカード列へ押し込むことなく、長いリポジトリ名、プルリクエストのタイトル、タイムスタンプ、コード行を収められます。コストは長い縦方向のスキャンであり、レビュー依頼に埋め込み差分が含まれる場合は特に顕著です。

フィルターから詳細へ

上部の検索フィールドには「Type / to search」と表示されますが、検索ハンドラーはありません。サイドバーのフィルターは、提供されたローカルグループに対して機能します。「Participating」ではレビュー依頼と担当Issueが表示され、「Review requests」ではレビューグループが表示され、「Mentions」では元データのメンションマーカーを持つグループだけが表示されます。そのマーカーは、返信が必要なレビュー行ではなく、担当Issueに付与されています。このフィルタリングはローカルな表示動作であり、接続されたGitHub検索や受信トレイサービスではありません。

色による状態変化

色は、ほかの点では似ている行全体に状態を伝えます。緑はオープンまたは健全に見えるリポジトリ状態、黄色は返信を待っている作業、赤は失敗したテスト、紫はマージ済みのアクティビティ項目を示します。Issueのラベルでは、「backend」と「p1」に別々の青とピンクのピルを使用しています。これにより、すべての文を読むより速くスキャンできますが、色は補助的な要素にとどまります。それぞれの状態はテキストでも記述されているため、色だけでは不十分な場合にも意味が保たれます。

機能の境界

このソースは、ローカルなカテゴリーのフィルタリングを実装し、行とタイトルから外部へ移動するGitHubリンクを生成します。これらのリンクは、表示されたサンプル識別子を使って固定リポジトリを指しますが、描かれているプルリクエスト、Issue、CI結果の存在を検証するものではありません。検索、認証済みの受信トレイ取得、永続的なレビュー状態、実際のテスト実行は実装されていません。名前、件数、タイムスタンプ、承認状態、コード抜粋は、デザインシナリオのための例示的なコンテンツとして残されています。