aboutsummaryrefslogtreecommitdiff
path: root/files/ja/mdn/contribute/open_source_etiquette/index.html
blob: 041a12e91e55749e478ae3d4b1b3c45fa75c716e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
---
title: オープンソースプロジェクトのための基本的なエチケット
slug: MDN/Contribute/Open_source_etiquette
tags:
  - Best practices
  - Community
  - Open source
  - MDN
  - Beginners
translation_of: MDN/Contribute/Open_source_etiquette
---
<p>{{MDNSidebar}}</p>

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

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

<h2 id="think_about_why_you_are_contributing_to_an_osp">自分がなぜ OSP に協力するのかを考えましょう</h2>

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

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

<ul>
  <li>このツールをいつも使っていて、バグを見つけた/もっと良くするために協力したい。</li>
  <li>他の人がこのツールをもっとうまく使えるようにしたい。</li>
  <li>他の人がよりうまくプロジェクトに協力できるようにしたい。</li>
  <li>自分自身のスキルを磨きたい。</li>
  <li>大学の授業の一環として、自分のスキルを公にアピールしたい。</li>
  <li>自分のスキルを公にアピールして、仕事の可能性を高めたい。</li>
</ul>

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

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

<ul>
  <li>誰かと会話をしたい。</li>
  <li>人々を釣ったり、命令したりしたい。</li>
  <li>自分がいかにすごいかをアピールしたい。</li>
</ul>

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

<h2 id="be_polite_be_kind_avoid_incendiary_or_offensive_language">礼儀正しく、親切に、煽るような言葉や攻撃的な言葉は避けましょう</h2>

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

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

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

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

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

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

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

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

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

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

<h2 id="choose_impactful_contributions">インパクトのある貢献を選びましょう</h2>

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

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

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

<ul>
  <li>入ってきた問題のトリアージを手伝う。</li>
  <li>誤字の修正を手伝う。</li>
  <li>文法を改善し、より理解しやすいページにする手伝いをする。</li>
  <li>修正を行おうとしている人の相談相手になって手伝う。</li>
</ul>

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

<ul>
  <li>「この書き方の方が好きだから」という理由でコードの書き方を変更すること。</li>
  <li>「その方が好きだから」というだけの理由で、言い回しを更新すること。</li>
  <li>アメリカ英語からイギリス英語にページを書き換えること。</li>
  <li>何の問題もないのに、大量の句読点を付けたり消したりすること。</li>
  <li>私たちが使っているテストフレームワークを、その方が好きだからという理由で別のものに変更する。</li>
</ul>

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

<h2 id="read_the_manual">マニュアルを読みましょう</h2>

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

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

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

<h2 id="find_out_where_to_ask_questions">質問をする場所を探しましょう</h2>

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

<h2 id="make_progress_not_noise">雑音ではなく進歩を</h2>

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

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

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

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

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

<h2 id="osps_are_a_democracy_almost">OSP は (ほぼ) 民主主義である</h2>

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

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

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

<h2 id="be_patient_be_timely">忍耐強く、タイムリーに</h2>

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

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

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

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

<h2 id="see_also">関連情報</h2>

<ul>
  <li><a href="https://opensource.guide/ja/how-to-contribute/">オープンソースにコントリビュートする方法</a></li>
  <li><a href="https://github.com/freeCodeCamp/how-to-contribute-to-open-source">More general freeCodeCamp "How to contribute to open source" list</a></li>
  <li><a href="https://stackoverflow.blog/2020/08/03/getting-started-with-contributing-to-open-source/">Getting started with contributing to open source</a></li>
</ul>