--- title: オープンソースプロジェクトのための基本的なエチケット slug: MDN/Contribute/Open_source_etiquette tags: - Best practices - Community - Open source - MDN - Beginners translation_of: MDN/Contribute/Open_source_etiquette ---

{{MDNSidebar}}

オープンソースプロジェクト (OSP) で作業したことがない方は、 MDN (または他のオープンソースプロジェクト) への協力を始める前に、この記事を読むことをお勧めします。あなたや他のプロジェクトの協力者が大切にされ、安全であると感じ、生産性を維持するために採用すべきベストプラクティスがいくつかあります。

この記事は、オープンソースへの協力についてすべてを教えるものではありません。ここでの目的は、オープンソースへの協力を始める際に考えたり学んだりするのによい出発点を提供することです。

自分がなぜ OSP に協力するのかを考えましょう

オープンソースプロジェクトへの協力を始める前に、なぜやりたいのかを自問してみてください。この質問に対する答えが、「退屈だから、何か生産的なことを見つけたい」ということだけであっても構いませんが、おそらくもっと深く掘り下げることができるでしょう。

もっと良い理由としては、以下のようなものがあります。

中には利己的な理由もありますが、それもいいでしょう。 — もしあなたが無料でプロジェクトに時間を費やしているのであれば、そこから何かを得られると期待するのは妥当なことですし、実際、あなたはプロジェクトに長く留まり、より生産的な貢献をしてくれる可能性がはるかに高いのです。また、プロジェクトを始める前に、協力する理由を明確にしておけば、どのタスクに着手するかを決めるのも容易になります。

協力を始めるにあたって、あまり良くない理由もあります。

プロジェクトでのあなたの存在は、生産性を高めるものであるべきであり、他人の生産性を妨げるものであってはなりません。

礼儀正しく、親切に、煽るような言葉や攻撃的な言葉は避けましょう

これを「親切にする」と略すことができます。これは、オープンソースへの協力を始めようとする人への、私たちの一番のアドバイスです。

プロジェクトに参加している他の協力者に親切にすることで、より幸せで生産性の高い場所になります。これには次のようなものがあります。

あなたや他の協力者は、プロジェクトに積極的に貢献したいと思ってここにいるのですが (あるいはそうあるべきですが)、それ以上に彼らについて何かを期待してはいけません。これには以下のようなものが含まれます。

そのためには、できるだけテーマに沿った記事を書き、宗教や政治など話題になりそうなテーマ外の話題は避け、たとえ誰かと意見が合わなかったり、その人の決定が気に入らなかったりしても、支持と尊敬の念を持つべきです。

また、 MDN 上での悪口や攻撃的な言葉は、たとえそれが特定の人に向けられたものでなくても、控えるべきです。これは参加するために必要なことではありませんし、中には本当に敏感に反応する人もいます。

優れた OSP では、協力者が協力中に不快な思いをしないように保護するためのルールが存在することに注意してください。これは通常、 GitHub 上の CODE_OF_CONDUCT.md ファイルに記載されています。

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

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

インパクトのある貢献を選びましょう

プロジェクトで何をしたいのかを考えましょう。例えば、 https://github.com/mdn/content/issues にファイルされた大量の課題リストがあります。これは、GitHub のさまざまなラベルによって、修正までの推定時間や技術カテゴリーなどに分けられています。また、 "good first issue" というラベルもあります。これは、非常にシンプルでプロジェクトの初心者が始めるのに適した課題に付与されます。また、近々、優先度指標などのラベルを追加して、課題のトリアージをより広範囲に行う予定です。自分の時間があればなんとかなりそうな課題を選んで、アサインを依頼してみてはいかがでしょうか。

また、 MDN の記事を読んでいて気になった問題を解決するために、プルリクエストを作成して協力することもできます。

MDN での作業の多くは、ドキュメントやコード例を書くことですが、それ以外にも協力できる方法があります。

どんなに小さな修正であっても、すべての修正は有用であり、私たちは修正を拒否することはありません。しかし、あなたの修正が生産的なものであることを確認してください。私たちは、このような投稿には注意したいと思います。

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

マニュアルを読みましょう

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

ここで1つお願いしたいのは、「助けを求めることを恐れないで、ただし、必ず質問する前に答えを見つけようとすること」です。そうすることで、プロジェクトに関する知識を深め、より自立した人間になることができ、他の協力者に不必要な負担をかけることもありません。

もちろん、ドキュメントは常に完璧というわけではありません。もし、何かが見つけにくかったり、説明が不十分であったりするのを見つけた場合は、課題を提出するか、プルリクエストを作成して、自分で解決しようとしてください。

質問をする場所を探しましょう

質問をするのに最も適した場所を常に見つけてください。優れた OSP であれば、必ずドキュメントでこの点を明確にしています (MDN の助けを求めるを参照)。もし一般的な質問をしたいのであれば、常にこれらのチャンネルを利用してください。質問のたびに GitHub に課題を提出するのはやめましょう。これはプロジェクトにノイズを与えることになります (下記の「雑音ではなく進歩を」を参照)。

雑音ではなく進歩を

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

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

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

OSP は (ほぼ) 民主主義である

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

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

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

忍耐強く、タイムリーに

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

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

すぐに返事をしなければならないというような要求を始めるのは妥当ではありません。あなたはそうではありません。

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

関連情報