有点不靠谱？同学们，总会有不堪回首的家伙，真的。此常见问题解答是StackExchange上一个受欢迎的每周博客系列的一部分，StackExchange是一个由社区支持的免费常见问题解答网站联盟，拥有超过100个成员，技术爱好者在其中提出常见问题解答，其他用户帮助回答。Nathan2055问：我为一个特定的网站写了一套开源脚本，和其他几位开发者一起放在了GitHub上（我在这里匿名了我的真实姓名）。采用新系统后，有几位新的开发者加入，其中一位仍然很活跃。然而，这位活跃的成员开始为项目带来许多变化。首先，这家伙删除了我们的版本管理系统（我们使用的版本管理系统与Git不同，但工作原理相似-当前版本称为v4。它可以直接在网站上发布。结果，现在我们没有一个我们可以专注于提供发行说明的空间，这对我们的情绪产生了巨大影响。真正让我感到愤怒甚至气愤离开的情况来自于推送脚本。项目组的其他几位开发人员写道一组简单的Python推送脚本。由于我们在多个站点上有多个版本的脚本，我开始编写一个更大的Java程序，该程序将使用地理界面来替换代理中的原始Python脚本。我使用IM通知我的合作伙伴关于这个消息，但是这个家伙跳出来给我泼了很多冷水——他认为原来的Python脚本可以实现我新脚本的所有功能，而且更轻量级的特性（他还鼓吹Pythonco的优越性与Java等相比）。我已经仔细查看了原始的推送脚本，可以负责任地告诉你——他提到的功能在这里都没有。所以现在我希望弄清楚自己该怎么办。我在这个项目上花了很多时间，所以我绝对不可能一走了之；但我也发现与这个新开发人员一起工作真的很困难。此外，他还成为项目中贡献最大的代码提交者，甚至比主开发者还活跃。我不知道我该如何处理这种情况。有朋友遇到过这样的问题吗？如果是这样，你如何处理它？坚持自己的方式还是正确的方式？gbjbaanb的回答（45票赞成）：1.你可以退出。这可能不是最有建设性的选择，但有时它是唯一的选择。如果你决定这样做，请不要纠结于此，并与你的合作伙伴谈谈你必须离开的原因。节省能量并将其直接用于其他有意义的事情——换句话说，“朝另一??个方向移动”。2.不理会别人，fork到底。您真的没有理由必须与其他人一起工作。坚持分叉，完善代码，让别人继续活在自己的小世界里。您的新项目势必会与您的旧项目正面交锋，而胜负取决于您。事实不言而喻，如果旧的解决方案依靠用户群和功能来压倒新项目，那么也许你真的错了。3.表达你的意见。您可以与开发团队的其他成员交流和表达您的顾虑，让他们知道您的想法和感受。请不要将这些归结为个人问题，记住坚持您对代码更改、缺乏可靠的质量流程或未得到每个成员批准的新决定的观点。可能大家认为旧的解决方案还没有坏到必须更换的地步，并且可能有几个团队成员同意你的判断并支持团队开始修改旧代码。结果，这个想要改变一切的活跃新人冒着失去代码提交权的风险。当然，最终的结果也可能是你意识到自己的错误，愿意和大家一起把项目恢复原状。（后者的可能性是绝对的，除非大家真的发现项目有根本性的偏差。）我们往往很难接受一个自己已经打理了很久的项目，会被新来的人议论纷纷刚进去，保持自己熟悉的方向，当然更安全，更安心。但换句话说，新人改变旧有的习惯做法其实是一件好事——至少在宏观意义上是这样。你站在哪里？BenMcCormick的回答（33票赞成）：我认为还有很多内容没有明确说明，尤其是您自己在项目团队中的角色。而最终答案的选择与这种情况密切相关。如果你是项目中的***并且控制了git存储库：把控制权还给你自己。如果这家伙未经项目负责人同意就提交了不满意的代码，那么干脆取消他的提交权限。这就是开源项目的运作方式——除非用户真正赢得了团队的信任。你不需要也不需要完全放权。如果代码库由其他人控制：与项目团队负责人交谈以表达您的担忧，并鼓励他们采用更严格的计划和批准机制来管理项目变更。如果***不同意你的建议，那么我们可以选择接受现实继续为项目做贡献，当然我们也可以根据自己的看法选择分叉路线来推动项目的发展（记得带一个认同自己观点的开发伙伴）。此外，您还可以选择离开并处理其他工作。不管怎么说，既然现在的情况让自己心里很不舒服，实在是没有继续忍下去的必要了。RealityDeerHunter接受的答案（15票赞成）：请原谅我的直言不讳，但您的文章读起来更像是纯粹的咆哮和抱怨。你说别人喜欢一味的改，然后又抛出一个你认为合理的新方案——Java。请冷静：思考问题不应该是非此即彼，我们不妨寻找一个折衷的解决方案（如果你还想继续参与这个项目，fork确实是最简单的方式——但这不仅会满足你的固执除了自我放纵之外没有任何意义）。请首先仔细考虑项目中每个参与者的明确权限划分。如果没有明确的划分，这样的权力之争将是不可避免的。是的，有时我们不得不相信其他成员的判断。TryGoogle'ssuggestionsKurtosis'sanswer(4votesupvoted):谷歌几年前就这个问题进行过一次技术讨论，所以这里总结一下由此得出的结论性意见：1.Understand：理解你社区成员参与的动机在当前项目的工作中，再将其与其他机会成本进行比较——这些动机必须小心保护，它们是项目持续生存和进步的根本因素。2.强化：建立一个健康的社区环境，礼貌、尊重、信任和谦逊是必不可少的社会化组成部分。3.识别：寻找坏苹果的明显迹象（这个清单还在继续，但既然你问过这类问题，你可能以前见过很多）。4.监督：冷静地坚持自己的立场，不要回应侮辱、轻视、挑战和不尊重，同时不断强化上述社区规范。原文链接：http://arstechnica.com/information-technology/2014/01/how-to-deal-with-a-difficult-programmer-on-an-open-source-project/
