发展你们的开源项目社区

社区拥有强大的能量。这种能量可能是正面的也可能是负面的，这一切都取决于你如何驾驭它。随着项目社区的成长，要想办法让之成为建设性的力量，而不是具有破坏性的。

不纵容坏人

一些流行的项目将不可避免地会吸引到一些破坏它们的人。这些人可能会从一些没必要的争论开始，对一些细枝末节进行纠缠不清，甚或用语言伤及他人。

对于这类人，必须采取零容忍的政策。一旦犹豫不决，那么这些消极的人会给社区的其他人带来不愉快的感觉。那时就会出现劣币驱逐良币的现象。

事实上是，拥有一个支持性社区才是项目成功的关键。如果没有来自我的同事，互联网上一些友好的陌生人，以及聊天渠道IRC的帮助，我不可能做好这些工作。（。。。）不要退而求其次。不要容忍混蛋。

— @okdistribute , “如何运营一个 FOSS 项目”

关于项目琐碎方面的定期辩论会分散其他人（包括您）的注意力，使他们无法专注于重要任务。新人可能会看到这些对话而不想参加。

当发现社区中有消极的行为时，要即时、公然的指出来。特别说明的是，要用坚定的语气解释他们的行为为什么是不可接受的。如果这种问题继续发生，你有必要要求他们离开 。你的行为准则 是为这些情景准备的建设性指南。

知道贡献者在哪里

随着项目的成长，好的文档会变得愈加重要。临时贡献者或路人是不可能一下子就对项目非常熟悉，一份好的文档，能够很快找到他们需要的。

在 CONTRIBUTING 文件里，需要明确告诉新来的贡献者该如何开始。而且若是可能为了想要达到这个目的，还需要准备一个专门的部分。

在issue列表中，缺陷的标签需要做到适合不同类型的贡献者：例如，“仅供入门者” , “优质Bug首秀”, 或者 “文档”. 这些标签 能够帮助新人快速浏览issues以及开始。

最后，撰写让人赏心悦目的文档，进一步让人感到愉悦和舒服。

你不可能做到与项目中的绝大多数人产生互动，你们可能没有收到一些贡献，因为有些人感到害怕或者不知道该从何处开始，有时候即使是几个字也能阻止一些人沮丧地离开你们的项目。

例如，这里是Rubinius 如何开始它的贡献指南 ：

我们想感谢你们使用Rubinius。这个项目是一个充满爱的工作，我们希望所有用户查找bugs，取得性能上的提升，以及帮助完善文档。每一个贡献都是有意义的，所以感谢你们的参与。话虽如此，但我们还是要求你们遵守一些指南，这样我们就能够找到你们的issue。

共享项目所有权

社区的领导者们有着不一样的意见，而这也是所有健康社区能够成长的原因之所在！终究你会明白，粗暴鲁莽的做法不能得到大家的认同，谦虚低调的做法更容易让大家接受，才是王道。

— @sagesharp , “是什么成就一个好的社区？”

当大家觉得自己就是项目的主人时，他们就会非常乐意为项目做贡献。但这并不意味着要去改变项目的愿景，又或者接受不想要的贡献。但是社区越信任他们，他们就会越忠实。

要尝试去尽快的找到让人们觉得社区就是自己的路径，这里有一些经验和大家分享：

• 不要亲自去修复简单（非关键）的缺陷。 相反，将这些缺陷作为招募新贡献者的工具，或者指导想要参与贡献的人。开始时可能效果不是很理想，但经过一段时间你们会得到想要的结果。例如，@michaeljoseph 要求一位贡献者提交一个pull request在一个Cookiecutter issue的下面，而不是自己修复它。

• 在项目中添加一个贡献者或者作者文件 用于记录每一个参与贡献的人。
• 如果社区有了一定的规模，那么 发送一封信或者发表一篇博客 感谢贡献者们。Rust的Rust周报 和Hoodie的Shoutouts 就是两个非常好的范例。
• 给每个贡献者提交的通道。@felixge 发现这样会使大家越发乐意斟酌他们的补丁 ，以及他甚至发现，在他没有工作的一段时间，项目依然有新的维护者进来。
• 如果项目是托管在 GitHub 上，那么 将项目从你们的个人账号转移到一个组织，以及添加至少一个备份管理员。组织能让与其他人一起工作在同一个项目在变得更加容易。

事实上很多项目只有一个或者两个做大量工作的维护者。随着项目以及社区越来越大，就会有更多的人参与进来。

虽然并不是一直都有人在回答问题，但是你可以去增加一些信号，以让他人有能够接触的机会，越是尽早开始，越是能够获得帮助。

你们最大的兴趣是招募喜欢你们项目以及能够做你们不能做的事的贡献者。你喜欢编码，但不喜欢回答issues？那么让社区中能做这件事的人去做。

— @gr2m , “打造受欢迎的社区”