diff options
Diffstat (limited to 'files')
| -rw-r--r-- | files/ja/mdn/contribute/open_source_etiquette/index.html | 166 |
1 files changed, 83 insertions, 83 deletions
diff --git a/files/ja/mdn/contribute/open_source_etiquette/index.html b/files/ja/mdn/contribute/open_source_etiquette/index.html index cb36d39c72..ccd7afc154 100644 --- a/files/ja/mdn/contribute/open_source_etiquette/index.html +++ b/files/ja/mdn/contribute/open_source_etiquette/index.html @@ -1,5 +1,5 @@ --- -title: Basic etiquette for open source projects +title: オープンソースプロジェクトのための基本的なエチケット slug: MDN/Contribute/Open_source_etiquette tags: - Best practices @@ -7,159 +7,159 @@ tags: - Open source - MDN - Beginners - +translation_of: MDN/Contribute/Open_source_etiquette --- <p>{{MDNSidebar}}</p> -<p>If you've not worked on an open source project (OSP) before, it is a good idea to read this article before starting to contribute to MDN (or other open source projects). There are a few best practices to adopt that will help ensure that you and the other project contributors feel valued and safe, and stay productive.</p> +<p>オープンソースプロジェクト (OSP) で作業したことがない方は、 MDN (または他のオープンソースプロジェクト) への協力を始める前に、この記事を読むことをお勧めします。あなたや他のプロジェクトの協力者が大切にされ、安全であると感じ、生産性を維持するために採用すべきベストプラクティスがいくつかあります。</p> -<p>This article won't teach you everything about contributing to open source; the aim here is more to give you some good starting points to think about and learn more about as you get started with open source contributions.</p> +<p>この記事は、オープンソースへの協力についてすべてを教えるものではありません。ここでの目的は、オープンソースへの協力を始める際に考えたり学んだりするのによい出発点を提供することです。</p> -<h2 id="think_about_why_you_are_contributing_to_an_osp">Think about why you are contributing to an OSP</h2> +<h2 id="think_about_why_you_are_contributing_to_an_osp">自分がなぜ OSP に協力するのかを考えましょう</h2> -<p>Before you start contributing to an open source project, ask yourself why you want to do that. It is fine if the answer to this question is just "I'm bored and I want to find something productive to do with my time", but you can probably go deeper than that.</p> +<p>オープンソースプロジェクトへの協力を始める前に、なぜやりたいのかを自問してみてください。この質問に対する答えが、「退屈だから、何か生産的なことを見つけたい」ということだけであっても構いませんが、おそらくもっと深く掘り下げることができるでしょう。</p> -<p>Even better reasons might include:<p> +<p>もっと良い理由としては、以下のようなものがあります。<p> <ul> - <li>I use this tool all the time and found a bug in it/want to help make it better.</li> - <li>I want to help other people use the tool more successfully.</li> - <li>I want to help other people contribute to the project more successfully.</li> - <li>I want to improve my own skills.</li> - <li>I want to publicly demonstrate my own skills as part of my college or university course.</li> - <li>I want to publicly demonstrate my own skills to improve my chances of getting a job.</li> + <li>このツールをいつも使っていて、バグを見つけた／もっと良くするために協力したい。</li> + <li>他の人がこのツールをもっとうまく使えるようにしたい。</li> + <li>他の人がよりうまくプロジェクトに協力できるようにしたい。</li> + <li>自分自身のスキルを磨きたい。</li> + <li>大学の授業の一環として、自分のスキルを公にアピールしたい。</li> + <li>自分のスキルを公にアピールして、仕事の可能性を高めたい。</li> </ul> -<p>Some of these reasons are self-serving, but that's OK too — if you are spending your time working on a project for free, then it is reasonable to expect to get something out of it, and in fact you are far more likely to stick around for longer and contribute more productively to the project. In addition, having a good set of reasons for contributing clear before you start will help make it easier to decide what tasks to start on.</p> +<p>中には利己的な理由もありますが、それもいいでしょう。 — もしあなたが無料でプロジェクトに時間を費やしているのであれば、そこから何かを得られると期待するのは妥当なことですし、実際、あなたはプロジェクトに長く留まり、より生産的な貢献をしてくれる可能性がはるかに高いのです。また、プロジェクトを始める前に、協力する理由を明確にしておけば、どのタスクに着手するかを決めるのも容易になります。</p> -<p>Some not so good reasons to start contributing are:</p> +<p>協力を始めるにあたって、あまり良くない理由もあります。</p> <ul> - <li>I want someone to talk to.</li> - <li>I want some people to troll/boss around.</li> - <li>I want to show off how amazing I am.</li> + <li>誰かと会話をしたい。</li> + <li>人々を釣ったり、命令したりしたい。</li> + <li>自分がいかにすごいかをアピールしたい。</li> </ul> -<p>Your presence on the project should still be productive, and not stop others from being productive.</p> +<p>プロジェクトでのあなたの存在は、生産性を高めるものであるべきであり、他人の生産性を妨げるものであってはなりません。</p> -<h2 id="be_polite_be_kind_avoid_incendiary_or_offensive_language">Be polite, be kind, avoid incendiary or offensive language</h2> +<h2 id="be_polite_be_kind_avoid_incendiary_or_offensive_language">礼儀正しく、親切に、煽るような言葉や攻撃的な言葉は避けましょう</h2> -<p>We could abbreviate this to "be kind". This is our number one bit of advice for anyone starting open source contributions.</p> +<p>これを「親切にする」と略すことができます。これは、オープンソースへの協力を始めようとする人への、私たちの一番のアドバイスです。</p> -<p>Be kind to the other contributors on the project, and it will be a happier and more productive place. This includes:</p> +<p>プロジェクトに参加している他の協力者に親切にすることで、より幸せで生産性の高い場所になります。これには次のようなものがあります。</p> <ul> - <li>Thanking people if they help you.</li> - <li>Congratulating people where appropriate (for example if they land their first ever pull request, or fix a particularly difficult bug).</li> - <li>Always responding respectfully to people, even if you feel like the answer to their question was a bit obvious, or that they are repeating themselves.</li> - <li>Trying to help people to do better next time, in a supportive way, e.g. during pull request reviews or as you answer their questions. Saying "this is wrong" or "here is the answer" is nowhere near as helpful as saying "This is OK, but I feel that this would be better if you tried doing it more like this, here's a blog post for more ideas" or "you can find the answer here; also check out this link for more common answers".</li> + <li>人に助けてもらったらお礼を言う。</li> + <li>適宜、お祝いの言葉をかける (例えば、初めてのプルリクエストを獲得した場合や、特に難しいバグを修正した場合など)。</li> + <li>相手の質問に対する回答がやや当たり前のことであったり、相手が同じことを繰り返していると感じたとしても、常に相手に敬意を持って対応する。</li> + <li>プルリクエストをレビューしたり相手の質問に答えたりする際に、支援する方法として、相手が次回はもっとうまくできるように助けること。「間違っています」や「これが答えです」というよりも、「これでも構いませんが、このようにしてみるともっとうまく行きますよ。このブログの投稿が詳しいです」や「答えはこちらで見つかります。また、もっと一般的な回答として、こちらのリンクを参照してください」と言った方がはるかに役に立ちます。</li> </ul> -<p>You and the other contributors are (or should be) here because they want to make a positive contribution to the project, but beyond that, you can't assume anything about them. This includes their:</p> +<p>あなたや他の協力者は、プロジェクトに積極的に貢献したいと思ってここにいるのですが (あるいはそうあるべきですが)、それ以上に彼らについて何かを期待してはいけません。これには以下のようなものが含まれます。</p> <ul> - <li>Knowledge of the project and the technologies used to build it</li> - <li>Gender, sexuality, age, languages spoken, location, political views, religion, or other personal attributes</li> - <li>Experience with open source projects</li> - <li>Confidence</li> - <li>Expectations</li> - <li>Sense of humor</li> + <li>プロジェクトとそれを構築するために使用される技術に関する知識</li> + <li>性別、性的志向、年齢、使用言語、居住地、政治的見解、宗教、などの個人的属性</li> + <li>オープンソースプロジェクトでの経験</li> + <li>信頼性</li> + <li>期待</li> + <li>ユーモアのセンス</li> </ul> -<p>You should therefore keep what you write on topic as much as possible, staying away from potential controversial off-topic subjects like religion or politics, and being supportive and respectful even if you disagree with someone, or don't like a decision they've made.</p> +<p>そのためには、できるだけテーマに沿った記事を書き、宗教や政治など話題になりそうなテーマ外の話題は避け、たとえ誰かと意見が合わなかったり、その人の決定が気に入らなかったりしても、支持と尊敬の念を持つべきです。</p> -<p>Also, you should refrain from any swearing / offensive language on MDN, even if it is not directed at anyone in particular. It is not needed for participation, and some people are really sensitive to it.</p> +<p>また、 MDN 上での悪口や攻撃的な言葉は、たとえそれが特定の人に向けられたものでなくても、控えるべきです。これは参加するために必要なことではありませんし、中には本当に敏感に反応する人もいます。</p> -<p>Be aware that there are rules in place in any good OSP to protect its contributors against being made to feel uncomfortable while contributing. This usually comes in the form of a CODE_OF_CONDUCT.md file on GitHub.</p> +<p>優れた OSP では、協力者が協力中に不快な思いをしないように保護するためのルールが存在することに注意してください。これは通常、 GitHub 上の CODE_OF_CONDUCT.md ファイルに記載されています。</p> -<p>For example, MDN's repos are governed by the wide-reaching <a href="https://www.mozilla.org/en-US/about/governance/policies/participation/">Mozilla Community Participation Guidelines</a>. Usually mildly offensive behavior on MDN repos (such as constantly being off-topic/disruptive, or being rude) will usually be first responded to by a warning on the repo, followed by a final warning, then a temporary or permanent ban. More serious behavioral problems such as hate speech or threats against another contributor will not be tolerated, and will likely result in an instant ban.</p> +<p>例えば、 MDN のリポジトリは、広範囲に及ぶ <a href="https://www.mozilla.org/ja/about/governance/policies/participation/">Mozilla コミュニティ参加ガイドライン</a>によって管理されています。通常、MDN のリポジトリにおける軽度の攻撃的な行動 (常にトピックから外れていたり、中断していたり、無礼であったりすること) は、通常、まずリポジトリ上で警告がなされ、次に最終警告、そして一時的または永久的な禁止措置がとられます。他の協力者に対するヘイトスピーチや脅迫などのより深刻な行動問題は容認されず、おそらく即刻禁止となります。</p> -<p>If you receive anything that makes you feel uncomfortable, you should always report it using the mechanism provided on the code of conduct.</p> +<p>何か不快になるものを受け取った場合は、行動規範に記載されている方法で報告してください。</p> -<h2 id="choose_impactful_contributions">Choose impactful contributions</h2> +<h2 id="choose_impactful_contributions">インパクトのある貢献を選びましょう</h2> -<p>Think about what you want to do on the project. For example, we have a large list of issues filed at <a href="https://github.com/mdn/content/issues">https://github.com/mdn/content/issues</a>, broken up by various GitHub labels into estimated time to fix, technology categories, and more. Another good label to look for is "good first issue", which is generally given to issues that are quite simple and good for beginners to the project to get started with. We are also soon going to start triaging our issues more extensively, by adding other labels such as priority indicators. Try picking some issues that you think you can manage OK with the time you have available, and ask to be assigned to them.</p> +<p>プロジェクトで何をしたいのかを考えましょう。例えば、 <a href="https://github.com/mdn/content/issues">https://github.com/mdn/content/issues</a> にファイルされた大量の課題リストがあります。これは、GitHub のさまざまなラベルによって、修正までの推定時間や技術カテゴリーなどに分けられています。また、 "good first issue" というラベルもあります。これは、非常にシンプルでプロジェクトの初心者が始めるのに適した課題に付与されます。また、近々、優先度指標などのラベルを追加して、課題のトリアージをより広範囲に行う予定です。自分の時間があればなんとかなりそうな課題を選んで、アサインを依頼してみてはいかがでしょうか。</p> -<p>You could also contribute by opening pull requests to fix problems that you come across while reading MDN articles.</p> +<p>また、 MDN の記事を読んでいて気になった問題を解決するために、プルリクエストを作成して協力することもできます。</p> -<p>A lot of the work on MDN revolves around writing documentation and code examples, but there are other ways to contribute too:</p> +<p>MDN での作業の多くは、ドキュメントやコード例を書くことですが、それ以外にも協力できる方法があります。</p> <ul> - <li>Help to triage issues that come in.</li> - <li>Help fix typos.</li> - <li>Help to improve grammar and make pages more understandable.</li> - <li>Help to mentor people that are trying to make fixes.</li> + <li>入ってきた問題のトリアージを手伝う。</li> + <li>誤字の修正を手伝う。</li> + <li>文法を改善し、より理解しやすいページにする手伝いをする。</li> + <li>修正を行おうとしている人の相談相手になって手伝う。</li> </ul> -<p>Every fix is useful, no matter how small, and we won't turn any fix away. Saying that however, try to make sure your fixes are productive. We'd like to advise against these kinds of contributions:</p> +<p>どんなに小さな修正であっても、すべての修正は有用であり、私たちは修正を拒否することはありません。しかし、あなたの修正が生産的なものであることを確認してください。私たちは、このような投稿には注意したいと思います。</p> <ul> - <li>Updating code styling just because "you like that style better".</li> - <li>Updating language style "just because you like that style better".</li> - <li>Changing pages from US English to British English.</li> - <li>Adding or removing a bunch of punctuation when there's not really anything wrong.</li> - <li>Changing the testing framework we are using for something else because you prefer it.</li> + <li>「この書き方の方が好きだから」という理由でコードの書き方を変更すること。</li> + <li>「その方が好きだから」というだけの理由で、言い回しを更新すること。</li> + <li>アメリカ英語からイギリス英語にページを書き換えること。</li> + <li>何の問題もないのに、大量の句読点を付けたり消したりすること。</li> + <li>私たちが使っているテストフレームワークを、その方が好きだからという理由で別のものに変更する。</li> </ul> -<p>In many cases, things are like they are on OSPs for a reason. You should read their style guides if they have one, and if in doubt about whether something is productive, always ask first!</p> +<p>多くの場合、 OSP では理由があってそのようになっています。スタイルガイドがあればそれを読むべきですし、何か生産的であるかどうか疑問がある場合は、必ず最初に尋ねてみるべきです。</p> -<h2 id="read_the_manual">Read the manual</h2> +<h2 id="read_the_manual">マニュアルを読みましょう</h2> -<p>Good OSPs will always make contributor documentation readily available. On GitHub projects, it is usually in the repo's CONTRIBUTING.md file, or sometimes in the project's README.md file. Being a documentation project, MDN content has a <a href="https://github.com/mdn/content/blob/main/README.md">README</a> and a decent set of contributor docs on the site itself (see <a href="/en-US/docs/MDN/Contribute">Contributing to MDN</a>).</p> +<p>優れた OSP は、常に協力者のドキュメントが容易に入手できるようにしています。 GitHub のプロジェクトでは、通常はリポジトリの CONTRIBUTING.md ファイル、またはプロジェクトの README.md ファイルに記載されています。ドキュメントプロジェクトである MDN のコンテンツには <a href="https://github.com/mdn/content/blob/main/README.md">README</a> があり、サイト自体に協力者向けのドキュメントがきちんと用意されています (<a href="/en-US/docs/MDN/Contribute">MDN への貢献</a>を参照)。</p> -<p>The one ask here is — don't be afraid to ask for help, but ALWAYS try to find the answer to your question first before asking. This way you build up your knowledge of the project and become more independent, and don't put unnecessary burden on the other contributors.</p> +<p>ここで1つお願いしたいのは、「助けを求めることを恐れないで、ただし、必ず質問する前に答えを見つけようとすること」です。そうすることで、プロジェクトに関する知識を深め、より自立した人間になることができ、他の協力者に不必要な負担をかけることもありません。</p> -<p>Of course, the docs won't always be perfect. If you find something that is hard to find or not explained very well, file an issue, or create a pull request to try to fix it yourself.</p> +<p>もちろん、ドキュメントは常に完璧というわけではありません。もし、何かが見つけにくかったり、説明が不十分であったりするのを見つけた場合は、課題を提出するか、プルリクエストを作成して、自分で解決しようとしてください。</p> -<h2 id="find_out_where_to_ask_questions">Find out where to ask questions</h2> +<h2 id="find_out_where_to_ask_questions">質問をする場所を探しましょう</h2> -<p>Always find out where the best place is to ask questions. Good OSPs will always make this clear in their docs (see <a href="/en-US/docs/MDN/Contribute/Getting_started#step_4_ask_for_help">ask for help on MDN</a>). If you want to ask general questions, then always make use of these channels. Don't just file an issue on GitHub for every question, as it adds noise to the project (see "Make progress, not noise" below).</p> +<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">Make progress, not noise</h2> +<h2 id="make_progress_not_noise">雑音ではなく進歩を</h2> -<p>Think carefully about the way you handle communication in the project — make sure it is useful, and that it doesn't make other contributor's jobs harder. Submitting pull requests to fix bugs is great, but are they truly useful, and easy to review? Filing issues and joining in other conversations is fine, but are your issues and comments on topic, or are they just adding noise?</p> +<p>プロジェクトでのコミュニケーションの取り方をよく考えてください。それが有用であり、他の参加者の仕事を難しくしないようにしてください。バグを修正するためにプルリクエストを提出することは素晴らしいことですが、それは本当に有益で、レビューしやすいものでしょうか？課題を提出したり、他の会話に参加したりするのは良いことですが、あなたの課題やコメントはトピックに沿っているでしょうか？</p> -<p>As a rule, do:</p> +<p>ルールとしては、以下のようにしてください。</p> <ul> - <li>Discuss one topic per issue — it is easy to keep issues focused and productive.</li> - <li>Fix one issue per PR — it my be slightly more work for you, but it is much easier to review a single clear fix.</li> - <li>Contribute to other threads if you have a useful point to make or can answer some else's question.</li> - <li>Ask questions using other mechanisms like chat rooms or forums if you are not sure whether something is useful or have a simple question.</li> - <li>Read the manual first to try to answer the question yourself before asking it.</li> + <li>一つの課題で一つのトピックを議論しましょう。 — 課題を集中的かつ生産的に進めることができます。</li> + <li>一つの PR につき、一つの問題を修正するようにしましょう。あなたにとっては多少手間がかかりますが、一つの明確な修正をレビューするのはずっと簡単です。</li> + <li>有益な指摘や他の人の質問に答えられることがあれば、他のスレッドに貢献しましょう。</li> + <li>役に立つかどうかわからないことや素朴な疑問は、チャットルームやフォーラムなどの他の仕組みを使って質問してみましょう。</li> + <li>まずはマニュアルを読んで、質問する前に自分で答えを出してみましょう。</li> </ul> -<p>Don't:</p> +<p>以下のようなことはしないでください。</p> <ul> - <li>Complicate issues by trying to discuss multiple topics at once, or making off-topic comments.</li> - <li>Try to cram multiple fixes into a single pull request. It makes it a lot harder to review, and raises suspicions (some people might think you are trying to hide some malicious code in between the valid changes).</li> - <li>Open lots of issues asking vague questions.</li> - <li>Ask questions without trying to solve the problem yourself first.</li> + <li>一度に複数のトピックを議論しようとしたり、トピックから外れたコメントをしたりして、問題を複雑にすること。</li> + <li>複数の修正を1つのプルリクエストに詰め込もうとすること。レビューが非常に難しくなりますし、疑念を持たれてしまいます (有効な変更の間に悪意のあるコードを隠そうとしているのではないかと思う人もいるかもしれません)。</li> + <li>曖昧な質問でたくさんの問題を開く。</li> + <li>まず自分で解決しようとせずに質問する。</li> </ul> -<h2 id="osps_are_a_democracy_almost">OSPs are a democracy (almost)</h2> +<h2 id="osps_are_a_democracy_almost">OSP は (ほぼ) 民主主義である</h2> -<p>OSPs are quite democratic — many decisions are voted on, and you are largely free to contribute how you want, as long as you don't impede anyone else from contributing.</p> +<p>OSP はとても民主的であり、多くの決定事項は投票で決められます。また、他の人の協力を妨げない限り、どのように協力するかはほぼ自由です。</p> -<p>However, some things will be largely decided by a small group of core contributors. You are free to make a case against any decision, but sometimes a moderator will make a call that goes against your opinion. You need to respect and accept these decisions.</p> +<p>しかし、中には少数の中心的な協力者のグループによって大きく決定されるものもあります。どのような決定に対しても異議を唱えるのは自由ですが、時にはモデレーターがあなたの意見に反する判断を下すこともあるでしょう。あなたはこれらの決定を尊重し、受け入れる必要があります。</p> -<p>It is useful to get to know any project's moderators, so you know who best to ask for help, for example in pull request or issue threads.</p> +<p>プロジェクトのモデレーターを知っておくと、例えばプルリクエストや課題のスレッドで誰に助けを求めればよいかがわかるので便利です。</p> -<h2 id="be_patient_be_timely">Be patient, be timely</h2> +<h2 id="be_patient_be_timely">忍耐強く、タイムリーに</h2> -<p>Bear in mind that many people working on OSPs are doing it in their own time, without payment, and all people working on OSPs are generally very busy. If you are waiting for something like a pull request review, or an answer to a question, be patient.</p> +<p>OSP に取り組んでいる多くの人々は、無報酬で自分の時間を使って仕事をしており、 OSP に取り組んでいるすべての人々は一般的に非常に忙しいということを覚えておいてください。プルリクエストのレビューや質問への回答などを待っている場合は、気長にお待ちください。</p> -<p>It is reasonable to wait a few days and then ping someone politely to ask if they've had time to look at it, and maybe follow up again after a week has passed to ask if they are too busy right now.</p> +<p>数日待ってから、丁寧に声をかけて、見てもらう時間があったかどうかを尋ね、 1 週間後にもう一度フォローして、今は忙しいかどうかを尋ねるのが妥当です。</p> -<p>It is NOT reasonable to start demanding things, like you are owed a quick reply. You are not.</p> +<p>すぐに返事をしなければならないというような要求を始めるのは妥当ではありません。あなたはそうではありません。</p> -<p>If someone is waiting for you to do something for them, you should be extended the same courtesy, but at the same time, try to respond as promptly as you can. If you really can't find the time, let them know, and ask the maintainers to help you find someone else to do the task.</p> +<p>誰かがあなたのために何かをしてくれるのを待っている場合、あなたも同じように礼儀を尽くすべきですが、同時に、できる限り迅速に対応するようにしましょう。どうしても時間が取れない場合は、その旨を伝え、他の人を探してもらえるようにメンテナーに依頼してください。</p> -<h2 id="see_also">See also</h2> +<h2 id="see_also">関連情報</h2> <ul> - <li><a href="https://opensource.guide/how-to-contribute/">How to Contribute to Open Source</a></li> + <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> |