开源社区，简化版
引言
构建和维护开源社区本质上取决于三件事：
- 让人们有兴趣贡献
- 消除进入项目和贡献的障碍
- 留住贡献者，使他们持续贡献
如果你能让人们感兴趣，然后让他们实际贡献，并让他们留下来，你就有了一个社区。否则，你就没有。
如果你刚刚启动一个项目或需要改进现有项目的社区，你应该按相反的顺序处理这些点。如果你在完成后面两个步骤之前就让人们对项目感兴趣，那么人们将无法进入，即使进入也不会留下来。你实际上不会扩展你的社区。
因此，首先，我们要确保能够留住现有和新贡献者。一旦做到这一点，我们就要消除进入障碍，以便感兴趣的人能够真正开始贡献。只有到那时，我们才开始担心如何让人们感兴趣。
留住贡献者
对于Bugzilla项目，这是我们最大的挑战。一旦有人开始贡献，是什么让他们持续贡献？我们如何让人们留下来？
我们在回答这些问题时有一个有趣的优势，因为我们是现存较老的开源项目之一，自1998年底以来一直存在。因此，我们有大量的实际数据可供使用。我们通过两种方式挖掘这些数据：
- 我们对所有过去离开项目的开发者进行了调查，询问他们为什么离开。这是一个自由形式的调查，允许人们以任何方式回答。
- 我们创建了项目整个十年期间贡献者数量的图表，并将图表的起伏与我们随时间采取或未采取的各种行动相关联。
完成所有这些后，我向Bugzilla项目的开发者发送了一封电子邮件，描述了研究结果。如果你想阅读整封电子邮件，可以查看，但我会在这里总结发现：
不要长时间冻结主干
Bugzilla项目有一个相当标准的系统，包括稳定分支（接收很少更改，例如“3.4”分支，我们提交错误修复并进行次要发布如3.4.1、3.4.2等）和一个主线“主干”仓库（所有新功能都进入这里，最终成为我们的下一个主要发布）。
在过去，在主要发布之前，我们会“冻结”主干。这意味着在几周或几个月内无法开发新功能，直到我们认为主干足够稳定以称为“发布候选”。然后，我们会从主干创建一个新的稳定分支，并重新开放主线主干以进行功能开发。然而，当主干被冻结时，Bugzilla项目中任何地方都没有功能开发。
图表分析非常清楚地显示，每次我们冻结时，社区都会急剧缩小，并且在我们解冻后需要几个月时间社区规模才能恢复。这种情况每次冻结时都会一致发生，跨越多年和多个发布。
开源的传统智慧是，人们喜欢处理功能而不喜欢修复错误。我不会说这完全正确，但我会说，如果你只让人们修复错误，那么他们中的大多数人不会留下来。
我们通过从不冻结主干来解决这个问题。相反，我们在通常“冻结”主干的时间点立即分支。主干始终保持开放以进行新功能开发。是的，这意味着有一段时间，我们的注意力会分散在主干和最新分支之间。我们将相同的错误修复提交到分支和主干。我们还在进行这些错误修复的同时在主干上进行功能开发。然而，我们发现，不仅社区以这种方式更快地扩展，而且我们实际上比过去更快地发布版本。所以这是一个双赢的局面。
人员流动是不可避免的
调查发现，贡献者离开的首要原因是他们不再有时间贡献，或者他们作为工作的一部分贡献，现在他们已经换了工作。本质上，大多数贡献者最终离开是不可避免的。
因此，如果社区成员肯定会离开，那么持续扩展社区的唯一方法是弄清楚如何留住新贡献者。如果你不让新成员留下来，那么无论你做什么，随着老贡献者离开，社区将不断缩小。
因此，虽然留住现有贡献者很重要——毕竟，你希望人们尽可能长时间地留下来贡献——但最重要的是留住新贡献者。你如何做到这一点？嗯，这很大程度上是其余这些点的内容。
立即回应贡献
Bugzilla项目有一个代码审查系统，要求所有新贡献在成为Bugzilla的一部分之前必须由经验丰富的开发者审查。多年来对这个系统有各种抱怨，但分析调查数据显示，人们离开项目是因为审查花费时间太长，而不是因为审查太难。事实上，只要在有人提交贡献后几乎立即进行审查，审查可以尽可能严格。
人们（通常）不介意必须修改贡献。他们甚至通常不介意多次修改。但他们介意的是，如果他们发布一个补丁，三个月没有得到审查，然后他们必须修改它，只是再等三个月才被告知必须再次修改。重要的是延迟，而不是质量控制的水平。
还有其他快速回应贡献的方法。例如，立即感谢某人发布补丁可以大大有助于留住新贡献者并将他们“转化”为长期开发者。
极其友善并明显表示赞赏
对于几乎每个回应我们调查的人，除了“我的工作变了”或“我没有时间”之外，不留下来的因素出奇地个人化。我知道我们都与计算机打交道，也许我们愿意认为工程应该是一个完全冷酷的科学职业，我们都根据机器的要求正确完成工作，而不担心我们的情感或个人投入。然而，没有什么比这更远离事实了——人们与社区成员的个人互动、他们感到被赞赏的程度以及他们感到被攻击的程度，实际上是留住社区成员的最重要方面。
当人们以志愿者身份贡献时，他们没有得到金钱报酬，他们得到的是钦佩、赞赏、工作完成良好的感觉以及他们正在帮助创建影响数百万人的产品的知识。当某人贡献了一个补丁时，你需要感谢他们。即使补丁完全糟糕且必须完全重写，你也需要感谢他们。他们为此付出了一些工作，如果你不赞赏这一点，他们甚至会在开始之前就离开。毕竟，大多数人在工作场所得到的赞赏很少——他们留在那里是因为他们得到金钱报酬！如果他们也不赞赏他们的工作，或者更糟的是，在甚至感谢他们之前就攻击他们贡献的每个方面，他们不需要免费为其他组织工作。
当然，你仍然需要纠正人们贡献中的错误。“友善”不包括将糟糕的代码放入你的系统中。这对任何人都不友善，包括技能可能需要提高的贡献者，他们可能继续相信他们错误地做的事情实际上是正确的。你仍然必须是细心的审查者和非常好的编码者。
这意味着，除了告诉人们他们贡献中的错误之外，赞赏他们贡献中的正确之处也很重要，即使仅仅是他们花时间贡献的事实。你必须实际告诉贡献者你赞赏他们的贡献。你这样做越频繁和真诚，就越有可能留住贡献者。
鼓励完全不存在个人负面情绪
一件事以闪电般的速度将人们赶出项目，那就是当他们尝试做积极的事情时受到个人攻击。“个人攻击”可以小到关于他们代码的不愉快笑话，而不是仅仅直接的技术描述错误。说类似“你怎么了？”而不是实际留下一些有帮助的评论。将个人批评伪装成“试图帮助他们更好地编码”或“帮助他们与他人相处”。无论这些行为看起来多么合理，它们都是对你的社区极其危险的个人攻击。
说实话，编码和与有不同观点的人合作项目有时会非常令人沮丧，我和任何人一样在这个领域犯过错误。但我们都必须学会，仅仅因为我们个人对他们感到沮丧就侮辱其他开发者作为人是不行的。
然而，解决方案不仅仅是说“大家现在把挫折憋在心里直到爆炸”。有很多实用的解决方案。最好的之一是建立一些具体的系统来处理有问题的贡献者。如果Bob无法与某个贡献者相处，社区中需要有人Bob可以去找以帮助解决问题。我们称这个可找的人为“社区调解员”。所以Bob告诉调解员问题，也许调解员看到那个贡献者确实是个可怕的人或糟糕的编码者，因此这个“社区调解员”温和地纠正那个贡献者。但也有可能Bob和那个贡献者之间存在一些沟通问题，调解员只需要帮助解决。
这个“调解员”系统不是处理问题的唯一方式。你可以通过多种方式解决问题——最重要的是你确实解决它。如果没有一些渠道或方法来处理个人挫折，个别贡献者会将