……如果我现在处于那样的情况，我会在项目根目录中写一个CONTRIBUTING.md文件，以冷静的方式描述我的期望（例如：PR是否被欢迎，项目决策是如何进行的等等）。如果用户表达的期望与我的意图不一致，我会直接指向CONTRIBUTING.md并结束讨论。我会在感到沮丧的程度像这个摘要中表达的那样之前就采取这一步。我这样说并不是为了批评链接中的帖子；我只是最近才明白这一点。但看起来这比让沮丧和怨恨随着时间积累要更健康。
源讨论开源不是关于你的（2018）原帖 188 条评论 · 导入时统计把你的经验，加入这段讨论。
> 我不是为了批评那个链接中的文章 你所写的显然就是对那个链接中文章的批评。
完整原文我同意，TFA（原文）是一个如何明确写出期望的很好例子。 但至于指责Hickey最终不得不直言不讳，我完全不这么认为。有些人认为开源团队应该为他们免费工作。无论怎么解释，都无法改变许多人的想法。他们理解这些论点，只是不同意。
完整原文此外，作为计划的一部分，冷静地写下合同可以避免在沮丧中匆忙完成，从而留下不好的后果。
完整原文有人曾经说过：滥用和期望会侵蚀合作的文化。 我现在在$work中亲眼目睹了这一点。我们正在构建的平台已经部署了一个旗舰产品，但整个销售/市场/项目文化完全没有做出调整。人们很咄咄逼人，充满辱骂，沟通不好，而且把所有事情都升级到高管层面。因此，我们平台工程团队现在开始像老派的系统管理员一样，建立支持流程、工单、规则、期望，其他一切都可以去见鬼。 现在每个人都在受苦，但我们必须这么做来维护自己的理智。 至少对我来说，这似乎在很多开源基础设施项目中都在发生。人们对这些项目需要的东西变得非常咄咄逼人和易怒。我宁愿和我的老板沟通来设置一个PR（请求合并）来获得我们需要的东西（而且我在这方面相当成功），…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。