GitHub-GitHubオープンソースプロジェクトにどのように参加しますか?
転記:http://www.csdn.net/article/2014-04-14/2819293-Contributing-to-Open-Source-on-GitHub
要旨:本文はGithubの公式が与えたGithub上のオープンソースプロジェクトに参加するいくつかの指導であり、オープンソースコミュニティに参加したい開発者にとって良い参考である.
ここ1年のオープンソースプロジェクトは特に暑く、多くの技術大会やフォーラムがオープンソースプロジェクトをテーマに検討していることから、これはトレンドであることがわかる.Githubはオープンソースプロジェクトの有名な管理地として、誰も知らないと言え、ますます多くの個人と会社がGithubの大家族に参加し、オープンソースのために薄い力を尽くしている.個人的には、自分のプロジェクトをGithubに管理することは、Githubオープンソースプロジェクトに参加したことを意味しません.自分のプロジェクトをオープンソースしたとしか言えません.他の人が自由にダウンロードすることができます.
では、Githubのオープンソースプロジェクトにどのように参加すればいいのでしょうか.多くの人が疑問を持っていると思いますが、ネット上には「Pull Request」や「Commit」など、さまざまなチュートリアルがあります.しかし、これらのチュートリアルは全面的ではないか、完全に正確ではないことが多く、うまくいかないと誤解に陥る可能性があります.これに鑑みて、先日Githubの公式チームは素晴らしい文章Contributing to Open Source on GitHubを書いて、Githubのオープンソースプロジェクトにどのように参加するかを専門に指導しました.以下は原文の翻訳です.
オープンソースプロジェクトに参加する最善の方法は、あなたが使用している既存のプロジェクトに参加することです.Githubには500万以上のオープンソースプロジェクトがあり、recipes、HTML/CSS、Ruby、Astrophysicsなど、さまざまな分野の技術に関連しています.このガイドでは、典型的なプロジェクトで発生する可能性のあることと、オープンソースプロジェクトにどのように貢献するかを説明します.
プロジェクトを探して、すでに使用しているプロジェクトや興味のあるプロジェクトから始めることをお勧めします.ここにはいくつかの素晴らしい場所があります.
GitHub Explore:人気と人気のあるプロジェクト.
GitHub Stars:他の人にstarされたプロジェクト(自分のライブラリのプロジェクトを指す).
GitHub Showcases:関連ライブラリを検索できる方法です.
LayerVault News:フロントエンドとデザインに関するプロジェクト.
典型的なプロジェクト
次は、Githubオープンソースプロジェクトで遭遇する可能性のある要素です.
The Community(コミュニティ)
プロジェクトには通常、異なるロール(正規または非正規)の他のユーザーで構成されるコミュニティメンテナンスがあります.
所有者(Owner):プロジェクトが作成され、Githubアカウントにプロジェクトがあるユーザーまたは組織です.
メンテナと協力者(Maintainers and Collaborators):プロジェクトに力を入れ、プロジェクトの発展を促進するユーザー.通常、所有者とメンテナンス担当者は同じユーザーまたは組織であり、プロジェクトライブラリに書き込み権限があります.
貢献者(Contributors):プロジェクトに対してpull requestを発行し、プロジェクトにマージした各ユーザーが貢献者です.
コミュニティメンバー(Community Members):このプロジェクトをよく使用し、非常に関心を持っているユーザーは、機能の特徴とpull requestを議論する上で非常に活躍しています.
The Docs(ドキュメント)一般項目にあるファイル.
Readme:ほとんどのGithubプロジェクトにはREADMEが含まれています.mdファイル.readmeは、プロジェクトの概要と、プロジェクトの使用、構築、さらにどのように貢献するかに関する詳細を提供します.
Contributing:プロジェクトとプロジェクトの保守者が異なるため、プロジェクトごとに貢献する最善の方法が異なります.CONTRIBEUTINGと表記されたドキュメントに注意してください.Contributingドキュメントでは、プロジェクトのメンテナンス者が貢献するパッチや機能がどのような仕様に合致するかを詳細に説明しています.これには、テスト、コード構文仕様、パッチセットを書く領域が含まれます.
License:LICENSEファイルはもちろんこのプロジェクトのライセンスです.オープンソースプロジェクトのlicenseは、ユーザーにできることとできないこと(使用、修正、再配布など)を伝え、貢献者に他の人に許可することを伝えます.オープンソースプロジェクトにライセンスを加える方法はたくさんありますchoosealicense.comは、各ライセンスの意味についてもっと読みます.
Documentation and Wikis:多くの大規模なプロジェクトにはreadmeが1つだけでなく、彼らのプロジェクトをどのように使用するかを指導しています.この場合、通常、ライブラリ内の「docs」という別のファイルまたはフォルダへのリンクを見つけることができます.
また、このライブラリでは、ドキュメントの代わりにGithub wikiを使用することもできます.
一つのプロジェクトに貢献して、そのプロジェクトを理解する関連資料を見つけた以上、次はいくつかの行動を取ることができます.
トピックを作成します.使用しているプロジェクトのバグを見つけたり(修復方法が分からない)、ドキュメントに理解できないか、プロジェクトに疑問がある場合は、トピックを作成しましょう.これは簡単で、一般的にどんな話題を作成しても、この問題が発生した唯一の人ではない可能性があります.そのため、他の人はあなたの話題が役に立つことに気づくかもしれません.詳細については、Issues guideを参照してください.
トピックの専門ヒント
話題を作る前に既存の話題をチェックします.話題の重複は双方に利益がないので、開いている話題と閉じている話題全体を検索して、あなたが直面している問題がすでに解決されているかどうかをチェックします.
自分の問題に対してはっきりした認識を持っていなければなりません:期待した結果は何ですか?何が起こったの?他の人がこの問題をどのように再現するかを詳しく説明します.
この問題をJSPedbleやCodePenのようなプラットフォームで再現し、問題demoへのリンクを与えます.
ブラウザ、ライブラリ、オペレーティングシステム、バージョン番号など、システムに関する詳細が含まれています.
あなたの話題やGistにエラー出力やログを貼り付けます.話題に貼れば、3つの反引用符
Pull Requestバグを修正したり、自分で機能を追加したりできるなら、素晴らしいですね.pull requestを送ってください.contributingに関するドキュメントをすでに読んでいることを確認し、licenseとCLAに署名したことを理解する必要があります(必要であれば).pull requestをコミットすると、メンテナンス者はあなたのブランチを既存のブランチと比較して、あなたの変更をマージするかどうかを決定します(つまりpull in).
Pull Requestプロフェッショナルヒント
Forkこのプロジェクトライブラリとcloneをローカルにします.リモートとして追加することで、元のupstreamライブラリにローカルに接続します.常に「upstream」ライブラリpull inからライブラリの最新を維持するように変更されます.これにより、pull requestをコミットすると、マージ競合は起こり得ません.ここをクリックして、より多くの指導の詳細を見てください.
あなたの編集者のために単独でブランチを作成します.
発生した問題と、その問題をどのように再現するか、またはなぜあなたの機能が役に立つのかを明確にしてください.そして同じように、どのようなステップがあるかを明らかにしなければなりません.
テストしたほうがいいです.既存のテスト(存在する場合)で変更を実行し、必要に応じて新しいテストを作成します.テストが存在するかどうかにかかわらず、変更が既存のプロジェクトを破壊しないことを確認します.
変更にHTML/CSSの違いが含まれている場合は、変更前と変更後のスクリーンショットを含めてください.あなたの画像をpull requestの本文にドラッグします.
できる限りプロジェクトのスタイルに努力してください.これは、自分のGithubライブラリで採用されているインデント、セミコロン、コメントとは異なるものを使用することを意味する可能性がありますが、これにより、メンテナンス者が統合されやすくなり、他の人が理解しやすくなり、今後のメンテナンスが容易になります.
オープンPull Requests pull requestを開くと、あなたが提案した変更をめぐって議論があります.他の貢献者やユーザーが参加する可能性がありますが、最終的にはメンテナンス者が決定します.pull requestに変更を要求される可能性があります.そうすれば、ブランチにcommitを追加してpushしてください.既存のpull requestに自動的に追加されます.
もしあなたのpull requestが合併されたら--よかった!合併されていなければ、大したことはありません.これはプロジェクトのメンテナンス者が望んでいる変更ではなく、バグや機能に力を入れているのかもしれません.このような状況が発生する可能性があるので、私たちの提案は、受け取った結果にフィードバックし、さらに努力して再びpull requestを出たり、自分のオープンソースプロジェクトを作成したりすることです.
VIA GitHub&CSDNブログ
要旨:本文はGithubの公式が与えたGithub上のオープンソースプロジェクトに参加するいくつかの指導であり、オープンソースコミュニティに参加したい開発者にとって良い参考である.
ここ1年のオープンソースプロジェクトは特に暑く、多くの技術大会やフォーラムがオープンソースプロジェクトをテーマに検討していることから、これはトレンドであることがわかる.Githubはオープンソースプロジェクトの有名な管理地として、誰も知らないと言え、ますます多くの個人と会社がGithubの大家族に参加し、オープンソースのために薄い力を尽くしている.個人的には、自分のプロジェクトをGithubに管理することは、Githubオープンソースプロジェクトに参加したことを意味しません.自分のプロジェクトをオープンソースしたとしか言えません.他の人が自由にダウンロードすることができます.
では、Githubのオープンソースプロジェクトにどのように参加すればいいのでしょうか.多くの人が疑問を持っていると思いますが、ネット上には「Pull Request」や「Commit」など、さまざまなチュートリアルがあります.しかし、これらのチュートリアルは全面的ではないか、完全に正確ではないことが多く、うまくいかないと誤解に陥る可能性があります.これに鑑みて、先日Githubの公式チームは素晴らしい文章Contributing to Open Source on GitHubを書いて、Githubのオープンソースプロジェクトにどのように参加するかを専門に指導しました.以下は原文の翻訳です.
オープンソースプロジェクトに参加する最善の方法は、あなたが使用している既存のプロジェクトに参加することです.Githubには500万以上のオープンソースプロジェクトがあり、recipes、HTML/CSS、Ruby、Astrophysicsなど、さまざまな分野の技術に関連しています.このガイドでは、典型的なプロジェクトで発生する可能性のあることと、オープンソースプロジェクトにどのように貢献するかを説明します.
プロジェクトを探して、すでに使用しているプロジェクトや興味のあるプロジェクトから始めることをお勧めします.ここにはいくつかの素晴らしい場所があります.
GitHub Explore:人気と人気のあるプロジェクト.
GitHub Stars:他の人にstarされたプロジェクト(自分のライブラリのプロジェクトを指す).
GitHub Showcases:関連ライブラリを検索できる方法です.
LayerVault News:フロントエンドとデザインに関するプロジェクト.
典型的なプロジェクト
次は、Githubオープンソースプロジェクトで遭遇する可能性のある要素です.
The Community(コミュニティ)
プロジェクトには通常、異なるロール(正規または非正規)の他のユーザーで構成されるコミュニティメンテナンスがあります.
所有者(Owner):プロジェクトが作成され、Githubアカウントにプロジェクトがあるユーザーまたは組織です.
メンテナと協力者(Maintainers and Collaborators):プロジェクトに力を入れ、プロジェクトの発展を促進するユーザー.通常、所有者とメンテナンス担当者は同じユーザーまたは組織であり、プロジェクトライブラリに書き込み権限があります.
貢献者(Contributors):プロジェクトに対してpull requestを発行し、プロジェクトにマージした各ユーザーが貢献者です.
コミュニティメンバー(Community Members):このプロジェクトをよく使用し、非常に関心を持っているユーザーは、機能の特徴とpull requestを議論する上で非常に活躍しています.
The Docs(ドキュメント)一般項目にあるファイル.
Readme:ほとんどのGithubプロジェクトにはREADMEが含まれています.mdファイル.readmeは、プロジェクトの概要と、プロジェクトの使用、構築、さらにどのように貢献するかに関する詳細を提供します.
Contributing:プロジェクトとプロジェクトの保守者が異なるため、プロジェクトごとに貢献する最善の方法が異なります.CONTRIBEUTINGと表記されたドキュメントに注意してください.Contributingドキュメントでは、プロジェクトのメンテナンス者が貢献するパッチや機能がどのような仕様に合致するかを詳細に説明しています.これには、テスト、コード構文仕様、パッチセットを書く領域が含まれます.
License:LICENSEファイルはもちろんこのプロジェクトのライセンスです.オープンソースプロジェクトのlicenseは、ユーザーにできることとできないこと(使用、修正、再配布など)を伝え、貢献者に他の人に許可することを伝えます.オープンソースプロジェクトにライセンスを加える方法はたくさんありますchoosealicense.comは、各ライセンスの意味についてもっと読みます.
Documentation and Wikis:多くの大規模なプロジェクトにはreadmeが1つだけでなく、彼らのプロジェクトをどのように使用するかを指導しています.この場合、通常、ライブラリ内の「docs」という別のファイルまたはフォルダへのリンクを見つけることができます.
また、このライブラリでは、ドキュメントの代わりにGithub wikiを使用することもできます.
一つのプロジェクトに貢献して、そのプロジェクトを理解する関連資料を見つけた以上、次はいくつかの行動を取ることができます.
トピックを作成します.使用しているプロジェクトのバグを見つけたり(修復方法が分からない)、ドキュメントに理解できないか、プロジェクトに疑問がある場合は、トピックを作成しましょう.これは簡単で、一般的にどんな話題を作成しても、この問題が発生した唯一の人ではない可能性があります.そのため、他の人はあなたの話題が役に立つことに気づくかもしれません.詳細については、Issues guideを参照してください.
トピックの専門ヒント
話題を作る前に既存の話題をチェックします.話題の重複は双方に利益がないので、開いている話題と閉じている話題全体を検索して、あなたが直面している問題がすでに解決されているかどうかをチェックします.
自分の問題に対してはっきりした認識を持っていなければなりません:期待した結果は何ですか?何が起こったの?他の人がこの問題をどのように再現するかを詳しく説明します.
この問題をJSPedbleやCodePenのようなプラットフォームで再現し、問題demoへのリンクを与えます.
ブラウザ、ライブラリ、オペレーティングシステム、バージョン番号など、システムに関する詳細が含まれています.
あなたの話題やGistにエラー出力やログを貼り付けます.話題に貼れば、3つの反引用符
```で囲まれて、うまく表現できるようにしてください. Pull Requestバグを修正したり、自分で機能を追加したりできるなら、素晴らしいですね.pull requestを送ってください.contributingに関するドキュメントをすでに読んでいることを確認し、licenseとCLAに署名したことを理解する必要があります(必要であれば).pull requestをコミットすると、メンテナンス者はあなたのブランチを既存のブランチと比較して、あなたの変更をマージするかどうかを決定します(つまりpull in).
Pull Requestプロフェッショナルヒント
Forkこのプロジェクトライブラリとcloneをローカルにします.リモートとして追加することで、元のupstreamライブラリにローカルに接続します.常に「upstream」ライブラリpull inからライブラリの最新を維持するように変更されます.これにより、pull requestをコミットすると、マージ競合は起こり得ません.ここをクリックして、より多くの指導の詳細を見てください.
あなたの編集者のために単独でブランチを作成します.
発生した問題と、その問題をどのように再現するか、またはなぜあなたの機能が役に立つのかを明確にしてください.そして同じように、どのようなステップがあるかを明らかにしなければなりません.
テストしたほうがいいです.既存のテスト(存在する場合)で変更を実行し、必要に応じて新しいテストを作成します.テストが存在するかどうかにかかわらず、変更が既存のプロジェクトを破壊しないことを確認します.
変更にHTML/CSSの違いが含まれている場合は、変更前と変更後のスクリーンショットを含めてください.あなたの画像をpull requestの本文にドラッグします.
できる限りプロジェクトのスタイルに努力してください.これは、自分のGithubライブラリで採用されているインデント、セミコロン、コメントとは異なるものを使用することを意味する可能性がありますが、これにより、メンテナンス者が統合されやすくなり、他の人が理解しやすくなり、今後のメンテナンスが容易になります.
オープンPull Requests pull requestを開くと、あなたが提案した変更をめぐって議論があります.他の貢献者やユーザーが参加する可能性がありますが、最終的にはメンテナンス者が決定します.pull requestに変更を要求される可能性があります.そうすれば、ブランチにcommitを追加してpushしてください.既存のpull requestに自動的に追加されます.
もしあなたのpull requestが合併されたら--よかった!合併されていなければ、大したことはありません.これはプロジェクトのメンテナンス者が望んでいる変更ではなく、バグや機能に力を入れているのかもしれません.このような状況が発生する可能性があるので、私たちの提案は、受け取った結果にフィードバックし、さらに努力して再びpull requestを出たり、自分のオープンソースプロジェクトを作成したりすることです.
VIA GitHub&CSDNブログ