如何处理加入开源项目的困难程序员？

我有一个特定站点的开放源脚本（我试图在这里不使用任何名称来命名），我和其他一些开发人员最近将其移至GitHub。自从迁移到新系统以来，我们已经获得了几名新开发人员，特别是其中一位非常活跃的开发人员。但是，这个活跃的人已经开始更改许多项目。

首先，他删除了我们的版本控制系统（不像Git，而是那样-我们称它为version v4.1.16），并说最好在我们认为准备就绪时将代码推送到该站点。现在没有放置发布说明的集中位置，这已经很烦人了。

使我准备好收拾行装的事情是推脚本。该项目的另一位开发人员编写了一个简单的基于Python的推送脚本。由于我们在不同的地方在线保留了多个版本的脚本，因此我开始使用图形界面来编写一个较大的Java程序，以取代Python脚本。我在IRC上通知了所有人，我收到了程序员的一个非常讨厌的答复，他说旧的基于Python的脚本可以完成我所能做的一切，而且更加轻巧（他还评论说，他认为Python比Java更好，依此类推）。我查看了旧推脚本的代码，发现他说的功能都不存在。

所以现在我想知道该怎么办。我在这个项目上花了很多时间，所以我不想起床离开，但是我发现与这个新开发人员一起工作很困难。另一方面，他现在是项目的第一提交者，提交的数量比主要开发人员还要多。我不太确定该怎么做。还有其他人遇到过这个问题吗？如果是这样，您做了什么？

更新1：我已经禁用了每个人的提交访问权限，并且我要求人们接受请求请求。我还提出了一些解决其他问题的措施。其他人都没有对此表示任何支持。麻烦的开发人员只是说，那些不严格遵循“提交操作”的人会认为，当项目真的没有时，它就会变得杂乱无章。我显然不同意这一点，因此我正在认真考虑退出该项目。

更新2：首席开发人员开始对以下事实感到满意：我的一个提交应该删除了代码中的三个换行符（还原提交在我发布讨论后显示，甚至没有引用我的“提交”），然后他们两个开始讨论是否撤消我的提交访问权限。因此，我已经完成了合乎逻辑的事情，并离开了项目。感谢您对每个人的帮助！

1. 你可以退出。这不是最有建设性的事情，但是有时这是唯一的选择。如果您这样做了，那就不要四处抱怨自己必须如何放弃它，而要把精力投入到其他事情上-换句话说就是“继续前进”。

2. 你可以分叉。您没有理由与任何人一起工作。分叉，改进代码，让其他人继续拥有一些自己的自我。无论您是否成功，新项目都将与旧项目竞争，而新项目则取决于您，无论是用户还是功能方面，旧项目都胜过您。

3. 您可以与项目的其他开发团队合作，表达您的疑虑。不要将其设置为个人，而是要确定您对代码搅动不满意，或者缺乏既定的质量流程，或者对新决策未经所有人的同意而感到不满意。您可能会被告知没有什么足以改变的错误，或者您会得到其他一些人的同意，即团队需要解决问题。这可能最终导致破坏性人失去提交访问权限。也许你们都会同意，某些更改不是改进，因此需要还原该项目。（后一种选择是最有可能的结果，除非它变成了根深蒂固的观点论点。）

当有人来改变您已经习惯的安全舒适的例程时，可能会很困难，但是可以说，有人来改变传统的舒适做法本身就是一件好事。

您已经不清楚您在这里扮演什么角色。答案取决于您的适应能力。

如果您正在领导项目并控制git存储库

收回控制权。如果此人在不咨询您的情况下做出您不喜欢的提交，请删除其直接提交访问权限。他可以分叉项目并发出合并请求以合并其提交。这就是开源在用户建立信任之前应该如何工作的方式。您不需要也不应立即授予完全访问权限。

如果其他人控制回购

向做此事的人表达您的疑虑，并鼓励制定更严格的计划和批准变更流程。如果领导层不适合某个流程，那么您可以选择接受现状并继续做出贡献，可以分叉该项目并按自己的版本进行工作（带同您意见的人一起），也可以选择离开并从事其他工作。无论如何，您都无需继续处理。

请原谅我的直言不讳，但您的帖子读起来很a。

您说的是另一个想要盲目的更改的人，但是当您谈论自己的新的闪亮的Java程序时，您就会自相矛盾。

休息一下; 它不是一条单向的街道，请尝试找到折中方案（如果您想继续从事该项目-分叉是最简单的决定，但它不会带给您任何有用的信息，尽管它可能会打动您的自我）。

还请仔细考虑项目中的分工 - 如果您没有明确的界限告诉谁胜任，草坪战争是不可避免的。是的，您有时必须相信别人的判断。

在几个答案中已经提到，分工是减少冲突的一种方法。以下是一些具体示例：

1. 平衡生产力与稳定性。要从战略游戏中借鉴一个类比，团队必须由Boom，Turtle和Rush组成，并且队友必须准备根据情况改变角色。
   • 当一个人陷入生产力狂潮时，其他人可以从事以下工作：
   • 其它功能
   • 错误修复
   • 规格（管理新功能请求，并验证软件是否符合商定的标准）
   • 质量保证
     • 手动（探索性）测试
     • 自动化测试
   • 文献资料
   • 重构和代码清理
   • 进行用户研究以收集想法以进行改进
   • 等等
2. 可以将项目模块化（例如在软件体系结构中），或者进行分隔（例如在项目管理中），以便可以独立地处理每个模块。
   • 通常，大多数同时包含前端和后端的软件都应该模块化，因为它们的开发速度不同。
   • UX丰富的软件可能由于大量使用跨模块事件路由而难以模块化。
   • 项目的维护者可能希望通过避免模块化来使项目保持简单。
3. 功能分支。每个开发人员都可以分叉该项目，使用他/她喜欢的宠物功能，并在实现完成后请求合并。首席开发人员可以就是否接受合并拥有最终决定权。

除了避免冲突方面，很明显该项目可能没有足够的治理。

为什么治理很重要？想象一下，有一天，一位前队友拿走了该软件的一部分，并起诉该团队侵权。或该团队被专利巨魔起诉。还是一个没人知道的人决定将DMCA通知发送到项目托管站点，并要求删除该项目的源代码。

至少：

• 所有贡献的源代码将使用的许可证
• 可用于发布项目源代码的许可证
  • 如果寻求新的公共许可证，如何获得每个贡献者的同意
• 谁可以对该项目拥有管理权限
• 指定谁来回应法律要求（例如DMCA通知或专利巨魔）
• 谁来管理项目的财务（支付服务器费用并记账广告收入或捐赠）
• 谁拥有投票权以包括新成员和驱逐成员。
• 等等

大多数开源项目站点都可以提供现成的项目管理章程。

我以前看过这个问题。但是几年后，您真的对项目感到厌倦，所以我的解决方案是离开项目。它可能对您不起作用，但问题根本在于不同的人以不同的方式思考。您认为非常重要的功能对其他人根本不重要。

好的计划是将不同人员的任务分开。如果您可以与每个人都负责的项目中的每个人都同意，那么只有一个人对项目的某些部分进行决策。但是团队合作总是很困难。您仍然永远不会喜欢其他程序员所做的决定。最好的解决方案是永远不要看其他程序员的决定。只要相信他们做正确的事就足够了。

共同的目标将把您的精力集中在重要的事情上。朝着同一个方向努力的每个人都很难得到，而且无论如何都会发生冲突。确定共同目标需要知道项目的当前状态，然后再确定一段时间后的位置。

这是需要避免的示例：例如，许多C ++程序员认为未使用STL库的代码已损坏。其他程序员认为对外部库的所有依赖都已破坏，包括STL。这样的冲突无法得到妥善解决-两种情况都不能同时得到解决-而最有问题的人无论遇到什么反对都将发表自己的意见。

我认为有四个选择。

1. 把他踢出去。您（仍然）仍然是该项目的主要成员；撤销他的推送特权并称之为一天。最有可能的结果是他分叉了项目，分裂了社区，然后一场战争爆发了，当尘埃落定时，其中一个将是受欢迎的分支。
2. 分叉并继续其他地方。攻击性小于1.，但后果是相同的。您必须在社区中保持活跃，才能将人们拉到身边。
3. 顺其自然：让他做他正在做的事情，冷静下来，并希望最好。
4. 与社区讨论，按要求妥协并解决问题。

就个人而言，我更喜欢选项4。

几年前，谷歌就此进行了两次技术讲座。看他们：1，2。简而言之：

1. 理解：了解您的社区从事项目工作的动机以及所有其他机会成本，并保留这些原因。
2. Fortify：以礼貌，尊重，信任和谦虚的社会准则建立一个健康的社区。
3. 确定：寻找有毒人物的明显迹象（要列出的人数太多，但是如果您问这个问题，那么您可能已经认识了很多）。
4. 消毒：保持镇定并站稳脚跟，对侮辱，轻微，挑战，不尊重等保持被动，并持续加强社区规范。

一个全面的书面提纲可用太多，如果你喜欢阅读，而不是手表。

您不能不付出任何努力就表达自己的担忧和困难而辞职。我知道这可能很困难。如果事实上您和您的团队成员还很年轻，还没有亲身经历过任何开发团队中发生的许多社会问题，那真的很难。

话虽如此，我坚信您应该表达您的关注。您可以在电子邮件中写下这些内容，并将其显示给您的信任朋友，这些朋友不属于团队，对您的工作没有兴趣或几乎没有兴趣。在这种情况下，您可能会得到很好的反馈，从而使电子邮件的措词不太苛刻。坚持事实。不要指责或责备。这是事实，因为缺少“ blah”，很难为您做点什么。每个团队成员都应该清楚为什么缺少“ blah”，即“新程序员”已删除或没有完成任何事情。

同样，发送此电子邮件很困难，但是就其本身而言，这是一次很好的体验，可能对您日后的工作非常有用。值得学习的好课。

PS：我并不是想听起来太父母。但是我的确对包括我的孩子在内的任何人说了这句话。