开源代码不开源_提供开源代码反馈的4个最佳实践-函數-匯編語言學習筆記

开源代码不开源_提供开源代码反馈的4个最佳实践

2023-09-18 阅读 19 评论 0

摘要：开源代码不开源在上一篇文章中，我为您提供了如何获得反馈的提示，尤其是在您第一次免费和开源项目的背景下。现在该讨论同一枚硬币的另一面：提供反馈。如果我告诉您您所做的贡献是“愚蠢”或“天真”的，您会感觉如何？您可能会生气&#

开源代码不开源

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

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

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

避免随意评论。 切记只查看贡献，而不要查看贡献者。就是说，要指出的是，“在这种情况下，这种贡献可能会更有效……”而不是“ 您没有效率地做到这一点”。后者是临时反馈。 Ad hominem是拉丁语，意为“ 给人 ”，这是您的反馈指向的地方：是给贡献者提供的，而不是贡献本身。通过提供有关该人的反馈，您可以使该反馈成为个人反馈，贡献者有理由将其个人化。制作反馈时请务必小心，以确保您只处理文稿的内容，而不是不小心批评提交文稿的人员。
包括正面评论。 并非您的所有反馈都必须（或应该）很关键。当您查看文稿时，您会看到自己喜欢的内容，并提供反馈。
指出错误，但忽略判断。坚持事实。
几项学术研究（包括鲍迈斯特，布拉斯夫斯基，芬克瑙尔和沃斯的一项重要研究）表明，人类更多地关注负面反馈而不是正面反馈。如果您的反馈意见完全是负面的，那么对于撰稿人来说可能会非常令人沮丧。包括积极的强化和反馈会激发人们的积极性，并帮助他们感觉自己的贡献和花费的时间，这些都加在一起，使他们感到将来更愿意提供其他贡献。不一定非得花哨的赞美，而是快速的“呵呵，这是一种非常聪明的处理方式。它可以使一切顺利进行”，可以极大地鼓励某人继续做出贡献。
问题也是反馈。 赞美是一种不太常见但有价值的评论反馈。问题是另一个。如果您正在查看稿件，却无法说明提交者的原因
如果您的反馈意见完全是负面的，那么对于撰稿人来说可能会非常令人沮丧。
以他们的方式做事，或者如果所做的贡献对您而言没有多大意义，则索取更多信息可作为反馈。它告诉提交者，他们贡献的内容并不像他们想的那么清晰，可能需要做一些工作才能使该方法更明显，或者如果它是代码贡献，则提供注释以解释发生了什么以及为什么。简单地说，“我在这里不了解这一部分。能否请您告诉我它在做什么以及为什么选择这种方式？” 可以启动对话，从而做出贡献，这对于将来的贡献者来说更容易理解和维护。
期待谈判。 使用问题作为反馈的形式意味着将有那些问题的答案，或者可能会有其他问题作为回应。无论您的反馈是有问题的还是陈述式的，您都应该期望在整个过程中进行某种形式的对话。另一种选择是将您的反馈视为不可争议的，将您的话视为法律。尽管这绝对是您可以采用的一种方法，但它很少是一种好的方法。提供有关贡献的反馈时，最好是协作而不是命令。随着这些对话的产生，将它们视为双方进行对话和学习的机会非常重要。愿意讨论他们的方法和您的反馈，并花时间了解他们的观点。