商用開発ではコードレビューが強く求められていることは知っています。しかし、コードレビューはオープンソースソフトウェアで使用されていますか、それとも信頼に基づいていますか？もしそうなら、彼らはどのように実行されますか？[遅延コミット、「プリコミット環境」ですか、パッチを別の開発者に送信できるツールはありますか？]
コードレビューを使用するプロジェクトはありますか？
私の理解では、Linuxカーネルは主にコミッターの信頼に基づいています。MySQLは、主要な著者の承認とパフォーマンスへの影響に基づいていました。
回答:
ほとんどすべてのオープンソースプロジェクトは、ある種のゲートキーパーワークフローを使用しています。このワークフローでは、個人またはグループが公式ビルドに入るには、すべての変更を承認する必要があります。Linuxカーネルなどの一部の大規模プロジェクトには、ゲートキーパーのレイヤーがあります。サブシステムの領域を管理する人に変更を送信し、サブシステム全体を管理する人に変更を送信し、変更をLinus Torvaldsに送信します。LinusTorvaldsは、コードを自分でレビューしたり、時には副官を信頼したりします。これらのレビューには通常、正式な構造はありません。マージされる前にコードを見ている人だけです。
ツールに関する限り、良い例としてgithubのプルリクエストメカニズムを見てください。あなたはプルリクエストを作成し、そのプルリクエスト専用のWebページで、人々がコメントし、作成者が承認するまで修正を加えます。他のゲートキーパーはプレーンgitを使用してメーリングリストからパッチを適用したり、パブリックリポジトリからのプルリクエストをマージしたりします。これがgitのようなDVCSが発明された主な理由の1つです。
多くの場合、オープンソースプロジェクトには、明確に公開された「コミュニティガイドライン」のセットがあり、そうでない場合は、プロジェクトワークフローの説明とコントリビューションの受け入れ方法（したがって、それらのテスト方法）も含まれます。コアコミッターになるためのプロセスとして。
コードレビューに関しては、やはりコミュニティに依存しますが、ガイドラインはしばしば明確にされます。非コミッターによるコントリビューションのガイドラインの例には、「実際のコードウィン」から「コントリビューションには完全なテストカバレッジとドキュメントが必要で、テストはコードと同時にコミットされる」から、その間のすべてのものまであります。これらのガイドラインに関係なく、暗示されている1つのガイドラインは、コアコミッターが非コミッターからのすべての貢献を承認する前に確認することです。
コアコミッターのグループを含むオープンソースプロジェクトでは、追加の目が必要になる可能性のある寄稿について話し合うために、仮想会議または専用の時間を持っていることもよくあります。これは、質問が締め切られる前に特定の評判のユーザーが複数回投票するSEプロセスのようです。メタやチャットを介して疑わしいものの議論。
以下は、私が最もよく知っているプロジェクトのコミュニティドキュメントの例へのクイックリンクです。これらのプロジェクトに固有の質問に対する回答を見つけることができます（すぐにテーマに気付くでしょう）。
大規模なOSSプロジェクトには、いくつかのコアコミッターがいます。それで、彼らは事実上の「コードレビュアー」だと思います。
また、OSSコードはその性質上誰もが自由に使用できるため、作成しているコードについては、さらに多くの議論が行われる可能性があります。これは正式なコードレビューの形式ではない可能性がありますが、特定のOSSプロジェクトでコードが完全に検討されていないかどうかを確認できます。