オープンソースへの貢献

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

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

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

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

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

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

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

ガイドラインを見つける

このようなガイドラインと要件にアクセスするには、[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 に関するコンテキストを提供します。

1.        **
          ** リポジトリの `github/docs` タブに移動し、**[Labels]** フィルターを使って [help wanted] を選ぶと、コミュニティのヘルプが必要であるとメンテナが特にマークした未解決の issue が表示されます。
   

2. Issue の一覧に目を通し、取り組みたい issue を見つけてください。

3. 移動先: https://github.com/copilot

4. 1. 移動先: https://github.com/copilot

      Text

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

5. プロンプト ボックスに次のプロンプトを入力します。 提供されているコンテキスト Copilot と、他の共同作成者やメンテナからのコメントを読んで、その issue に取り組むかどうかを判断します。

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

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

1. この例では、github/docs リポジトリのフォークを作成する手順について説明します。

2. https://github.com/github/docs にある GitHub Docs プロジェクトに移動します。

3. ページの右上隅の [フォーク] を選択します。

4. [所有者] の下のドロップダウン メニューを選び、フォークされたリポジトリの所有者をクリックします。 既定では、フォークの名前はその上流リポジトリと同じです。

5. 必要に応じて、[リポジトリ名] フィールドに名前を入力すると、フォークをさらに区別できます。

6. 必要に応じて、[説明] フィールドにフォークの説明を入力します。

   必要に応じて、 [DEFAULT ブランチのみをコピーする] を選びます。 オープンソース プロジェクトへのコントリビューションなど、多くのフォーク シナリオでは、既定のブランチのみをコピーする必要があります。

7. このオプションを選ばないと、すべてのブランチが新しいフォークにコピーされます。

          **[フォークの作成]** をクリックします。

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

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

2. ファイル一覧の上にある [ Code] をクリックします。

   

3. リポジトリの URL をコピーします。

   • HTTPS を使用してリポジトリを複製するには、"HTTPS" の下にある をクリックします。

   • Organization の SSH 認証機関から発行された証明書などの SSH キーを使ってリポジトリをクローンするには、 [SSH] 、 の順にクリックします。

   • GitHub CLI を使ってリポジトリをクローンするには、 [GitHub CLI] をクリックしてから、 をクリックします。

     

4. GitHub で、自分のフォークのgithub/docsリポジトリに移動します。 1. ファイル一覧の上にある [ Code] をクリックします。

   

5. リポジトリの URL をコピーします。

   • HTTPS を使用してリポジトリを複製するには、"HTTPS" の下にある をクリックします。

   • Organization の SSH 認証機関から発行された証明書などの SSH キーを使ってリポジトリをクローンするには、 [SSH] 、 の順にクリックします。

   • GitHub CLI を使ってリポジトリをクローンするには、 [GitHub CLI] をクリックしてから、 をクリックします。

     

6. カレントワーキングディレクトリを、ディレクトリをクローンしたい場所に変更します。

7. Mac または Linux では、ターミナルを開きます。 Windowsで Git Bash を開きます。

   Shell

   git clone https://github.com/YOUR-USERNAME/docs
   

8. カレントディレクトリを変更して、リポジトリをクローンするためのコマンドを実行します。 「 git clone」と入力し、先ほどコピーした URL を貼り付けます。

次のように、YOUR-USERNAME ではなく、自分の GitHub のユーザー名が表示されます。

          **Enter** キーを押します。 これで、ローカルにクローンが作成されます。 トピックブランチで変更を行う

git checkout -b YOUR_TOPIC_BRANCH

git checkout -b YOUR_TOPIC_BRANCH

それでは、変更を加えましょう。 始める前に、フォーク内にわかりやすい名前を付けたトピック ブランチを作成することをお勧めします。

• トピック ブランチを使うと、作業をリポジトリの既定のブランチから分離することができます。
• トピック ブランチに切り替えたら、お気に入りのテキスト エディターまたは IDE を開いてコーディングを始めます。 次のベスト プラクティスに従ってください。
• Copilot を使ってコードの提案を受けることで、変更に自信を持てるようにします。
• コードを文書化し、テストを作成します。
• これらは見落とされがちですが、あなたの貢献が意図通りにマージされるように役立ちます。

実装要件をさらに理解するために、Copilot に issue について質問します。

Copilot を使って変更をレビューし、プロジェクトのコーディング スタイルとドキュメントの要件を満たしていることを確認します。 Copilot を使って、ローカル コンピューターでプロジェクトをビルドおよびテストする手順について支援してもらいます。 あなたの変更をコミットしてプッシュする

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

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

変更の準備ができたら、リポジトリにステージングしてコミットできます。 コミット メッセージを書くときは、コミットの内容を要約した 50 文字未満の明確で簡潔なコミット タイトルを使います。

git push

git push

可能な場合は関連する変更を 1 つのコミットにグループ化します。ただし、関連のない変更は個別のコミットにします。

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

1. 変更を GitHub にプッシュしたら、pull request を開く準備は完了です。 ブランチで行った変更を完了していない場合でも、レビューのために pull request を開くことができます。
2. 貢献プロセスの早い段階で pull request を開くと、メンテナに認知され、変更に関する最初のフィードバックを受けられるようになります。 GitHubでフォークされたリポジトリに移動します。
3. たとえば、「 https://github.com/YOUR-USERNAME/docs 」のように入力します。
4. 最近プッシュしたブランチには "Compare & pull request" というプロンプトが表示されます。
5. このボタンをクリックします。
6. そうでない場合は、[Pull request] タブに移動して、[New pull request] をクリックします。 base リポジトリが github/docs であり、ベース ブランチがメイン ブランチ (例: main) であることを確認します。 head リポジトリが自分のフォーク (YOUR-USERNAME/docs) であり、比較ブランチが自分のブランチであることを確認します。 プルリクエストのタイトルと説明を入力します。

こうすると pull request のコンテキストが示され、pull request のマージ時に issue は自動的に解決状態になります。

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

• プロジェクト メンテナとの連携 Pull request を送信した後の次の手順では、プロジェクト メンテナがレビューしてフィードバックを提供します。
• プロジェクト メンテナからは、コードベースのスタイルやアーキテクチャに合わせた変更を求められ、場合によっては、作業のかなりの部分のリファクターが必要になることがあります。 Pull request に関するフィードバックを受け取ったら、たとえ批判が厳しいと感じても、迅速かつプロフェッショナルに対応してください。
• 通常、メンテナはコードの品質に重点を置いています。 Pull request に対して変更を求められた場合、その変更に対応するために新しい pull request を開かないでください。 既存の pull request を開いたままにして、そこで変更を加えることで、メンテナはコンテキストを見失わずに済みます。
• Pull request が何週間も未対応のままになっている場合は、フィードバックを求めるコメントを記載して丁寧にフォローアップします。

メンテナのハンドルに直接言及しないでください。

保守担当者は、多くの場合、オープンソース仕事とフルタイムの責任のバランスを取り、時間の制約を理解すると、より良いコラボレーションが促進されます。 貢献が受け入れられなかった場合は、次に貢献する際の参考になるように、メンテナにフィードバックを依頼してください。 次のステップ