オープンソースにコントリビュートする方法

オープンソースにコントリビュートする理由は？

オープンソースにコントリビュートすることはやりがいがあり、あなたが思い描くどんなスキルに対しても、学習し、教え、経験を積むことができます。

なぜ人々はオープンソースにコントリビュートするのでしょう？理由は様々です！

既に持っているスキルを改善する

あなたが練習したいと思っていることが、コーディングであれ、UIデザインやグラフィックデザイン、文章を書くこと、組織を作ることであれ、オープンソースプロジェクトにはあなたのためのタスクがあります。

似たようなことに興味を持っている人に会う

暖かく迎えてくれるコミュニティを持ったオープンソースプロジェクトでは、人々が何年経っても戻って来続けます。多くの人がオープンソースに参加することによって生涯に渡る友好関係を築いています。たとえそれがカンファレンスでばったり会うという形であったり、夜遅くにブリトーについてチャットをしているという形であれ。

メンターを見つけ互いに教えあう

同じプロジェクトで他の人と一緒に働くということは、あなたが仕事をやる方法を説明するだけでなく、他の人に助けを求める必要が出てきます。学習し、教えることは関わる人全てにとって充実した活動となります。

あなたの評判（やキャリア）を育てるのに役立つ成果物を作り上げる

その定義からして、すべてのオープンソースはパブリックです。このことはあなたがやっていることをどこでも自由に紹介できる事例を得られるということを意味します。

ピープルスキルを学ぶ

オープンソースは、人々の衝突を解消したり、チームを組織したり、仕事の優先順位付けをするなどといったリーダーシップやマネジメントスキルを実践する機会を提供してくれます。

変化を起こせるようになる助けとなる、たとえそれが小さな変化であったとしても

あなたは何もオープンソースに生涯に渡って常に参加し続ける必要があるわけではありません。ウェブサイトでタイポを見つけて、直してほしいと思ったことはありませんか？オープンソースプロジェクトでは、あなたがそれをできるのです。オープンソースによって、人々は人生や世界をどう経験するかが自分自身のものだと感じられることを助けてくれます。そしてその事自体が大きな喜びとなるのです。

コントリビュートするということが意味するもの

オープンソースコントリビューターになりたてで自信が持てないと感じているかもしれません。どのようにして正しいプロジェクトを見つけるのでしょう？もしコーディングの仕方を知らないとしたらどうでしょう？もし何かが間違ってしまったらどうしましょう？

心配ありません！オープンソースプロジェクトに関わるにはあらゆる方法があります。そして、少しのコツがあればあなたの経験を最大限活かす事ができるでしょう。

かならずしもコードを書く必要はありません

オープンソースへのコントリビュートについてのよくある勘違いとしては、あなたはコードを書く必要があるというものです。実際、それはしばしばプロジェクトの中で最も無視されるか見落とされている部分です。この種のコントリビュートを行うことによってプロジェクトに対して 非常に大きな 助けとなります。

たとえコードを書くことが好きであったとしても、他の種類のコントリビュートはプロジェクトに関わり、他のコミュニティメンバーに会う良いやり方です。このような関係を作ることはそのプロジェクトの他の部分に関わる人と仕事をする機会を与えてくれます。

イベントを計画するのが好きですか？

@fzamperin が NodeSchool でやったようにワークショップやミートアップを開催する
(もしあるなら)プロジェクトのカンファレンスを企画する
コミュニティメンバーが発表するのにちょうどよいカンファレンスを見つけるのを手伝う

デザインをするのが好きですか？

プロジェクトのユーザビリティを向上させるためにレイアウトを再構成する
Drupal で提案されているように、プロジェクトのナビゲーションやメニューを再構成して改善するためにユーザーリサーチを実施する
プロジェクトが一貫したビジュアルデザインを保てるようにスタイルガイドを作る
hapi.js のコントリビューターがやったように、Tシャツや新しいロゴのデザインをする

文章を書くのが好きですか？

プロジェクトのドキュメントを書いたり改善する
プロジェクトがどのように使われているかの事例を選別する
プロジェクトのニュースレターを始めたり、メーリングリストのハイライトを整理する
PyPA のコントリビューターがやったように、プロジェクトのチュートリアルを書く
プロジェクトのドキュメントを翻訳する

整理するのが好きですか？

整理するために、重複しているイシューを紐づけたり、新しいイシューのラベルを提案する
@nzakas が ESLint でやったように、オープンなイシューをくまなく調べ、古いものをクローズすることを提案する
議論を前進させるために、最近オープンされたイシューの内容を明確にする質問をする

コードを書くのが好きですか？

@dianjin が Leaflet でやったように、取り組むオープンなイシューを見つける
新しい機能を書く手伝いをできるかどうか聞いてみる
プロジェクトのセットアップを自動化する
ツールやテストの改善をする

人々を助けるのが好きですか？

Stack Overflow (この Postgres の例のように)や Reddit でのプロジェクトに対する質問に答える
オープンイシューでの質問に答える
ディスカッションボードやコンバセーションチャネルでの会話の進行をする

他の人がコードを書くのを助けるのが好きですか？

他の人のコードをレビューする
プロジェクトがどのように使われるのかについてチュートリアルを書く
@ereichert が Rust で @bronzdoc にやったように、他のコントリビューターのメンターをやる

必ずしもソフトウェアプロジェクトで働く必要はありません

「オープンソース」はしばしばソフトウェアのことを指していますが、あなたはどんなものでもコラボレートできるのです。本やレシピ、リストや授業もオープンソースプロジェクトとして開発されているのです。

例えば:

@sindresorhus は“素敵なもの”のリストを作っています
@h5bp はフロントエンド開発者のための面接での質問集をまとめています
@stuartlynn と @nicole-a-tesla はツノメドリについての愉快な事柄のコレクションを作っています

たとえあなたがソフトウェアエンジニアだったとしても、ドキュメントを書くことはオープンソース活動を始めるにあたって良いスタートとなります。ときにはコードを書かないプロジェクトに関わることのほうが障壁が低く、コラボレーションのプロセスを通じて自信と経験を身につけることができます。

新しいプロジェクトに順応しよう

タイポの修正以上のものであればなんでも、オープンソースにコントリビュートするというのは知らない人たちのパーティに近づいていくようなものです。もしあなたがラマについて話し始めたとして、一方で彼らは金魚について深い議論をしていたら、おそらくあなたのことを少し奇妙な目で見るでしょう。

盲目的にあなた自身の提案をする前に、部屋の雰囲気を読み取る方法を学びましょう。そうすることによって、あなたのアイデアの存在に気づいてもらい聞き入れてもらうチャンスが増すでしょう。

オープンソースプロジェクトの構造

それぞれのオープンソースコミュニティは異なります。

ある一つのオープンソースプロジェクトで長い時間を過ごしたということは、ある一つのオープンソースプロジェクトについて理解したということを意味します。異なるプロジェクトに移ると、使っている言葉や規範、コミュニケーションスタイルが全く異なることに気づくでしょう。

とはいえ、多くのオープンソースプロジェクトは似たような組織構造を持っています。異なるコミュニティの役割や全体のプロセスを理解することは新しいプロジェクトに早く順応するための助けになるでしょう。

典型的なオープンソースプロジェクトは下記のような種類の人々がいます:

オーサー: そのプロジェクトを作った人(たち)もしくは組織
オーナー: 組織やリポジトリに対して管理上の所有権を持っている人(たち)もしくは組織(かならずしも元のオーサーと同じとは限らない)
メンテナー: ビジョンを推し進め、プロジェクトの組織的なマネジメントを行うコントリビューター(彼らはオーサーやオーナーであることもある)
コントリビューター: プロジェクトに対して何かしらのコントリビュートをするすべての人
コミュニティメンバー: プロジェクトを使っている人々。彼らは議論をしたり、プロジェクトの方向性に対して意見を表明したりする

より大きなプロジェクトでは、ツールの整備やコミュニティのモデレートやイベントの運営など異なるタスクに特化した分科会やワーキンググループがあるかもしれません。プロジェクトのウェブサイトの「チーム」についてのページや、リポジトリの運営に関するドキュメントをみて、こういった情報を見つけましょう。

プロジェクトにはドキュメントもあります。これらのファイルはたいていリポジトリのトップレベルに置かれています。

LICENSE: その定義から、すべてのオープンソースプロジェクトはオープンソースライセンスを持っている必要があります。もしそのプロジェクトがライセンスを持っていないのであれば、それはオープンソースではありません。
README: README はそのプロジェクトへの新しいコミュニティメンバーを迎えるための操作マニュアルです。そこではなぜそのプロジェクトが便利で、どのように始めるかの説明があります。
CONTRIBUTING: README が人々がそのプロジェクトを使う手助けをする一方、 CONTRIBUTING ドキュメントは人々が コントリビュートする 手助けをします。そこではどういった種類のコントリビュートが必要とされていて、そのプロセスがどうなっているかの説明があります。すべてのプロジェクトが CONTRIBUTING ファイルを持つわけではないですが、そのファイルがあることによって、そのプロジェクトがコントリビュートを歓迎していることの印になります。
CODE_OF_CONDUCT: 行動規範は参加者の振る舞いに対する基本原則を設定し、友好的な環境を作る手助けをします。すべてのプロジェクトが CODE_OF_CONDUCT ファイルを持つわけではないですが、そのファイルがあることによって、そのプロジェクトがコントリビュートを歓迎していることの印になります。
その他のドキュメント: それ以外にも、特に大きなプロジェクトではチュートリアル、ウォークスルー、運営方針などといったドキュメントがあることがあります。

最後に、オープンソースプロジェクトは議論を整理するために次のようなツールを使います。アーカイブを読み通すことで、そのコミュニティがどのように考え動いてきたかを把握することができるでしょう。

イシュートラッカー: そのプロジェクトに関連するイシューを議論する場所
プルリクエスト: 作業中の変更について議論し、レビューをする場所
ディスカッションフォーラムやメーリングリスト: いくつかのプロジェクトではあるトピックについて会話 (例えば、バグの報告や機能要望の代わりに 「これはどうやって・・・すると良いのでしょう？」 や 「・・・についてどう思いますか？」 といったもの) をするのにこれらのチャネルを使うかもしれません。また、すべての会話をイシュートラッカー上で行うプロジェクトもあります。
同期的なチャットチャネル: カジュアルな会話やコラボレーション、簡単なやりとりについては ( Slack や IRC のような) チャットチャネルを使うプロジェクトもあります。

コントリビュートするプロジェクトを見つけよう

さてあなたはオープンソースプロジェクトがどのように働くのかを理解しました。次はコントリビュートするプロジェクトを見つける番です！

もしあなたがこれまでにオープンソースプロジェクトにコントリビュートしたことが一度もないのであれば、アメリカ大統領のジョン・F・ケネディのアドバイスを聞いてみましょう。彼はかつて、 「あなたの国があなたのために何をしてくれるのかを問うのではなく、あなたが国のために何ができるかを問いなさい」 と言いました。

オープンソースへのコントリビュートはあらゆる階層で、プロジェクトをまたいで行われています。あなたの最初のコントリビュートが具体的にどういったものであるかや、どのようなものなのかを考えすぎる必要はありません。

代わりにあなたが既に使っていたり使いたいと思っているプロジェクトについて考え始めましょう。活発にコントリビュートすることになるプロジェクトは、何度も戻ってきたいと思うようなものなのです。

そういったプロジェクトの中で、何かをよくできたり違ったものにできると考え始めたときはいつでも、あなたの直感に従って行動しましょう。

オープンソースは排他的なクラブではありません。あなたのような人々からなっているのです。「オープンソース」は世の中の問題が解決可能であると扱うための単なるきらびやかな名前でしかないのです。

README を読んで、壊れたリンクやタイポを見つけるかもしれません。もしくは、あなたは新しいユーザーで、何かが壊れていたり、ドキュメントに書かれているべきと考えるイシューがあるかもしれません。それを無視して先に進んだり、他の誰かに直してとお願いする代わりに、あなたが参加することで手助けができないかどうか確かめてみましょう。これがオープンソースというものなのです！

オープンソースへのふとしたコントリビュートの28% がタイポの修正やフォーマットの修正や翻訳といったドキュメントに対するものなのです。

また、新しいプロジェクトを見つけてコントリビュートする手助けとして、次のようなリソースのうちの一つを使うこともできます:

コントリビュートする前のチェックリスト

コントリビュートしたいプロジェクトを見つけたら、そのプロジェクトがコントリビュートを受け入れる体制ができているかどうかを確かめるために簡単に調べてみましょう。さもないと、あなたの懸命な努力が全くの無反応で終わってしまうかもしれません。

次に、プロジェクトが新しいコントリビューターにとって良いかどうかを評価する簡単なチェックリストを記載しました。

オープンソースの定義に適っているか

ライセンスがあるか？たいてい、リポジトリのルートにある LICENSE という名前のファイルがそれに当たります。

プロジェクトがコントリビュートを積極的に受け入れているか

master ブランチのコミットアクティビティをみてみましょう。 GitHub ではリポジトリのホームページでこの情報を見ることができます。

最新のコミットはいつか？

そのプロジェクトには何人のコントリビューターがいるか？

どのくらいの頻度でコミットしているか？ ( GitHub では、トップにある "Commits" をクリックすることでこれを見ることができます)

次に、プロジェクトのイシューをみてみましょう。

いくつのイシューがあるか？

メンテナーはイシューがオープンされたらすばやく反応しているか？

イシューでアクティブな議論は行われているか？

イシューは最近のものか？

イシューがクローズされているか？ ( GitHub では、 Issues ページの "closed" タブでクローズされたイシューを見ることができます)

次にプロジェクトのプルリクエストに対して同じことをしましょう。

いくつのプルリクエストがあるか？

メンテナーはプルリクエストがオープンされたらすばやく反応しているか？

プルリクエストでアクティブな議論は行われているか？

プルリクエストは最近のものか？

どのくらい最近プルリクエストがマージされたか？ ( GitHub では、プルリクエストページの "closed" タブをクリックすることでクローズされたプルリクエストを見ることができます)

プロジェクトは歓迎してくれるか

友好的で歓迎してくれるプロジェクトは新しいコントリビューターを受け入れてくれる印です。

メンテナーはイシューでの質問に助けとなるような回答をしているか？

人々はイシューやディスカッションフォーラム、チャット(例えば IRC や Slack )で友好的か)?

プルリクエストはレビューされているか？

メンテナーはコントリビュートに対して感謝しているか？

コントリビュートする方法

あなたは好きなプロジェクトを見つけ、コントリビュートをする準備ができています。ついに！次にあなたのコントリビュートを効果的に行う方法を紹介します。

効果的にコミュニケーションする

あなたが一度きりのコントリビューターであろうとコミュニティに参加しようとしているのであろうと、他の人と働くことはオープンソースで獲得するスキルの中で最も大事なものの一つです。

イシューやプルリクエストをオープンする前に、あなたのアイデアが効果的に扱われる助けのために、これらのことを心にとどめておきましょう。

コンテキストを与えましょう。 他の人がすぐに把握する手助けをしましょう。もしあなたがエラーに遭遇しているのであれば、あなたが何をしようとしていて、どうやって再現させるのかを説明しましょう。もしあなたが新しいアイデアを提案しているのであれば、なぜそれがプロジェクトにとって（あなたにとってだけではなく！）便利だと思うのかを説明しましょう。

😇 “Yを行った時にXが起きません”

😢 “Xが壊れています！直して下さい。”

まずは自分の手を動かしましょう。 何かを知らないのは問題ないのですが、トライしたことは示しましょう。助けを求める前に、プロジェクトの README やドキュメント、イシュー（オープンなものもクローズされたものも）、メーリングリストや答えをインターネットで探したか確認しましょう。人々はあなたが学ぼうとしていることを示せば、それを評価してくれるでしょう。

😇 “私は X を実装するやり方がわかりません。ヘルプドキュメントを見たのですが、それについての言及を見つけることができませんでした。”

😢 “わたしはどうやったら X ができますか？”

要求は短く直接的にしましょう。 メールを送るのと同じように、それぞれのコントリビュートは、それがいくらシンプルで役に立つものであっても、他の誰かのレビューを必要とします。多くのプロジェクトでは、人々が助けられる以上の数の要求が来ています。簡潔にしましょう。そうすれば、誰かが助けてくれるチャンスを増やすことができるでしょう。

😇 ” API チュートリアルを書こうと思っています。”

😢 “私は先日高速道路を走っていて、給油のため止まりました。すると、我々がやるべき素晴らしいアイデアが思い浮かんだのです。しかし、それを説明する前に・・・”

全てのコミュニケーションを公開の場でしましょう。 いくらやりたくなったとしても、機密情報（セキュリティイシューや重大な行動指針違反など）を共有するのでもない限り、メンテナーに非公開に接触するのはやめましょう。会話を公開の場で行い続ければ、あなたの会話からより多くの人が学び、利益を得ることができます。会話することはそれ自体がコントリビュートとなりうるのです。

😇 (コメントで) “@メンテナーこんにちは！このプルリクエストはどうやって進めたら良いですか？”

😢 (メールで) “こんにちは、メールを送ってすみませんが、私のプルリクエストをレビューしていただけないかと思いまして。”

質問をするのは問題ありません（ただし、辛抱強く！） 誰しもがある時点ではそのプロジェクトに慣れていなく、経験のあるコントリビューターでさえ新しいプロジェクトを見るときは最新情報が必要となります。同様に、古くからのメンテナーでさえ常にそのプロジェクトのあらゆる部分に詳しいわけではありません。あなたが彼らに望むような辛抱強さをあなたも彼らに対して示しましょう。

😇 “このエラーについて調べてくれてありがとうございます。あなたの提案に従ってみました。こちらがその出力です。”

😢 “なぜ私の問題を解決できないのでしょう？これはあなたのプロジェクトじゃないんですか？”

コミュニティの決定を尊重しましょう。 あなたのアイデアはコミュニティの優先事項やビジョンとは異なっているかもしれません。彼らはフィードバックを提供したり、あなたのアイデアを採用しないと決定するかもしれません。あなたは議論したり妥協点を見出したりするべきですが、メンテナーはあなたよりも長い期間あなたのアイデアと付き合っていく必要があるのです。もしあなたが彼らの方向性に賛成出来ないのなら、あなたはいつでもあなた自身のフォークやあなた自身のプロジェクトを始めることができるのです。

😇 “あなたが私のユースケースを支持できないのは残念ですが、あなたが説明してくれたようにそれはユーザーのうちの一部にしか影響しませんし、私も理由を理解できます。意見を聞いてくださりありがとうございます。”

😢 “なぜあなたは私のユースケースを支持しないのですか？これは受け入れられません！”

なにより常にポジティブでいましょう。 オープンソースは世界中のコラボレータによって成り立っています。言語や文化、地理、タイムゾーンをまたぐことでコンテキストが失われてしまいます。加えて、テキストコミュニケーションでは調子や雰囲気を伝えるのが難しいです。これらの会話では相手は前向きであると仮定しましょう。丁寧にアイデアを先送りしたり、さらなるコンテキストを聞いたり、あなたのポジションを更に明確にするのは良いことです。インターネットがあなたが見つけたときよりもよりよい場所であるように心がけましょう。

コンテキストを集める

何かをする前に、あなたのアイデアが他の場所で既に議論されていないか確かめましょう。そのプロジェクトの README やイシュー（オープンなものもクローズされたものも）、メーリングリストやスタックオーバーフローにざっと目を通しましょう。全てに目を通すのに何時間もかける必要はありませんが、いくつかのキーワードで検索するので十分です。

もしあなたのアイデアが他で見つけられないのであれば、動き出す準備ができたことになります。そのプロジェクトが GitHub 上にあるのであれば、あなたはおそらくイシューやプルリクエストをオープンすることでコミュニケーションするでしょう。

イシュー は会話や議論を始めるようなものです
プルリクエスト は解決に向けて仕事を始めることです
確認や方法を聞く質問のような、軽いコミュニケーションには 、もしそのプロジェクトが使っているのであれば、スタックオーバーフロー、 IRC 、 Slack や他のチャットで質問してみましょう。

イシューやプルリクエストをオープンする前に、そのプロジェクトのコントリビュートの方法についてのドキュメント（大抵は CONTRIBUTING と呼ばれるファイルや README の中にあります）を確認し、なにか特定の情報を含める必要があるか確かめましょう。例えば、あなたはテンプレートを使ったり、テストを実行する必要があるかもしれません。

もしあなたが大きなコントリビュートをしたいのであれば、その仕事に取り掛かる前にイシューをオープンしましょう。受け入れられないかもしれない仕事に取り掛かる前に、暫くの間そのプロジェクトをウォッチし（ GitHub では、 “Watch” をクリックすることで全ての会話の通知を受け取ることができます)、コミュニティメンバーを知ることは役に立つでしょう。

イシューをオープンする

下記のような状況では大抵イシューをオープンすべきです：

あなただけで解決できないエラーの報告
高レベルなトピックやアイデア（例えば、コミュニティやビジョンや方針）についての議論
新しい機能や他のプロジェクトへのアイデアの提案

イシュー上でのコミュニケーションのコツ：

あなたが取り組みたいオープンイシューを見つけたら、 そのイシュー上であなたがそれに取り掛かる事を人々に知らせるためにコメントしましょう。そうすることで、あなたの仕事と重複する可能性が減ります。
イシューがしばらく前にオープンされたのであれば、 それは他の場所で取り組まれていたり、既に解決されている可能性があります。なので、仕事に取り掛かる前に確認するコメントをしましょう。
もしあなたがイシューをオープンしたのに、あとになって自分で解決策を見つけたのであれば、 そのイシューで人々に知らせるためにコメントしましょう。そして、イシューをクローズしましょう。成果をドキュメントにするだけでもそのプロジェクトに対するコントリビュートとなります。

プルリクエストをオープンする

下記のような状況では大抵プルリクエストをオープンすべきです：

明確な修正（例えばタイポや壊れたリンクや明らかなエラー）の提出
既に要求されているコントリビュートや既にイシュー上で議論された仕事を始める際

プルリクエストでは、仕事が完了している必要はありません。大抵の場合、早い段階でプルリクエストを開き、他の人があなたの進捗を確認したり、フィードバックを与えられるようにしたほうが望ましいです。タイトルに “WIP” (Work in Progress) とつけましょう。いつでもさらなるコミットを追加できます。

そのプロジェクトが GitHub 上にあるのであれば、下記がプルリクエストを提出する方法です：

リポジトリをフォークし ローカルにクローンしましょう。あなたのローカルと元の “upstream” リポジトリを remote として追加することで紐づけましょう。 “upstream” からの変更を頻繁にプルすることで、プルリクエストを提出する時にマージコンフリクトが起きづらくなるように、最新に追いついているようにしましょう。（より詳細な手順はこちらを確認して下さい)。
あなたの変更のためのブランチを切りましょう。
プルリクエストの中であらゆる関連するイシュー や関連するドキュメントを参照しましょう（例えば、 “Closes #37.” のように)。
もしあなたが HTML/CSS を変更するのであれば、前後のスクリーンショットを含めましょう。あなたのプルリクエストの本文に画像をドラッグアンドドロップしましょう。
あなたの変更をテストしましょう！ もし既存のテストがあるのであれば、あなたの変更に対してそのテストを実行したり、必要であれば新しいテストを作りましょう。既存のテストの有無にかかわらず、あなたの変更が既存のプロジェクトを壊さないことを確かめましょう。
できる限りそのプロジェクトのスタイルに従ってコントリビュートしましょう。これによってインデントやセミコロン、コメントがあなた自身のリポジトリの使い方とは異なるかもしれないということを意味します。しかし、メンテナーがマージしやすくしたり、他の人が理解して将来もメンテナンスしやすいようにしましょう。

もしこれがあなたの初めてのプルリクエストであれば、 Make a Pull Request という、 @kentcdodds が作成したビデオチュートリアルを確認しましょう。また、プルリクエストを作る練習を First Contributions という、 @Roshanjossey によって作成されたリポジトリで行うこともできます。

コントリビュートを提出した後に起こること

やりました！おめでとう、あなたはオープンソースコントリビューターになりました。これからも多数のコントリビュートを行う第一歩になることを願っています。

コントリビュートを提出した後、下記のうちのどれかが起きるでしょう：

😭 返事をもらえない

あなたはコントリビュートを行う前に、そのプロジェクトの活動の様子を調べていると思います。しかしながら、アクティブなプロジェクトだったとしても、あなたのコントリビュートに対して返事が無いことがおき得ます。

一週間以上返事がないようであれば、同じスレッドにて、誰かにレビューを丁寧にお願いするのは妥当でしょう。あなたのコントリビュートをレビューするのに適切な人の名前を知っているのであれば、そのスレッドにて@メンションを使うことができます。

その人に非公開の場で接触するのはやめましょう。オープンソースプロジェクトにとって、公開の場でコミュニケーションすることは必要不可欠であるということを思い出しましょう。

もしあなたが丁寧につついてもまだ誰も反応しないのであれば、ずっと誰も反応しない可能性があります。良い気分ではないでしょうが、落胆しないようにしましょう。それは誰に対しても起こることなのです！返事をもらえない理由はたくさんあり、それにはあなたがコントロールできない個人的な状況も含まれます。他のプロジェクトや他のコントリビュートの方法を探しましょう。いずれにしても、他のコミュニティメンバーが携わってくれて反応してくれるようになる前にコントリビュートをするのに大きな時間を投資しないほうが良いのです。

🚧 あなたのコントリビュートに対して変更を要求する人がいる

あなたのコントリビュートに対して変更を要求されるのはよくあることです。その要求はあなたのアイデア自体に対してのフィードバックであることもあれば、コードに対する変更であることもあります。

変更を要求する人が居たら、すぐに返事をしましょう。彼らはあなたのコントリビュートに対して時間をとってレビューしてくれたのです。プルリクエストを開いて居なくなってしまうのは良くないやり方です。もしあなたが変更の仕方を知らないのであれば、その問題を調査し、必要であれば助けを求めましょう。

もしあなたがその問題に対してそれ以上の時間をかけることができない（例えばその会話が何ヶ月にも渡り、あなたの状況が変わったなど）場合は、メンテナーにそれを伝え、返答ができない旨を伝えましょう。他の誰かが喜んで引き継いでくれるはずです。

👎 あなたのコントリビュートが受け入れられない

あなたのコントリビュートは最終的に受け入れられるかもしれないし、受け入れられないかもしれません。既に多大なコストを払っていないとよいのですが。もしなぜ受け入れられないかわからないのであれば、メンテナーにフィードバックや確認をするのは全くもって理にかなっています。しかし、究極的にはそれが彼らの決定であると尊重する必要があるでしょう。異議を唱えたり、敵意を示さないようにしましょう。もし彼らに賛成出来ないのであれば、あなたはいつでもフォークしてあなた自身のプロジェクトを始めることができるのです。

🎉 あなたのコントリビュートが受け入れられた

バンザイ！あなたは無事にオープンソースにコントリビュートできました！

やりました！

初めてのオープンソースへのコントリビュートをしたのであれ、他のコントリビュートの方法を探しているのであれ、あなたがなにか行動を起こそうという気持ちになっていたら嬉しいです。たとえあなたのコントリビュートが受け入れられなかったとしても、メンテナーがあなたを助けるために労力を割いてくれたことに対して感謝を伝えるのを忘れないようにしましょう。オープンソースはあなたのような、イシュー、プルリクエスト、コメントや挨拶をするような、人々で成り立っているのです。