オープンソースのエチケット

オープンソースプロジェクトへの協力を始める前に、なぜやりたいのかを自問してみてください。 この質問に対する答えが「自分の時間を何かに使いたい」であれば問題ありませんが、もっと良い理由としては、以下のようなものがあります。

• 自分自身のスキルを磨きたい。
• このツールをいつも使っていて、バグを見つけた／もっと良くするために協力したい。
• 他の人がこのツールをもっとうまく使えるようにしたい。
• 他の人がよりうまくプロジェクトに協力できるようにしたい。
• 大学のコースで自分自身でスキルを証明したい、または就職のチャンスを広げたい。

中には利己的な理由もありますが、それもいいでしょう。 協力する明確な理由を持つことで、より生産的になり、コミュニティと一緒に作業しやすくなります。

これを「人に優しくする」と略すことができます。 これは、オープンソースへの協力を始めようとする人への、私たちの一番のアドバイスです。 プロジェクトに参加している他の協力者に親切にすることで、より幸せで生産性の高い場所になります。これには次のようなものがあります。

• 人に助けてもらったらお礼を言う。
• 適宜、お祝いの言葉をかける（例えば、初めてのプルリクエストを獲得した場合や、特に難しいバグを修正した場合など）。
• 相手の質問に対する回答がやや当たり前のことであったり、相手が同じことを繰り返していると感じたとしても、常に相手に敬意を持って対応する。
• プルリクエストをレビューしたり相手の質問に答えたりする際に、支援する方法として、相手が次回はもっとうまくできるように助けること。「間違っています」や「これが答えです」というよりも、「これでも構いませんが、このようにしてみるともっとうまく行きますよ。このブログの投稿が詳しいです」や「答えはこちらで見つかります。また、もっと一般的な回答として、こちらのリンクを参照してください」と言った方がはるかに役に立ちます。

協力者は、自分のプロジェクトに正の影響を及ぼしたいと考えてここにいるのです。 それ以外にも、次のような思い込みはしないようにしましょう。

• プロジェクトとそれを構築するために使用される技術に関する知識
• 性別、性的志向、年齢、使用言語、居住地、政治的見解、宗教、などの個人的属性
• オープンソースプロジェクトでの経験
• 信頼性
• 期待
• ユーモアのセンス

書く内容はトピックに関連したものにし、宗教や政治などの論争を呼ぶ可能性のある話題は避けるべきです。 卑猥な言葉や不快な可能性のある表現は控えましょう。 コミュニケーションの改善にはほとんどつながりませんし、他にも参加しにくくなる可能性があります。

たとえ誰かと意見が異なったり、その人の下した決定が気に入らなくても、対応し、敬意を払いましょう。 良い OSP には、協力者が協力中に不快な思いをしないよう、持つルールがあることを認識しましょう。 これはふつう、 GitHub の CODE_OF_CONDUCT.md ファイルにあります（例えば mdn/content CODE_OF_CONDUCT をご覧ください。

例えば、 MDN のリポジトリーは、広範囲に及ぶ Mozilla コミュニティ参加ガイドラインによって管理されています。 通常、MDN のリポジトリーにおける軽度の攻撃的な行動（常にトピックから外れていたり、中断していたり、無礼であったりすること）は、通常、まずリポジトリー上で警告がなされ、次に最終警告、そして一時的または永久的な禁止措置がとられます。 他の協力者に対するヘイトスピーチや脅迫などのより深刻な行動問題は容認されず、おそらく即刻禁止となります。

何か不快になるものを受け取った場合は、行動規範に記載されている方法で報告してください。

プロジェクトで何をしたいのかを考えましょう。例えば、協力者タスクボード（英語）にファイルされた大量の課題リストがあります。 また、 MDN の記事を読んでいて気になった問題を解決するために、プルリクエストを作成して協力することもできます。

MDNで多くの作業は、ドキュメントやコードの例を書くことに集中していますが、他にも協力する方法がいくつかあります。 これは、 issue のトリアージを手伝ったり、誤字脱字を修正したり、文法を直してページをわかりやすくしたり、修正しようとしている人を指導したりすることです。 すべての修正は、どんなに小さくても有益なものであり、私たちはどんな修正も排除しません。 とはいえ、あなたの修正する内容が生産的であるように心がけてください。私たちは、このような種類の貢献をしないように助言したいと思います。

• コードスタイル、文章の言葉遣い、検査フレームワークを、より気に入っているからという理由で更新すること。
• アメリカ英語からイギリス英語にページを書き換えること。
• 元のものに問題がないのに、句読点を付けたり消したりすること。

多くの場合、 OSP では理由があってそのようになっています。スタイルガイドがあればそれを読むべきですし、何か生産的であるかどうか疑問がある場合は、必ず最初に尋ねてみるべきです。

優れた OSP は、常に協力者のドキュメントが容易に入手できるようにしています。 GitHub のプロジェクトでは、通常はリポジトリーの CONTRIBUTING.md ファイル、またはプロジェクトの README.md ファイルに記載されています。文書化プロジェクトである MDN のコンテンツには README があり、サイト自体に協力者向けのドキュメントがきちんと用意されています（コミュニティのリソースを参照）。

助けを求めることを恐れないで、ただし、必ず質問する前に答えを見つけようとしてください。そうすることで、プロジェクトに関する知識を深め、より自立した人間になることができ、他の協力者に不必要な負担をかけることもありません。 もちろん、ドキュメントは常に完璧というわけではありません。もし、何かが見つけにくかったり、説明が不十分であったりするのを見つけた場合は、課題 (issue) を提出したり、プルリクエストを作成したりして、自分で解決してみてください。

質問をするのに最も適した場所を常に探してください。優れた OSP であれば、必ずドキュメントでこの点を明確にしています（お問い合わせを参照）。もし一般的な質問をしたいのであれば、常にこれらのチャンネルを利用してください。質問のたびに GitHub に課題を提出するのはやめましょう。これはプロジェクトにノイズを与えることになります（次の節を参照）。

プロジェクトでのコミュニケーションの取り方をよく考えてください。それが有用であり、他の参加者の仕事を難しくしないようにしてください。バグを修正するためにプルリクエストを提出することは素晴らしいことですが、それは有益で、レビューしやすいものでしょうか。 課題を提出したり、他の会話に参加したりするのは良いことですが、あなたの課題やコメントはトピックに沿っているでしょうか？それとも雑音を追加しているのでしょうか？

ルールとしては、以下のようにしてください。

• 課題 1 つにつき 1 つのトピックを議論しましょう。 — 課題を集中的かつ生産的に進めることができます。
• 1 つの PR につき、1 つの問題を修正するようにしましょう。あなたにとっては多少手間がかかりますが、1 つの明確な修正をレビューするのはずっと簡単です。
• 有益な指摘や他の人の質問に答えられることがあれば、他のスレッドに協力しましょう。
• 役に立つかどうかわからないことや素朴な疑問は、チャットルームやフォーラムなどの他の仕組みを使って質問してみましょう。
• まずはマニュアルを読んで、質問する前に自分で答えを出してみましょう。

以下のようなことはしないでください。

• 一度に複数のトピックを議論しようとしたり、トピックから外れたコメントをしたりして、課題を複雑にすること。
• 複数の修正を 1 つのプルリクエストに詰め込もうとすること。レビューが非常に難しくなりますし、疑念を持たれてしまいます（有効な変更の間に悪意のあるコードを隠そうとしているのではないかと思う人もいるかもしれません）。
• 曖昧な質問でたくさんの課題を開くこと。
• まず自分で解決しようとせずに質問すること。

OSP はとても民主的であり、多くの決定事項は投票で決められます。また、他の人の協力を妨げない限り、どのように協力するかはほぼ自由です。

しかし、中には少数の中心的な協力者のグループによって大きく決定されるものもあります。どのような決定に対しても異議を唱えるのは自由ですが、時にはモデレーターがあなたの意見に反する判断を下すこともあるでしょう。あなたはこれらの決定を尊重し、受け入れる必要があります。

プロジェクトのモデレーターを知っておくと、例えばプルリクエストや課題のスレッドで誰に助けを求めればよいかがわかるので便利です。

OSP に取り組んでいる多くの人々は、無報酬で自分の時間を使って仕事をしており、 OSP に取り組んでいるすべての人々は一般的に非常に忙しいということを覚えておいてください。プルリクエストのレビューや質問への回答などを待っている場合は、気長に待ってください。

数日待ってから、丁寧に声をかけて、見てもらう時間があったかどうかを尋ね、 1 週間後にもう一度フォローして、今は忙しいかどうかを尋ねるのが妥当です。

すばやい返事を求めるようなことは、理にかなっておらず、礼儀正しいことでもありません。

誰かがあなたのために何かをしてくれるのを待っている場合、あなたも同じように礼儀を尽くすべきですが、同時に、できる限り迅速に対応するようにしましょう。どうしても時間が取れない場合は、その旨を伝え、他の人を探してもらえるようにメンテナーに依頼してください。

• オープンソースにコントリビュートする方法
• More general freeCodeCamp "How to contribute to open source" list
• Getting started with contributing to open source
• Google Engineering Practices Documentation on google.github.io/eng-practices