尊重他人的评审意见
评审 issue 和 pull request 是开始为 Symfony 社区做贡献的好方法。任何人都可以做到！但是在您给出评论之前，请退后一步思考一下，您将要说的实际上是您想要表达的吗？
仅通过文本在互联网上进行交流可能是一个很大的挑战，尤其当您记住 Symfony 社区是世界性的，并且由各种具有不同想法和意见的人组成时。
并非所有人都会说英语或能够使用键盘。有些人可能有阅读障碍或类似的状况，影响他们的写作。
更不用说有些人可能在之前的贡献（对其他项目）中有过不好的经历。
您并不孤单。本指南将尝试帮助您撰写建设性的、尊重他人且有帮助的评审和回复。
提示
本指南不是在教训您“遵守”或放弃您的想法和意见，而是帮助您更好地沟通，防止可能的混淆，并保持 Symfony 社区对所有人都是一个欢迎的地方。您可以不同意他人的意见，但请不要不尊重他人。
重要的是要接受许多编程决策都是个人意见。讨论权衡，您更喜欢哪一个，并快速达成决议。这与对错无关，而是使用有效的方法。
语气
我们不期望您完全正式，甚至不期望您写出没有错误的英语。只需记住这一点：不要说脏话，尊重他人。
不要在愤怒或带有攻击性的语气中回复。如果您生气了，我们理解，但说脏话/诅咒和人身攻击并不能真正鼓励任何人帮助您。深吸一口气，数到 10，然后尝试清楚地解释您遇到的问题。
包容性语言
为了包容更广泛的人群，建议使用不暗示特定性别的代词。除非有人声明了他们的代词，否则请使用“他们”、“她们”、“它们”而不是“他”、“她”、“他的”、“她的”、“他/她的”、“他/她”等。
尽量避免使用可能被认为具有排斥性、不必要地带有性别色彩（例如，以男性或女性为基础的词语）、种族动机或单独挑出社会特定群体的措辞。例如，建议使用“大家”、“团队”、“所有人”等词语，而不是“伙计们”、“女士们”、“美国佬”等。
给予积极反馈
在评审 issue 和 pull request 时，您可能会遇到一些建议（包括补丁），这些建议不反映您的想法，不好，或者完全错误。
现在，当您准备评论时，请考虑作者在其想法上花费的工作量和时间，以及您的回复会让他们有何感受。
您是否正确理解了他们的意图？或者您是否在做假设？无论您的回复是什么，都要明确。记住人们并不总是能在线理解您的意图。
避免使用可能被视为指涉个人特质的术语（“笨”、“蠢”）。假设每个人都是聪明且善意的。
提示
好的问题避免评判，并避免对作者的观点进行假设。
也许您可以要求澄清？提出替代方案？或者提供一个简单的解释，说明您为何不同意他们的建议。
这看起来是错的。你确定它是正确的吗？(例如，拼写错误/语法错误)您觉得用 "RequestFactory" 代替 RequestCreator 怎么样？
即使某件事确实是错的或“一个坏主意”，也要保持尊重，不要陷入无休止的“你错了”的讨论或“口水战”。
不要使用夸张的说法（“总是”、“从不”、“无休止地”、“什么都没有”、“最差”、“可怕”、“糟糕”）。
不要： “我不喜欢你写这段代码的方式” - 没有明确解释您为何不喜欢它的写法。
更好： “我发现这段代码难以阅读，因为它有很多嵌套的 if 语句，您能让它更易读吗？通过封装一些细节，或者也许添加一些注释来解释整体逻辑。” - 您解释了为何您觉得代码难以阅读，并给出了一些改进建议。
如果一段代码实际上是错误的，请解释原因
- “这段代码不符合 Symfony 的 CS 规则。请参阅 [...] 了解详情。”
- “Symfony 3 仍然使用 PHP 5，并且不允许使用标量类型提示。”
- “我认为现在的代码可读性变差了。” - 这里要小心，务必解释清楚您为何认为代码可读性变差，并且也许可以给出一些建议？
拒绝的有效理由示例
- “我们过去尝试过这样做（链接到相关的 PR），但由于 XXX 原因，我们需要回退它。”
- “这个更改会在合并 Symfony 分支时引入太多的合并冲突。过去我们总是拒绝像这样的更改。”
- “我分析了这个更改，它会显著降低性能” - 如果您不进行性能分析，这只是个人意见，因此我们可以忽略
- “代码不符合 Symfony 的 CS 规则（例如，使用
[]而不是array()）” - “我们只与非常流行的项目集成（例如，我们集成了 Bootstrap，但没有集成您自己的 CSS 框架）”
- “这将需要添加大量代码并进行大量更改，才能实现一个看起来不太重要的功能。这可能会损害未来的维护。”
要求修改
很少有东西从一开始就是完美的，即使代码本身很好。它可能不是最优的，或者不符合 Symfony 的编码风格。
再次强调，理解作者已经在这个 issue 上花费了时间，要求（小的）更改可能会被误解或视为人身攻击。
感谢他们（到目前为止）的工作，保持积极态度，并真正帮助他们使贡献变得出色。尤其是当他们是首次贡献者时。
使用“请”、“谢谢”和“您能”之类的词语，而不是提出要求；
- “感谢您到目前为止的工作。我留下了一些改进建议，以使代码更易读。”
- “您的代码包含一些编码风格问题，您能在我们合并之前修复这些问题吗？谢谢”
- “请使用 4 个空格而不是制表符”，“这需要放在上一行”；
在 pull request 评审期间，您通常可以留下多个评论，您不必一直使用“请”。但这不会有坏处。
这看起来可能没什么大不了的，但说“谢谢”确实会让其他人感到更受欢迎。
防止冲突升级
有时当人们收到反馈时，他们可能会变得 defensive。在这种情况下，最好尝试以不同的方式进行讨论，以避免进一步升级。
如果您希望有人调解，请加入 #contribs 频道 Symfony Slack，以获得安全的环境，并继续为共同目标努力。
使用幽默
简而言之：极端的不当行为将不被容忍，甚至可能导致您被封禁；保持真实和友好。
不要对严肃的话题使用讽刺，这不属于 Symfony 社区。 并且不要轻视别人的问题；我想这不应该发生？ 😆。
即使某人的解释“容易让人开玩笑”，但对他们来说这是一个真正的问题。拿这个开玩笑无助于解决他们的问题，只会让他们感觉自己很蠢。相反，尝试找出实际问题。
结语
如果您“未能”遵循这些技巧，请不要感到难过。只要您的意图是好的，并且您没有真正冒犯或侮辱任何人；您可以解释您误解了，您并非有意轻视，或者只是失败了。
但不要“只是因为”而说，如果您的道歉不是真诚的，您将失去其他开发者的信任和尊重。
己所不欲，勿施于人。