Githubでオープンソースに貢献するには？

オープンソースに参加する素晴らしい方法は、現在取り組んでいるプロジェクトに貢献することです。Githubは、最大500万のオープンソースプロジェクトのホスティングを提供しています。Githubは、500万ものオープンソースプロジェクトをホスティングしています。このガイドでは、典型的なプロジェクトで作業するすべての側面と、コントリビューションに参加する方法について説明します。

プロジェクトを探す

まずは、すでに使っているアイテムから調べてみることをお勧めします。以下は、訪問する価値のあるリンクです：

• - GitHub Explore: What's Hot and What's Not.
• - GitHub Stars: 他の人から評価されたプロジェクトのリスト。
• · GitHub Showcases: 関連リポジトリを探す.
• · LayerVault News: フロントエンドとデザインプロジェクト.

[]

典型的なプロジェクト

オープンソースプロジェクトでアクセスされる可能性のある要素をいくつか紹介します。

コミュニティ

プロジェクトには通常、さまざまな役割を持つ他のユーザーによって作られたコミュニティが存在します：

• 所有者はプロジェクト作成者またはその組織であり、このアカウントIDがプロジェクトを所有します。
• メンテナと共同作業者は、プロジェクトの主要な開発者であり、プロジェクトの方向性の舵取りをする責任者です。通常、プロジェクトオーナーとメンテナーは同じ人です。彼らはリポジトリへの書き込みアクセス権を持っています。
• コントリビューターとは、プロジェクトに対してプルオペレーションを行い、それをプロジェクトにマージする人のことです。
• コミュニティメンバーは、プロジェクトに深い関心を持ち、その機能やプルリクエストについて積極的に議論する、プロジェクトの常連ユーザーです。

ドキュメント

プロジェクトに含まれる共通文書ファイル

読んでください。

Github上のほぼすべてのプロジェクトにはREADME.mdファイルが含まれています。このReadmeには、プロジェクトの使い方やコンパイル方法、場合によってはプロジェクトに関わる詳細な地図が記載されています。

参加ドキュメント

プロジェクトやそれを維持する人々には違いがあり、参加する方法も異なります。CONTRIBUTINGというドキュメントに従うことができます。CONTRIBUTING ドキュメントには、プロジェクトのメンテナが望むパッチやコントリビュートされた機能の仕様が詳細に記述されています。これには、テストの書き方、コードのスタイル、パッチの適用範囲などが含まれます。

ライセンス

LICENSEファイルは、プロジェクトのライセンス記述ファイルです。オープンソースプロジェクトのライセンスは、参加者の権利と同様に、何ができて何ができないかをユーザーに伝えます。オープンソースプロジェクトのライセンスと配布には多くの方法があり、このウェブサイトでさまざまなライセンスの意味を知ることができます:choosealicense.com。

ドキュメントとwiki

多くの大規模プロジェクトでは、Readmeを省略して、ユーザーがプロジェクトをどのように使えるかを指定しています。その場合、通常、リポジトリにリンクや「docs」というフォルダがあります。

[]

あるいは、リポジトリはドキュメントの代わりにGithubのウィキシステムを使うこともできます。

プロジェクトに参加する

プロジェクトを理解するための材料が見つかったら、さっそく行動に移しましょう。

課題の作成

もしあなたが使っているプロジェクトにバグを見つけたり、それに関する情報をドキュメントで見つけられなかったり、プロジェクトについて質問がある場合は、issueを作成してください！issueの内容や今抱えている問題が何であれ、おそらく質問を持っているのはあなただけではありませんし、他のユーザーがissueから助けを得られるかもしれません！他のユーザーがその課題から助けを得られるかもしれません。また、issueがどのように機能するかについては、[]ご覧ください。

Issuesプロのアドバイス

• 現在のissueの中に、あなたに関連するものがないか確認してください。重複したissueを投稿すると、双方の効率が低下します。オープンissueとクローズissueを検索して、現在提案しているissueが言及されていないか確認してください。
• 質問を明確にしてください：何が望ましい出力で、実際に何が起こったのか？また、他の人はどのようにこの問題を再現したのでしょうか。
• 例へのリンク:jsfiddleやcodepenの例へのリンクのような、問題を再現する方法。
• システム環境の詳細を報告します。例えば、使用されているブラウザ、使用されているライブラリ、オペレーティングシステムのバージョンなどです。
• エラー出力やログを issue やGistに貼り付けてください。エラー出力やログを issue に貼り付ける場合は、バッククォート ``` を3つ使うと見栄えが良くなります。

Pull

もしあなたが自分でバグを修正したり、新しい機能を追加する能力を持っているなら、それは素晴らしいことです。コードベースへのプルリクエストを行いましょう！プルリクエストを提出すると、プロジェクトのメンテナはそのブランチを現在のブランチと比較して、変更をマージするかどうかを決めることができます。

Pull専門家の助言を求める

• リポジトリをし、ローカルにクローンします。これは、ローカルリポジトリを最初の「上流」リポジトリに接続し、リモート接続としてマークすることで行います。随時「上流」リポジトリから変更を取り込むことで、プルリクエスト時に最新版が利用できるようになり、マージ競合の可能性が低くなります。詳しい手順はこちらをご覧ください。
• エディター用の作成します。
• 問題がどのようにして発生したのか、また、他の人がその問題や提出した機能をどのように再現することができるのかを明確に理解することは有用です。同様に、変更の実施手順についても明確に理解してください。
• テストを実施するのが最善です。可能であれば、既存のテスト項目の変更をテストし、必要であれば新しいテストを作成します。テストが存在するかどうかに関係なく、変更が既存のプロジェクトを混乱させないようにしてください。
• html/cssの差分を含む、変更前と変更後のスクリーンショットをプルリクエストに提供し、イメージをドラッグ＆ドロップしてください。

プルリクエストを開く

[]

もしプルリクエストがマージされれば、それは素晴らしいことです！プロジェクトメンテナが気づかなかったか、すでに何か手を打ったのかもしれません。この時点で、あなたが受け取ったフィードバックを受け入れ、プルリクエストを再度提出するか、あなた自身のオープンソースプロジェクトを作成するかして、作業を続けることをお勧めします。