From e2778e83b16d10215afc0e187841135545e1227e Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Sat, 20 Mar 2021 02:02:51 +0900 Subject: MDN/Contribute/Open_source_etiquette の新規翻訳 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 新規翻訳しました。 --- .../contribute/open_source_etiquette/index.html | 166 ++++++++++----------- 1 file changed, 83 insertions(+), 83 deletions(-) (limited to 'files/ja/mdn') 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 ---

{{MDNSidebar}}

-

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.

+

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

-

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.

+

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

-

Think about why you are contributing to an OSP

+

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

-

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.

+

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

-

Even better reasons might include:

+

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

-

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.

+

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

-

Some not so good reasons to start contributing are:

+

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

-

Your presence on the project should still be productive, and not stop others from being productive.

+

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

-

Be polite, be kind, avoid incendiary or offensive language

+

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

-

We could abbreviate this to "be kind". This is our number one bit of advice for anyone starting open source contributions.

+

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

-

Be kind to the other contributors on the project, and it will be a happier and more productive place. This includes:

+

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

-

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:

+

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

-

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.

+

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

-

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.

+

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

-

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.

+

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

-

For example, MDN's repos are governed by the wide-reaching Mozilla Community Participation Guidelines. 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.

+

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

-

If you receive anything that makes you feel uncomfortable, you should always report it using the mechanism provided on the code of conduct.

+

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

-

Choose impactful contributions

+

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

-

Think about what you want to do on the project. For example, we have a large list of issues filed at https://github.com/mdn/content/issues, 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.

+

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

-

You could also contribute by opening pull requests to fix problems that you come across while reading MDN articles.

+

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

-

A lot of the work on MDN revolves around writing documentation and code examples, but there are other ways to contribute too:

+

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

-

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:

+

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

-

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!

+

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

-

Read the manual

+

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

-

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 README and a decent set of contributor docs on the site itself (see Contributing to MDN).

+

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

-

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.

+

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

-

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.

+

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

-

Find out where to ask questions

+

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

-

Always find out where the best place is to ask questions. Good OSPs will always make this clear in their docs (see ask for help on MDN). 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).

+

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

-

Make progress, not noise

+

雑音ではなく進歩を

-

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?

+

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

-

As a rule, do:

+

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

-

Don't:

+

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

-

OSPs are a democracy (almost)

+

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

-

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.

+

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

-

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.

+

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

-

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.

+

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

-

Be patient, be timely

+

忍耐強く、タイムリーに

-

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.

+

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

-

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.

+

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

-

It is NOT reasonable to start demanding things, like you are owed a quick reply. You are not.

+

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

-

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.

+

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

-

See also

+

関連情報

-- cgit v1.2.3-54-g00ecf