Question

如果你正在管理开源项目中的程序员，要尽量保持足够的时间，这样他们才能获得足够的技术和政治技能—最少也需要几年时间。当然，没有项目，无论是开源还是闭源，都可以从轮换程序员中获益。新来者搞清楚窍门需要的时间在不同环境下各不相同。但是在开源项目中的代价更加巨大，因为离开的开发者不仅带走了他们的知识，也带走了社区中的他们的地位和其中建立的人际关系。

开发者已经积累的信誉不能够传递。一个新来的开发者不能继承来自离开者的提交权限（可以本章后面的the section called “钱不能让你可爱”），如果新的开发者还没有提交权限，在获得这个权限之前它只能提交补丁。但是提交权限只是所失去的影响中最容易度量的表现。一个长期的开发者也知道邮件列表中所有以前达成和未达成一致的讨论。一个新的开发者，没有这些对话的记忆，也许会再次发起某些讨论，这会损失在组织中的信誉；其他人会奇怪为什么“他们什么也记不住？”新的开发者也对项目特性没有太多政治感觉，所以也不能象老手一样迅速和平滑的影响开发方向。

通过指导契约的程序来训练新手。新的开发者第一天就可以与公共开发社区直接交流，从bug修正和清理任务开始，这样他们可以逐渐熟悉代码基并在社区获取声誉，尽管此时他们还不能在设计讨论中蹦出火花。一个或多个有经验的开发者应当一直负责解惑的任务，阅读新手在开发列表中的每一篇帖子，即使是经验丰富的开发者通常不会注意的内容。这可以帮助团队在新手搁浅之前定位潜在的暗礁。私下的幕后鼓励和忠告也会非常有益，特别是当新手不习惯大量的代码平行同级评审的时候。

当CollabNet雇佣新的开发者为Subversion工作时，我们会坐在一起为新人找一些打开的bug来练练手。我们会讨论解决方案的技术要点，并让至少一个有经验的开发者来评审（公开的）新开发者的补丁（也是公开的）。我们通常不会在主开发列表公开之前查看这个补丁，虽然，如果情况特殊，我们可以如此。重要的是，新开发者经历公开评审的过程中，在熟悉代码基的同时，也需要习惯于接受来自完全是陌生人的批评。但是我们会调整时机，保证我们的评审会在补丁发出之后立刻出现。这样列表中出现的第一个评审就是我们的，这可以帮助我们确立其他评审的基调。它也可以加强一个概念，也就是这个新人需要认真对待：如果其他人看到我们花时间提供详细的评审，并包含完整的解释和归档中合适的参考，他们会意识到正在进行一种培训，并意味着一个长期的投资。这可以帮助他们对那个开发者保持正面的态度，至少会花费更多的时间回答问题和评审补丁。