2016年12月7日にGitHubブログで発表された機能が追加され、オプションが導入されました。プルリクエストにレビュアーを追加する
共同作業者に明示的にレビューをリクエストできるようになり、プル リクエストをレビューする相手を簡単に指定できるようになりました。
プル リクエスト ページのサイドバーには、レビューを待っているユーザーのリストと、すでにレビューを残したユーザーのレビューのステータスも表示されます。
ただし、PR のレビュー担当者を明示的に設定することは、人を割り当てることによってすでに行われています (担当者オプション)。
両方のオプションが利用可能になりましたが、どちらも最終目標は同じなので、各オプションの役割は何でしょうか?
ベストアンサー1
編集：
複数の OSS メンテナーと話し合った結果、レビュー担当者は本来の意味である「(誰かのコードを)レビューする」と定義され、「担当者」は以下に説明するようなより緩い定義を持つようになりました。
「レビュー担当者」 : コードをレビューしてもらいたい人。必ずしもその領域の責任者やコミットのマージ責任者である必要はありません。GitHub が自動的に提案するように、以前にそのコード チャンクに取り組んだことがある人でもかまいません。
「担当者」について: その意味はプロジェクトのチーム/メンテナー次第であり、厳密な定義はありません。PR を開始した人、またはその領域の責任者 (レビューの完了後に PR を受け入れるか、単にクローズする人) のいずれかになります。それが何であるかを定義するのは GitHub ではなく、プロジェクト メンテナーがプロジェクトに最適なものを選択できるようにしています。
前回の回答:
では、自分の質問に答えていきましょう。
書き込みアクセス権を持つユーザーの PR の場合:担当者は PR を開いた人と同じになり、レビュー担当者は古い担当者機能 (コードのレビュー) を置き換え、担当者が選択した人になります。
書き込みアクセス権のないユーザー (外部貢献者) の PR の場合:書き込みアクセス権を持つユーザーが、自分自身 (または他の書き込み権限を持つメンバー) を PR のレビュー担当者 (レビュー担当者) に割り当てます。担当者は空白です。
外部貢献者からの未完了の PR の場合: 書き込みアクセス メンバーが未完了の作業を引き受け、割り当てます。彼女は割り当て先としてタスクを完了する責任を負います。PR の主な目的は変更のレビューであるため、彼女は変更のレビューを行う他の人を選択します。