GitHubでは、レビュー担当者と担当者の違いは何ですか？

2016年12月7日に追加され、GitHubブログで発表された機能では、プルリクエストにレビュー担当者を追加するオプションが導入されました

共同編集者に明示的にレビューをリクエストできるようになり、プルリクエストのレビュー対象者を簡単に指定できるようになりました。

プルリクエストページのサイドバーには、レビューを待っている人のリストや、すでにレビューを去った人のレビューのステータスも表示されます。

ただし、PRのレビュー担当者を明示的に設定することは、すでに人を割り当てることによって行われていました（譲受人オプション）。

両方のオプションが利用可能になりましたが、どちらも同じ最終目標を共有しているため、各オプションの役割は何ですか？

編集：

何人かのOSSメンテナと話し合った後、レビュアーとは、本来あるべき単語として定義されます。

「レビューア」の場合：コードをレビューしたい人。その領域の責任者やコミットのマージの責任者である必要はありません。GitHubが自動提案するように、以前にそのコードのチャンクに取り組んだ人である可能性があります。

「担当者」の場合：プロジェクトのチーム/メンテナ次第で、その意味は何であり、厳密な定義はありません。PRオープナー、またはその領域の担当者（レビューが完了した後、PRを受け入れるか、単にそれを閉じる）にすることができます。プロジェクトのメンテナーがプロジェクトに最適なものをオープンにしておくものを定義するのは、GitHubの責任ではありません。

以前の答え：

わかりました、私自身の質問に答えます。

書き込みアクセス権を持つユーザーのPRの場合：担当者はPRを開いた人と同じであり、レビュー担当者は古い担当者機能（コードのレビュー）を置き換え、これが担当者が選択した誰かになります。

書き込みアクセス権のないユーザー（寄稿者以外）のPRの場合：書き込みアクセス権を持つユーザーが自分（または他の書き込み特権メンバー）に割り当てて、PR（レビュー担当者）をレビューします。担当者は空白です。

外部の貢献者からの未完成のPRの場合：書き込みアクセスメンバーは、未完成の作業を取り、彼女に割り当てます。彼女は担当者として、タスクを完了する責任があります。PRの主な理由は変更のレビューであるため、彼女は変更をレビューするために他の何人かを選択します。

GitHubでは、レビュー担当者はプルリクエストをレビューする人です。プロジェクトオーナーは、任意のメンテナからレビューをリクエストできます。書き込みリクエストを持つメンテナの1人がプルリクエストをレビューする場合にのみプルリクエストをマージできるように、オプションを設定することもできます。

公式のgithubドキュメントによると、譲受人は特定の問題とプルリクエストに取り組んでいる人です。レビューアと混同されることもあります。実際には、プルリクエストではなく課題で使用することを目的としているため、課題を受け取ったときに、修正を依頼することができます。プルリクエストでは、担当者とは、他のメンテナからコメントや変更リクエストを受け取った後、そのプルリクエストをマージする担当者を指します。

受け入れられた答えに従って。はい、「担当者」の定義は緩く、チームのニーズに合わせてさまざまに使用できます。

8人の開発者のチームでは、ほとんどのPRに1人のレビュー担当者がおり、変更を提案して最終的にPRを承認します。レビュー段階では、「担当者」はPRを開いた人物です。後でPRが他の開発者によって取り上げられた場合、新しい「担当者」が追加されます。PRが承認され、QAまたは直接マージの準備ができると、新しいQA「担当者」が追加されます。このようにして、「担当者」リストが大きくなります。

「譲受人」を使用して、以下の人々を集合的に指定します。

1. プルリクエスト作成者
2. PR変更提案に取り組んでいる作成者（通常は1と同じ）
3. QA担当者
4. マージの責任者（通常は2または3と同じ）

「担当者」を使用すると、将来のPRを簡単に見つけることができます。私のプロジェクトの1つが3000を超えるPRを持っています。

is:open is:pr author:raya-dumas

is:closed is:pr assignee:raya-dumas

またはauthor:raya-dumas、作成者が作成したすべてのアイテム（問題、PR）を検索する

検索プロセスを容易にするためのその他の同様のクエリ。「マイルストーン」は、PRの検索を容易にするためにも使用すると非常に役立ちます。

以前は、GitHubには担当者フィールドのみがあり、レビューアフィールドはありませんでした。当時は区別がなかったため、担当者フィールドが最も一般的にレビューアフィールドとして使用されていました。

ただし、プロジェクトに適した方法で使用してください。