让项目向成功方向迈进

现在的你，已经启动了属于自己的项目，而且正在传播它，更重要的是现在已经有人将之下载到本地进行观摩。这真是令人振奋！那么你现在要做的就是，怎么能够让这些有兴趣的人们坚持下去，持续跟进项目。

一个受欢迎的社区对于项目的未来至关重要，如果你的项目是刚刚开始收到他人的首次贡献，那么你需要给贡献者们一次愉悦的体验，以鼓励他们进一步的继续参与。

让大家感到受欢迎

可以通过被@MikeMcQuaid称之为贡献者漏斗的方法思考项目的社区。

contributor funnel

当建立了自己的开源社区，你需要考虑如何让那些处在漏斗上方的人（潜在用户）转移到漏斗下方（活跃的维护者）。目标是减少贡献者们在每个阶段所遇到的摩擦。当人们能够轻易的取得成绩时，他们就会乐意去做更多事。

从你的文档开始：

好的文档能够邀请他人参与你们项目的互动。最终，一些人会开一个issue或者pull request。将这些互动视为机会，将他们转移到漏斗的下方。

  • 当一些人选择了你们的项目，请对他们表示感谢！ 一次糟糕的体验就可能失去一个用户。
  • 及时回应。 如果你们一个月都没有回答他们的问题，他们可能早已忘记了你们的项目。
  • 对你以后接受的所有贡献者持开放态度。 很多贡献者是从一份bug报告或者小的修复开始的。这里有很多为项目做贡献的方式。让大家选择他们喜欢的方式。
  • 如果你不赞成一个贡献， 首先你需要对他们的想法表示感谢，同时 解释为什么它不适合项目，如果有必要的话你可以给出相关的文档链接。

多数开源贡献者是”临时贡献者”，因为他们只是偶尔参与项目贡献。一位临时贡献者可能没有充足的时间全程跟踪你的项目，所以你的工作是能让他们很轻松地参与贡献。

鼓励其他的贡献者也是对项目的一种投资。当你们授权大量的粉丝做他们感兴趣的工作时，压力就会少很多。

记录一切

当你开始一个新项目，你会觉得保持工作的私有性是正常的。但是开源项目开始于你在公共平台记录自己的工作进程。

当你把事情记录下来，会有更多的人能够按照预定的方式参与到每一个过程中。你可能会得到意想不到的帮助。

书写东西不仅仅只是技术文档。任何时刻，你们有写一些东西或者私自讨论项目的冲动，请询问自己是否能将之公开。

保持项目透明的项目路线：你们期待什么类型的贡献者，如何审查贡献，或者你们为什么做某些决定。

如果你注意到有多个用户遇到过同样的问题，那么你应该将答案记录在 README 中。

对于经常遇到的问题，你们可以考虑发布你们的笔记或者相关的issue。在这种情况下得到的反馈常常会出乎意料。

记录一切也适用于你自身的工作。如果你正在进行大量的更新工作，请将其放入pull request并标记为正在进行（WIP）。这样，可以让其他人感觉参与过早期工作。

积极回应

一旦你推广项目，人们将会给你们反馈。他们可能会问项目是如何工作的，或者参与项目初期需要你的帮助。

当有人列出一条issue，提交一个pull request，或者询问项目的有关问题时，你们应该尽量回答他们。当你们快速地做出回应时，人们将感觉到他们参与了对话，以及他们将会更热情地参与。

如果你无法及时审查请求，请尽早确认，这样会有助于提高参与度。这里是@tdreyno在Middleman上所回应的一个pull request：

middleman pull request

Mozilla的一份研究发现 如果贡献者在48小时内收到代码审查，他们会有很大的回头率，且极有可能会再次贡献。

与项目有关的话题也可能发生在互联网的其它地方，例如Stack Overflow，Twitter，或者Reddit。你可以在像这样的一些网站设置通知，这样当有人提及项目时，可以即时的收到提醒。

为你们的社区提供一个聚会的场所

有两个理由可以解释为什么要给社区提供一个聚会的场所。

第一个理由是为了贡献者。线下聚会可以帮助人们相互认识。因为有着共同兴趣的人会想要一个可以聊天的地方。同时当信息是公开的而且是适宜的时候，任何人可以阅读过去的档案以至于能够快速的追赶以及参与。

第二个理由是为了社区本身。如果社区没有提供一个公共的场所来谈论项目，他们可能会直接与你联系。刚开始时，回复私有来信可能对你来说很轻松。但是经过一段时间后，尤其是如果项目变得流行的时候，就会感到疲于应付。不要私下和人们谈论你们的项目，而是直接指明他们去指定的公共渠道。

公共交流和指明人们开一条issue一样简单，而不是直接发送电子邮件或者在博客上发表评论。你也可以为了方便人们谈论项目设置一个邮件列表，或者创建一个Twitter账号，Slack，IRC频道。或者尝试上述的所有方式。

Kubernetes kops 每隔一周抽出办公时间帮助社区成员：

Kops每隔一周都会留出时间为社区提供帮助和指导。Kops维护者已经同意留出时间专门与新手一起工作，帮助PRs，以及讨论新特性。

公开交流需要特别注意的事项：1）有关安全方面的issues 2）敏感的行为准则。应该为大家提供一个私下报告这些issue的方式。若不想使用自己的个人邮箱，那么就创建一个公用的邮箱。

发展你们的社区

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

不纵容坏人

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

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

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

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

知道贡献者在哪里

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

在 CONTRIBUTING 文件里，需要明确告诉新来的贡献者该如何开始。你甚至可能为此专门准备一个独立的部分：例如 Django, 就提供一个专门的首页面来欢迎和指导新晋贡献者。

django new contributors page

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

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

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

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

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

共享项目所有权

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

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

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

cookiecutter issue

  • 在项目中添加一个贡献者文件(CONTRIBUTORS) 或者作者文件(AUTHORS) 用于记录每一个参与贡献的人。

  • 如果社区有了一定的规模，那么 发送一封信或者发表一篇博客 感谢贡献者们。Rust的Rust周报和Hoodie的Shoutouts就是两个非常好的范例。

  • 给每个贡献者提交的通道。@felixge发现这样会使大家越发乐意斟酌他们的补丁，以及他甚至发现，在他没有工作的一段时间，项目依然有新的维护者进来。

  • 如果项目是托管在GitHub上，那么 将项目从你们的个人账号转移到一个组织，以及添加至少一个备份管理员。组织能让与其他人一起工作在同一个项目在变得更加容易。

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

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

解决冲突

在项目的早期，做决定是件蛮容易的事。几乎是想做什么就可以做什么。

随着项目的越加流行，会有更多的人对社区的决策开始感兴趣。即使社区没有大量的贡献者，如果项目拥有很多用户，就会发现大家的重点在决策上或者增加他们的issues。

在大多数情况下，如果你们培养了一个友好，颇受尊重的社区并公开记录你的过程，社区应该能够找到解决方案。但也有时候会遇到难以解决麻烦。

建立友好的氛围

当社区正在讨论一个很难的issue时，气氛会很激烈。人们可能会为此变得愤怒或者沮丧，甚至会遭到直接的人身攻击。

作为一名维护者的工作是不要让这种情况出现。即使这些你对话题有很强烈的观点，也要尽量站在一个主持者或者推动者的位置，而不是参与争吵以及推动自己的观点。如果有人不友好或者垄断话题，那么立即采取行动，以保持有礼貌和丰富的讨论。

一些人希望得到指导。撰写一个优势的示例。当然仍然可以表达失望、不高兴或者忧虑，但得心平气和。

保持你们的酷并不容易，但是展示领导力能促进社区健康的发展。互联网感谢你们。

将你们的README视为最高法则

README 不仅仅是一个简单的说明。它也是一个谈论目标、产品愿景和路线的地方。 如果人们过分专注于讨论特定功能的优点，那么你可能需要重新审视您的README，并谈论项目的更高的愿景。关注README也会使对话变得个人化，所以可以进行建设性的讨论。

专注过程，而不是结果

一些项目用投票的方式做重要决定。虽然看上去是明智的，投票强调的是得到一个”答案”，而不是倾听以及解决每个人的顾虑。

投票会变成政治，社区成员在做感兴趣的事或者表决一个明确的方法时会感到压力。不是每个人都参与了投票，可能在你们的社区中保持沉默的人占了多数，或者用户不知道投票这件事正在发生。

有时候，投票是必要的手段。尽你们所能强调“寻求共识”而不是共识本身。

在寻求共识的过程中，社区成员讨论主要问题，直到他们感到他们的意见已经得到充分的表达。当仅遗留下一些无关紧要的问题时，社区需要向前迈进。”寻求共识”不能确保社区能得到一个完美的答案。而是侧重聆听和讨论。

即使不确定是否采用寻求共识的方式，作为维护者，让大家知道他们正在受到关注。让其他人知道，以及承诺解决他们的问题，这在很大程度上减少了敏感情况的发生。然后，就去坚决的执行。

不要为了获得决议而急于做出决定。在做一个决议之前请确保每个人已经知道以及所有的信息以及公开。

将对话的重点聚焦于行动

讨论很重要，但是富有成效和没有效果的对话是有很大区别的。

鼓励讨论，只要它正积极地朝着解决问题的方向进行着。如果对话已经无法再进行下去，只有很少的人在参与或者大家正在讨论无关紧要的问题，这时候就该结束对话了。

允许这些对话进行下去不仅对解决问题没有帮助，而且不利于社区的健康发展。它释放了这样一个信号，表示允许或甚至鼓励这种类型的对话，它可能阻止人们提高或者解决未来的问题。

当你们或者其他人每提出一个观点时，请自问：”这如何使我们更接近一个决议？”

如果对话开始有解散的征兆，问团队：”我们下一步该做什么?”才能重新对话。

如果一个对话没有清晰的方向，没有明确的措施可以采取，或者合适的措施已经被使用，那么关掉issue并解释为什么关掉它。

挑战你们的智慧

上下文很重要。考虑谁参与讨论，以及他们如何代表社区的其他人。

社区中的每个人都为这个问题而烦恼，或者参与讨论了吗？或者只是一部分人感到困惑吗？不要仅关心活跃的声音，也请不要忘记考虑社区中保持沉默的人。

如果这个问题不代表社区的更广泛的需求，你们可能要承认只是少数人的担心。如果这是一个反复出现的issue，没有一个清晰的解决方案，那么指向他们以前讨论的话题。

找出社区中的决策者

通过一个态度端正和目标清晰的对话，很多困难都是可以解决的。即使在富有成效的对话中，对于如何进行的意见也可能存在差异。在这些情况下，确定一个人或一组人，可以作为决策者。

决策者可以是项目的主要维护者，或者是大家投票选出的一个小团体。理想情况下，在使用GOVERNANCE文件之前，其实已经确定了决策者和与之相关的事宜。

使用决策者应该是你们最后才能采取的手段。分离issues是一个你们社区成长和学习的机会。利用这些机会并精诚合作，尽量找出问题的解决方案。

社区是开源的❤️

健康，蓬勃的社区每周都会为开源付出大量辛勤的劳动。许多贡献者指出其他人在开源工作或不在开源工作的原因。通过学习如何建设性地利用这股力量，你们会帮助他人有一个难忘的开源体验。