开源代码 不开源

在上一篇文章中，我为您提供了如何获得反馈的提示，尤其是在您第一次免费和开源项目的背景下。 现在该讨论同一枚硬币的另一面： 提供反馈。

如果我告诉您您所做的贡献是“愚蠢”或“天真”的，您会感觉如何？ 您可能会生气，受伤或两者并存，理应如此。 这些是刻薄的单词，当指向人时，可以像刀子一样切开。 单词很重要，而且很重要。 因此，在为项目留下反馈时，应尽可能多地考虑与对项目所做的任何其他形式的贡献一样的想法。 当您撰写反馈时，请对自己进行思考：“如果有人对我这样说，我会有什么感觉？有人会以其他方式采取这种方式吗？这种方式不太有用？” 如果最后一个问题的答案甚至是肯定的，请回溯并重写您的反馈。 最好现在花一点时间重写，而不是以后花很多时间道歉。

当某人犯了一个本来应该很明显的错误时，请记住我们所有人都有不同的经验和知识。 对您来说显而易见的可能不是别人。 而且，如果您还记得，曾经有一段时间那件事对您来说并不明显。 我们都会犯错。 我们都错字了。 我们都忘记了逗号，分号和右括号。 节省大量时间和精力：指出错误，但忽略判断。 坚持事实。 毕竟，如果错误很明显，那么就不需要批评了，对吧？

1. 避免随意评论。 切记只查看贡献，而不要查看贡献者。 就是说，要指出的是，“在这种情况下，这种贡献可能会更有效……”而不是“ 您没有效率地做到这一点”。 后者是临时反馈。 Ad hominem是拉丁语，意为“ 给人 ”，这是您的反馈指向的地方：是给贡献者提供的，而不是贡献本身。 通过提供有关该人的反馈，您可以使该反馈成为个人反馈，贡献者有理由将其个人化。 制作反馈时请务必小心，以确保您只处理文稿的内容，而不是不小心批评提交文稿的人员。
2. 包括正面评论。 并非您的所有反馈都必须（或应该）很关键。 当您查看文稿时，您会看到自己喜欢的内容，并提供反馈。
   指出错误，但忽略判断。 坚持事实。

   几项学术研究（包括鲍迈斯特，布拉斯夫斯基，芬克瑙尔和沃斯的一项重要研究）表明，人类更多地关注负面反馈而不是正面反馈。 如果您的反馈意见完全是负面的，那么对于撰稿人来说可能会非常令人沮丧。 包括积极的强化和反馈会激发人们的积极性，并帮助他们感觉自己的贡献和花费的时间，这些都加在一起，使他们感到将来更愿意提供其他贡献。 不一定非得花哨的赞美，而是快速的“呵呵，这是一种非常聪明的处理方式。它可以使一切顺利进行”，可以极大地鼓励某人继续做出贡献。

3. 问题也是反馈。 赞美是一种不太常见但有价值的评论反馈。 问题是另一个。 如果您正在查看稿件，却无法说明提交者的原因
   如果您的反馈意见完全是负面的，那么对于撰稿人来说可能会非常令人沮丧。

   以他们的方式做事，或者如果所做的贡献对您而言没有多大意义，则索取更多信息可作为反馈。 它告诉提交者，他们贡献的内容并不像他们想的那么清晰，可能需要做一些工作才能使该方法更明显，或者如果它是代码贡献，则提供注释以解释发生了什么以及为什么。 简单地说，“我在这里不了解这一部分。能否请您告诉我它在做什么以及为什么选择这种方式？” 可以启动对话，从而做出贡献，这对于将来的贡献者来说更容易理解和维护。

4. 期待谈判。 使用问题作为反馈的形式意味着将有那些问题的答案，或者可能会有其他问题作为回应。 无论您的反馈是有问题的还是陈述式的，您都应该期望在整个过程中进行某种形式的对话。 另一种选择是将您的反馈视为不可争议的，将您的话视为法律。 尽管这绝对是您可以采用的一种方法，但它很少是一种好的方法。 提供有关贡献的反馈时，最好是协作而不是命令。 随着这些对话的产生，将它们视为双方进行对话和学习的机会非常重要。 愿意讨论他们的方法和您的反馈，并花时间了解他们的观点。

底线是：不要混蛋。 如果您不确定要离开的反馈是否听起来像个混蛋，请在单击发送之前先暂停一下，让别人查看它。 在该反馈的接收端对人有同感。 虽然这句格言已有几千年的历史了，但今天它仍然是正确的，即您应该像对待别人那样对别人做。 把自己放在自己的鞋子上，并致力于提供帮助和支持，而不是简单地做到正确。

由VM（Vicky）Brasseur改编自《借助开放源代码打造您的未来》 ，版权所有©2018 The Pragmatic Programmers LLC。 经出版者许可转载。

翻译自: https://opensource.com/article/18/10/best-practices-giving-open-source-code-feedback

开源代码 不开源