オープンソースへの貢献

この記事では、例を挙げながらオープンソースプロジェクトに貢献する方法について説明します。ここでは、github/docs リポジトリに貢献する方法について指針を示します。具体的には、リポジトリの理解、貢献できる分野の特定、pull request の作成と送信、メンテナと連携して変更を受け入れてもらう方法です。

プロジェクトのガイドラインを理解する

始める前に、プロジェクトのガイドラインと要件を理解することが重要です。

ガイドラインが重要な理由

各プロジェクトには、独自の規則、コーディング標準、貢献プロセスがあり、それらに従う必要があります。

コードスタイルと書式設定の要件: コードの書式設定方法、名前付け規則、リンティング規則
テストガイドライン: テストの実行方法、新機能に必要なテスト、テストの規則
Pull request プロセス: Pull request の構造、含める情報、期待されるレビュー
開発のセットアップ: ローカル開発環境、必要な依存関係、ビルドプロセスの設定方法
issue の報告: バグの報告、機能のリクエスト、質問の方法
コミュニケーションチャネル: 質問し、変更について話し合い、メンテナの支援を受けられる場所

この内容をよく読むことで、自分とメンテナの両方の時間を節約できます。また、貢献が受け入れられる可能性が高まります。

ガイドラインを見つける

このようなガイドラインと要件にアクセスするには、[Insights] タブの [Community Standards] チェックリストに移動します。この例では、[github/docs Community Standards] を使います。

README: プロジェクトの概要について説明します。 README の内容はさまざまですが、ユーザーや共同作成者がプロジェクトの内容と使用方法をすぐに理解できるように支援するものです。他のドキュメントへのリンクも記載されています。
Code of Conduct: プロジェクトの共同作成者とコミュニティメンバーが遵守すべき行動基準を定義し、違反への対応方針や手順を定めています。
Contributing: プロジェクトに参加する共同作成者向けのガイドラインと手順が記載されています。明確な期待値を設定し、一貫性のあるコラボレーションを促進することで、貢献プロセスの効率化を支援する内容です。
License: 著作権とアクセス許可に関する明確な条件を設定することで、他のユーザーがコードを使用、変更、配布できる方法を法的に定義し、管理者とユーザーの両方を保護しています。
- たとえば、github/docs リポジトリではドキュメントに Creative Commons ライセンスを使っています。これは創作物に特化したライセンスの一種です。 github/docs のソフトウェアコードは MIT ライセンスの下で提供されています。これは、それに含まれるコードを誰でも利用できる寛容なライセンスです。
- [Choose a license] ツールを使うと、他の一般的なライセンスの種類について確認することができます。
Security policy: リポジトリメンテナにセキュリティ上の脆弱性を報告する手順が記載されています。

github/docs リポジトリで使用できる各リソースをレビューしてください。

プロジェクトに初めて貢献するときは、ドキュメントの改善や小さなバグ報告といった軽微な修正から始めると、コードベースや共同作成者のワークフローに慣れるのに役立ちます。この例では、help wanted および good first issue ラベルを使って issue を検索し、外部の共同作成者に公開されている特定の issue を見つけます。次に、Copilot を使って、issue に関するコンテキストを提供します。

github/docs リポジトリの [Issue] タブに移動し、[Labels] フィルターを使って [help wanted] を選ぶと、コミュニティのヘルプが必要であるとメンテナが特にマークした未解決の issue が表示されます。
Issue の一覧に目を通し、取り組みたい issue を見つけてください。
GitHub の任意のページの右上で、検索バーの横にあるボタンをクリックします。

イマーシブモードの Copilot Chat がページ全体に表示されます。

プロンプトボックスに次のプロンプトを入力します。

Text

Can you summarize the key points and next steps from this issue?

Can you summarize the key points and next steps from this issue?

提供されているコンテキスト Copilot と、他の共同作成者やメンテナからのコメントを読んで、その issue に取り組むかどうかを判断します。具体的な質問がある場合は、issue で直接質問するか、該当する場合はプロジェクトの Discord、IRC、または Slack で質問することができます。

ヒント

help wanted または good first issue ラベルが付いていない issue に取り組む場合は、計画している貢献がプロジェクトの目標と一致しているかどうかを確認するために、issue のメンテナに pull request を開いてよいか確認することをお勧めします。

プロジェクトの独自コピーの作成

これで、貢献を始める準備ができました。リポジトリを編集するアクセス権がないため、まずフォークを作成する必要があります。つまり、安心して変更し、それを送信してメンテナのレビューを受けることができる自分専用のコピーです。この例では、github/docs リポジトリのフォークを作成する手順について説明します。

https://github.com/github/docs で GitHub Docs プロジェクトに移動します。
ページの右上隅の [フォーク] を選択します。
[所有者] の下のドロップダウンメニューを選び、フォークされたリポジトリの所有者をクリックします。
既定では、フォークの名前はその上流リポジトリと同じです。必要に応じて、[リポジトリ名] フィールドに名前を入力すると、フォークをさらに区別できます。
必要に応じて、[説明] フィールドにフォークの説明を入力します。
必要に応じて、 [DEFAULT ブランチのみをコピーする] を選びます。

オープンソースプロジェクトへのコントリビューションなど、多くのフォークシナリオでは、既定のブランチのみをコピーする必要があります。このオプションを選ばないと、すべてのブランチが新しいフォークにコピーされます。
[フォークの作成] をクリックします。

プロジェクトのフォークをクローンする

自分のアカウントに github/docs リポジトリのフォークを作成しましたが、変更作業を開始するには、自分のローカルコンピューターに取得する必要があります。

GitHub で、github/docs リポジトリの自分のフォークに移動します。
ファイルの一覧の上にある [コード] をクリックします。
リポジトリの URL をコピーします。
- HTTPS を使ってリポジトリをクローンするには、[HTTPS] の下のをクリックします。
- Organization の SSH 認証機関から発行された証明書などの SSH キーを使ってリポジトリをクローンするには、 [SSH] をクリックしてから、をクリックします。
- GitHub CLI を使ってリポジトリをクローンするには、 [GitHub CLI] をクリックしてから、をクリックします。
Mac または Linux では、ターミナルを開きます。 Windows では、Git Bash を開きます。
カレントワーキングディレクトリを、ディレクトリをクローンしたい場所に変更します。
「git clone」と入力し、既にコピーした URL を貼り付けます。次のように、YOUR-USERNAME ではなく、自分の GitHub のユーザー名が表示されます。
Shell
```
git clone https://github.com/YOUR-USERNAME/docs
```
```
git clone https://github.com/YOUR-USERNAME/docs
```
Enter キーを押します。これで、ローカルにクローンが作成されます。

トピックブランチで変更を加える

それでは、変更を加えましょう。始める前に、フォーク内にわかりやすい名前を付けたトピックブランチを作成することをお勧めします。トピックブランチを使うと、作業をリポジトリの既定のブランチから分離することができます。

Shell

git checkout -b YOUR_TOPIC_BRANCH

git checkout -b YOUR_TOPIC_BRANCH

トピックブランチに切り替えたら、お気に入りのテキストエディターまたは IDE を開いてコーディングを始めます。次のベストプラクティスに従ってください。

Copilot を使ってコードの提案を受けることで、変更に自信を持てるようにします。
コードを文書化し、テストを作成します。これらは見落とされがちですが、貢献が確実にマージされるために役立ちます。
実装要件をさらに理解するために、Copilot に issue について質問します。
Copilot を使って変更をレビューし、プロジェクトのコーディングスタイルとドキュメントの要件を満たしていることを確認します。
Copilot を使って、ローカルコンピューターでプロジェクトをビルドおよびテストする手順について支援してもらいます。

変更のコミットとプッシュ

変更の準備ができたら、リポジトリにステージングしてコミットできます。コミットメッセージを書くときは、コミットの内容を要約した 50 文字未満の明確で簡潔なコミットタイトルを使います。可能な場合は関連する変更を 1 つのコミットにグループ化します。ただし、関連のない変更は個別のコミットにします。

Shell

git add .
git commit -m "a short description of the change"

git add .
git commit -m "a short description of the change"

読みやすくなるように、コミットの説明行は 72 文字未満に抑えるようにします。ローカルの変更のコミットを完了し、GitHub にプッシュする準備ができたら、変更をリモートにプッシュします。

Shell

git push

git push

プル要求の送信

変更を GitHub にプッシュしたら、pull request を開く準備は完了です。ブランチで行った変更を完了していない場合でも、レビューのために pull request を開くことができます。貢献プロセスの早い段階で pull request を開くと、メンテナに認知され、変更に関する最初のフィードバックを受けられるようになります。

GitHub 上のフォークしたリポジトリに移動します。たとえば、「 https://github.com/YOUR-USERNAME/docs 」のように入力します。
最近プッシュしたブランチには "Compare & pull request" というプロンプトが表示されます。このボタンをクリックします。
そうでない場合は、[Pull request] タブに移動して、[New pull request] をクリックします。
base リポジトリが github/docs であり、ベースブランチがメインブランチ (例: main) であることを確認します。
head リポジトリが自分のフォーク (YOUR-USERNAME/docs) であり、比較ブランチが自分のブランチであることを確認します。
プルリクエストのタイトルと説明を入力します。説明には、自分の pull request によって解決する issue を記載します。たとえば、「 Closes: #15 」のように入力します。こうすると pull request のコンテキストが示され、pull request のマージ時に issue は自動的に解決状態になります。

ヒント

Pull request がレビュー用に送信された後は、強制プッシュを行わないでください。メンテナがフィードバックへの対応状況を確認しにくくなります。

プロジェクトメンテナとの連携

Pull request を送信した後の次の手順では、プロジェクトメンテナがレビューしてフィードバックを提供します。プロジェクトメンテナからは、コードベースのスタイルやアーキテクチャに合わせた変更を求められ、場合によっては、作業のかなりの部分のリファクターが必要になることがあります。

Pull request に関するフィードバックを受け取ったら、たとえ批判が厳しいと感じても、迅速かつプロフェッショナルに対応してください。通常、メンテナはコードの品質に重点を置いています。
Pull request に対して変更を求められた場合、その変更に対応するために新しい pull request を開かないでください。既存の pull request を開いたままにして、そこで変更を加えることで、メンテナはコンテキストを見失わずに済みます。
Pull request が何週間も未対応のままになっている場合は、フィードバックを求めるコメントを記載して丁寧にフォローアップします。メンテナのハンドルに直接言及しないでください。多くの場合、メンテナはオープンソースの作業と本業を両立させています。時間的な制約があることを理解して、良好なコラボレーションを促進しましょう。
貢献が受け入れられなかった場合は、次に貢献する際の参考になるように、メンテナにフィードバックを依頼してください。

次のステップ

ここでは、取り組むべき適切な issue の特定方法、メンテナがマージしたくなるコントリビューションを作成する方法、pull request のレビュープロセスを進める方法について説明しました。 GitHub のオープンソースコミュニティは、あなたの独自の視点とスキルを歓迎しています。興味をそそられる新しいプロジェクトを見つけ、取り組むべき issue を特定し、貢献を始めましょう。

この記事の内容