メインコンテンツまでスキップ

デザインレビューガイドライン

該当する場合は、以下のガイドラインに従ってください。

V8のデザインレビューの形式化には、複数の目的があります:

  1. 個々の貢献者（IC）に意思決定者が誰であるかを明確にし、技術的な意見の不一致でプロジェクトが進まない場合の道筋を示す
  2. 明確なデザイン議論の場を提供する
  3. V8技術リード（TL）が重要な変更をすべて認識し、技術リード層で意見を述べる機会を持てるようにする
  4. 世界中のすべてのV8貢献者の関与を増やす

要約​

V8のデザインレビューガイドラインの概要

重要:

  1. 善意を前提とする
  2. 親切で礼儀正しくあること
  3. 実用的であること

提案された解決策は以下の前提/柱に基づいています:

  1. 提案されたワークフローは個々の貢献者（IC）が主導権を持つことを前提としています。彼らがプロセスを促進します。
  2. 指導するTLは、ICが適切なLGTM提供者を見つけるのを助けるように任命されています。
  3. 機能が物議を醸さない場合、ほぼ何の負担も生じません。
  4. 多くの論争がある場合、機能はV8 Eng Review Ownersの会議に'エスカレーション'され、次のステップが決定されます。

役割​

個々の貢献者（IC）​

LGTM: 該当なし この人物が機能の作成者であり、デザインドキュメントの作成者です。

ICの技術リード（TL）​

LGTM: 必須 この人物は特定のプロジェクトやコンポーネントのTLです。おそらく、あなたの機能が触れる主なコンポーネントの所有者である人物です。TLが誰であるかが明確でない場合は、[email protected] を介してV8 Eng Review Ownersに尋ねてください。適切であればTLは必要なLGTM提供者のリストにさらに多くの人物を追加する責任を持っています。

LGTM提供者​

LGTM: 必須 この人物はLGTMを提供する必要がある人です。それはICまたはTL(M)である場合があります。

ドキュメントの“不定”レビューア（RRotD）​

LGTM: 必須ではない この人物は単に提案をレビューしコメントする人です。その意見は考慮されるべきですが、LGTMは必須ではありません。

V8 Eng Review Owners​

LGTM: 必須ではない 行き詰まった提案は[email protected]を介してV8 Eng Review Ownersにエスカレーションされることができます。そのようなエスカレーションの潜在的な使用ケース:

  • LGTM提供者が応答しない場合
  • デザインに関するコンセンサスが得られない場合

V8 Eng Review Ownersは非LGTMまたはLGTMを覆すことができます。

詳細なワークフロー​

V8のデザインレビューガイドラインの概要

  1. 開始: ICが機能に取り組むことを決定する/割り当てられた機能を受け取る
  2. ICは初期デザインドキュメント/説明資料/一枚の文書をいくつかのRRotDsに送る
    1. プロトタイプは「デザインドキュメント」の一部と見なされます
  3. ICは自身が考えるLGTM提供者のリストに人々を追加します。TLはLGTM提供者のリストに必須です。
  4. ICがフィードバックを取り入れる。
  5. TLがLGTM提供者のリストにさらに人々を追加する。
  6. ICが初期デザインドキュメント/説明資料/一枚の文書を[email protected]に送る。
  7. ICがLGTMsを収集する。TLが手助けする。
    1. LGTM提供者が文書をレビューし、コメントを追加し、文書の冒頭にLGTMまたは非LGTMを示す。非LGTMを追加する場合は理由を列挙する。
    2. オプション: LGTM提供者は自分自身をLGTM提供者リストから外すことができる/他のLGTM提供者を提案できる
    3. ICとTLは未解決の問題を解決するために協力する。
    4. すべてのLGTMが収集された場合、[email protected] にメールを送信し（例えば元スレッドをピンすることで）、実装を発表する。
  8. オプション: ICとTLが行き詰まり、または広範な議論を望む場合は、問題をV8 Eng Review Ownersにエスカレーションすることができる。
    1. ICがv8[email protected] にメールを送信する
      1. CCにTLを含む
      2. メール内のデザインドキュメントのリンク
    2. すべてのV8 Eng Review Ownersメンバーは文書をレビューする義務があり、任意でLGTM提供者リストに自分自身を追加できる。
    3. 機能のブロックを解除するための次のステップが決定される。
    4. その後ブロッカーが解決されない場合、または新たな解決不能なブロッカーが発見された場合、8に進む。
  9. オプション: 機能がすでに承認された後に非LGTMsが追加された場合、それらは通常の未解決の問題として扱われるべきです。
    1. ICとTLは未解決の問題を解決するために協力する。
  10. 終了: ICが機能を続行する。

そして、いつも覚えておくべきこと:

  1. 善意を前提とする
  2. 親切で礼儀正しくあること
  3. 実用的であること

FAQ​

機能がデザインドキュメントを持つ価値があるかどうかをどう判断するか?​

デザインドキュメントが適切な場合のいくつかのポイント:

  • 少なくとも2つのコンポーネントに触れる
  • V8以外のプロジェクト（例：デバッガー、Blink）との調整が必要
  • 実装に1週間以上かかる
  • 言語機能である
  • プラットフォーム固有のコードが編集される
  • ユーザー向けの変更が含まれる
  • 特別なセキュリティ考慮が必要、またはセキュリティ影響が明白でない

不明な場合は、TL に確認してください。

LGTMプロバイダーとして誰を追加すべきかを決める方法​

LGTMプロバイダーのリストに追加すべきタイミングに関するポイント:

  • 触る予定のソースファイル/ディレクトリのOWNER
  • 触る予定のコンポーネントの主なエキスパート
  • 変更内容の下流利用者（例：APIの変更時）

“私の”TLとは誰を指すのか？​

これはおそらく、あなたの機能が触れる主なコンポーネントのオーナーです。TLが明確でない場合、[email protected] 経由でV8エンジニアリングレビューチームのオーナーに問い合わせてください。

設計ドキュメントのテンプレートはどこにありますか？​

こちら.

大きな変更が発生した場合はどうすればいいですか？​

LGTMs の状況を確認し、例えば LGTMプロバイダーに明確で合理的な期限を提示して意見を求めるようにしてください。

LGTMプロバイダーが私のドキュメントにコメントしない場合、どうすればいいのか？​

この場合、以下のエスカレーションステップに従ってください:

  • メール、Hangouts、ドキュメント内のコメント/タスク割り当てを通じて直接連絡し、明示的にLGTMまたは非LGTMを追加するよう依頼してください。
  • あなたのTLを巻き込んで助けを求めてください。
  • [email protected] にエスカレートしてください。

誰かが私をLGTMプロバイダーとしてドキュメントに追加した場合、どうすればいいのか？​

V8は意思決定をより透明にし、エスカレーションを円滑にすることを目指しています。設計が十分に良く、実施すべきであると考える場合、あなたの名前の隣のテーブルセルに「LGTM」を追加してください。

懸念事項や意見がある場合は、「Not LGTM, because <理由>」を名前の隣のテーブルセルに追加してください。さらに一巡のレビューを求められる準備をしてください。

V8の設計レビューガイドラインは、V8の Blink Intent+Errataプロセスを補完します。新しいWebAssemblyまたはJavaScript言語機能を立ち上げる場合、V8の Blink Intent+Errataプロセスと設計レビューガイドラインに従ってください。Intent to Implement を送信するタイミングで全てのLGTMを集めるのが妥当でしょう。