Respectful Review Comments

Reviewing issues and pull requests is a great way to get started with contributing to the Symfony community. Anyone can do it! But before you give a comment, take a step back and think, is what you are about to say actually what you intend?

イシューとプルリクエストのレビューは、Symfony コミュニティへの貢献を始めるための優れた方法です。誰でもできます!しかし、コメントをする前に、一歩下がって考えてみてください。

Communicating over the Internet with nothing but text can pose a big challenge, especially if you remember that the Symfony community is world-wide and is composed of a wide variety of people with differing ideas and opinions.

特に、Symfony コミュニティが世界中に広がり、さまざまな考えや意見を持つ多種多様な人々で構成されていることを覚えている場合は、テキストだけでインターネットを介して通信することは大きな課題となる可能性があります。

Not everyone speaks English or is able to use a keyboard. Some might have dyslexia or similar conditions that affect their writing.

誰もが英語を話したり、キーボードを使用できるわけではありません。一部の人は、失読症またはライティングに影響する同様の状態を持っている可能性があります。

Not to mention that some might have a bad experience from previous contributions (to other projects).

言うまでもなく、以前の貢献 (他のプロジェクトへの貢献) から悪い経験をした人もいるかもしれません。

You're not alone in this. This guide will try to help you write constructive, respectful and helpful reviews and replies.

これはあなただけではありません。このガイドは、建設的で、礼儀正しく、役立つレビューや返信を書くのに役立ちます。

Tip

ヒント

This guide is not about lecturing you to "conform" or give-up your ideas and opinions but helping you to better communicate, prevent possible confusion, and keeping the Symfony community a welcoming place for everyone. You are free to disagree with someone's opinions, but don't be disrespectful.

このガイドは、あなたのアイデアや意見を「受け入れる」または放棄するように説教するものではありませんが、コミュニケーションを改善し、混乱の可能性を防ぎ、Symfony コミュニティを誰にとっても居心地の良い場所に保つのに役立ちます。誰かの意見に反対するのは自由ですが、無礼にならないようにしてください。

It’s important to accept that many programming decisions are opinions. Discuss trade-offs, which you prefer, and reach a resolution quickly. It's not about being right or wrong, but using what works.

プログラミングに関する決定の多くは意見に基づくものであることを受け入れることが重要です。トレードオフについて話し合い、どちらが望ましいかを検討し、迅速に解決策にたどり着いてください。正しいか間違っているかではなく、機能するものを使用することが重要です。

Tone of Voice

We don't expect you to be completely formal, or to even write error-free English. Just remember this: don't swear, and be respectful to others.

私たちは、あなたが完全に形式的であること、またはエラーのない英語を書くことさえ期待していません.これを覚えておいてください：悪口を言わず、他人を尊重してください。

Don't reply in anger or with an aggressive tone. If you're angry, we understand that, but swearing/cursing and name calling doesn't really encourage anyone to help you. Take a deep breath, count to 10 and try to clearly explain what problems you encounter.

怒ったり、攻撃的な口調で返信しないでください。あなたが怒っているなら、私たちはそれを理解していますが、ののしり/ののしりや名前の呼びかけは、誰かがあなたを助けることを実際に奨励するものではありません.深呼吸をして、10まで数えて、あなたが遭遇した問題を明確に説明してみてください。

Inclusive Language

In an effort to be inclusive to a wide group of people, it's recommended to use personal pronouns that don't suggest a particular gender. Unless someone has stated their pronouns, use "they", "them" instead of "he", "she", "his", "hers", "his/hers", "he/she", etc.

幅広い人々を包括するために、特定の性別を示唆しない人称代名詞を使用することをお勧めします。誰かが代名詞を述べていない限り、"he"、"she"、"his"、"hers"、"his/hers"、"he/she" などの代わりに、"they"、"them" を使用します。

Try to avoid using wording that may be considered excluding, needlessly gendered (e.g. words that have a male or female base), racially motivated or singles out a particular group in society. For example, it's recommended to use words like "folks", "team", "everyone" instead of "guys", "ladies", "yanks", etc.

除外、不必要な性別 (例: 男性または女性ベースの単語)、人種的動機、または社会の特定のグループの単一化と見なされる可能性のある表現を使用しないようにしてください。たとえば、「男」、「女性」、「ヤンク」などの代わりに、「人々」、「チーム」、「全員」などの単語を使用することをお勧めします。

Giving Positive Feedback

While reviewing issues and pull requests you may run into some suggestions (including patches) that don't reflect your ideas, are not good, or downright wrong.

イシューやプル リクエストをレビューしているときに、あなたのアイデアを反映していない、良くない、または完全に間違っている提案 (パッチを含む) に出くわすことがあります。

Now, when you prepare your comment, consider the amount of work and time the author has spent on their idea and how your response would make them feel.

コメントを準備するときは、作成者がアイデアに費やした労力と時間、およびあなたの回答がどのように感じるかを考慮してください。

Did you correctly understand their intention? Or are you making assumptions? Whatever your response, be explicit. Remember people don't always understand your intentions online.

彼らの意図を正しく理解できましたか？それとも仮定を置いていますか?あなたの回答が何であれ、明確にしてください。オンラインであなたの意図が常に人々に理解されるとは限らないことを忘れないでください。

Avoid using terms that could be seen as referring to personal traits ("dumb", "stupid"). Assume everyone is intelligent and well-meaning.

個人の特徴を指すと見なされる可能性のある用語 (「ばか」、「ばか」) は使用しないでください。誰もが知的で善意があると仮定してください。

Tip

ヒント

Good questions avoid judgment and avoid assumptions about the author's perspective.

良い質問は、判断を回避し、著者の視点に関する仮定を回避します。

Maybe you can ask for clarification? Suggest an alternative? Or provide a simple explanation why you disagree with their proposal.

多分あなたは説明を求めることができますか？代替案を提案しますか?または、彼らの提案に反対する理由を簡単に説明してください。
  • This looks wrong. Are you sure it's correct? (e.g. typo/syntax error)
    これは間違っているようです。それは正しいですか？ (例: タイプミス/構文エラー)
  • What do you think of "RequestFactory" instead of RequestCreator?
    RequestCreator の代わりに "RequestFactory" をどう思いますか?

Even if something is really wrong or "a bad idea", stay respectful and don't get into endless you-are-wrong discussions or "flame wars".

何かが本当に間違っている、または「悪い考え」である場合でも、敬意を払い、終わりのない議論や「炎上戦争」に巻き込まれないようにしてください。

Don't use hyperbole ("always", "never", "endlessly", "nothing", "worst", "horrible", "terrible").

誇張を使用しないでください (「常に」、「決して」、「際限なく」、「何もない」、「最悪」、「恐ろしい」、「ひどい」)。

Don't: "I don't like how you wrote this code" - there is no clear explanation why you don't like how it's written.

してはいけないこと: 「このコードの書き方が気に入らない」 - 書き方が気に入らない理由が明確に説明されていません。

Better: "I find it hard to read this code as there are many nested if statements, can you make it more readable? By encapsulating some of the details or maybe adding some comments to explain the overall logic." - You explain why you find the code hard to read and give some suggestions for improvement.

ベター: 「ネストされた if ステートメントがたくさんあるので、このコードを読むのは難しいと思います。もっと読みやすくすることはできますか?詳細の一部をカプセル化するか、全体的なロジックを説明するコメントを追加してください。」 - コードが読みにくいと感じる理由を説明し、改善のための提案をしてください。

If a piece of code is in fact wrong, explain why:

コードの一部が実際に間違っている場合は、その理由を説明してください。
  • "This code doesn't comply with Symfony's CS rules. Please see [...] for details."
    「このコードは Symfony の CS ルールに準拠していません。詳細については [...] を参照してください。」
  • "Symfony 3 still uses PHP 5 and doesn't allow the usage of scalar type-hints."
    「Symfony 3 はまだ PHP 5 を使用しており、スカラー型ヒントの使用を許可していません。」
  • "I think the code is less readable now." - careful here, be sure explain why you think the code is less readable, and maybe give some suggestions?
    「今はコードが読みにくくなっていると思います。」 - ここで注意してください。コードが読みにくいと思う理由を説明してください。また、何か提案をしてください。

Examples of valid reasons to reject:

拒否する正当な理由の例:
  • "We tried that in the past (link to the relevant PR) but we needed to revert it for XXX reason."
    「過去にそれを試みましたが (関連する PR へのリンク)、XXX の理由で元に戻す必要がありました。」
  • "That change would introduce too many merge conflicts when merging up Symfony branches. In the past we've always rejected changes like this."
    「その変更は、Symfony のブランチをマージする際に、あまりにも多くのマージ競合を引き起こします。これまで、私たちはこのような変更を常に拒否してきました。」
  • "I profiled this change and it hurts performance significantly" - if you don't profile, it's an opinion, so we can ignore
    「この変更をプロファイリングしましたが、パフォーマンスが大幅に低下しました」 - プロファイリングしない場合、これは意見であるため、無視できます
  • "Code doesn't match Symfony's CS rules (e.g. use [] instead of array())"
    「コードが Symfony の CS ルールと一致しません (たとえば、array() の代わりに [] を使用)」
  • "We only provide integration with very popular projects (e.g. we integrate Bootstrap but not your own CSS framework)"
    「非常に人気のあるプロジェクトとの統合のみを提供します (たとえば、Bootstrap は統合しますが、独自の CSS フレームワークは統合しません)」
  • "This would require adding lots of code and making lots of changes for a feature that doesn't look so important. That could hurt maintenance in the future."
    「これには多くのコードを追加し、それほど重要ではないように見える機能に多くの変更を加える必要があります。将来のメンテナンスに悪影響を与える可能性があります。」

Asking for Changes

Rarely something is perfect from the start, while the code itself is good. It may not be optimal or conform to the Symfony coding style.

コード自体は優れていても、最初から完璧なものはめったにありません。最適ではないか、Symfony のコーディング スタイルに準拠していない可能性があります。

Again, understand the author already spent time on the issue and asking for (small) changes may be misinterpreted or seen as a personal attack.

繰り返しになりますが、作成者はすでにこの問題に時間を費やしており、(小さな) 変更を求めることは誤解されたり、個人攻撃と見なされる可能性があることを理解してください。

Be thankful for their work (so far), stay positive and really help them to make the contribution a great one. Especially if they are a first time contributor.

（これまでのところ）彼らの仕事に感謝し、前向きであり続け、彼らが貢献を素晴らしいものにするのを本当に助けてください.特に彼らが初めての貢献者である場合。

Use words like "Please", "Thank you" and "Could you" instead of making demands;

要求する代わりに、「お願いします」、「ありがとう」、「できますか」などの言葉を使用します。
  • "Thank you for your work so far. I left some suggestions for improvement to make the code more readable."
    「これまでの作業に感謝します。コードをより読みやすくするための改善点をいくつか残しました。」
  • "Your code contains some coding-style problems, can you fix these before we merge? Thank you"
    「あなたのコードにはコーディングスタイルの問題がいくつか含まれています。マージする前にこれらを修正できますか? ありがとうございます」
  • "Please use 4 spaces instead of tabs", "This needs be on the previous line";
    "タブの代わりに 4 つのスペースを使用してください", "これは前の行にある必要があります";

During a pull request review you can usually leave more than one comment, you don't have to use "Please" all the time. But it wouldn't hurt.

プル リクエストのレビュー中は、通常、複数のコメントを残すことができます。常に「Please」を使用する必要はありません。しかし、それは害はありません。

It may not seem like much, but saying "Thank you" does make others feel more welcome.

大したことではないように思えるかもしれませんが、「ありがとう」と言うと、他の人はより歓迎されていると感じます。

Preventing Escalations

Sometimes when people receive feedback they may get defensive. In that case, it is better to try to approach the discussion in a different way, to not escalate further.

フィードバックを受け取ったときに防御的になることもあります。その場合は、それ以上エスカレートしないように、別の方法で議論にアプローチすることをお勧めします。

If you want someone to mediate, please join the #contribs channel on Symfony Slack, to have a safe environment and keep working together on common goals.

誰かに仲介してもらいたい場合は、Symfony Slack の #contribs チャンネルに参加して、安全な環境を作り、共通の目標に向かって協力し続けてください。

Using Humor

In short: Extreme misbehavior will not be tolerated and may even get you banned; Keep it real and friendly.

要するに、極端な不正行為は容認されず、禁止されることさえあります。現実的かつ友好的に保ちます.

Don't use sarcasm for a serious topic, that's not something that belongs to the Symfony community. And don't marginalize someone's problems; Well I guess that's not supposed to happen? 😆.

皮肉を深刻な話題に使用しないでください。それは Symfony コミュニティに属するものではありません。そして誰かの問題を過小評価しないでください;まあ、それは起こるべきではないと思いますか? 😆。

Even if someone's explanation is "inviting to joke about it", it's a real problem to them. Making jokes about this doesn't help with solving their problem and only makes them feel stupid. Instead, try to discover the actual problem.

誰かの説明が「それについて冗談を言うように誘う」ものであったとしても、それは彼らにとって現実的な問題です.これについて冗談を言っても、彼らの問題を解決する助けにはなりません。代わりに、実際の問題を発見してみてください。

Final Words

Don't feel bad if you "failed" to follow these tips. As long as your intentions were good and you didn't really offend or insult anyone; you can explain you misunderstood, you didn't mean to marginalize or simply failed.

これらのヒントに従わなかったとしても、気にしないでください。あなたの意図が善良であり、実際に誰かを怒らせたり侮辱したりしていない限り、あなたは誤解を説明することができます。

But don't say it "just because", if your apology is not really meant you will lose credibility and respect from other developers.

しかし、「ただの理由で」とは言わないでください。謝罪が本当に意図されていない場合、他の開発者からの信頼と尊敬を失うことになります。

Do unto others as you would have them do unto you.

あなたが彼らにあなたにしてもらいたいと思うように、他の人にもしてください。