建立成功的项目
你们已经启动了你们的项目，你们正在传播它，同时有人正在查看它。真棒！现在，你如何让他们坚持下去。
一个受欢迎的社区是对你们项目的未来和声誉的投资。如果你的项目才开始收到第一次贡献，那么你们需要尽早的给贡献者们一次积极的经历，以至于能让他们继续参与贡献。
让大家感到受欢迎
可以通过被@MikeMcQuaid称之为贡献者漏斗的方法思考你们项目的社区。
当你们建立了自己的社区，你需要考虑如何让那些处在漏斗上方的人（潜在用户）转移到漏斗下方（活跃的维护者）。你们的目标是减少贡献者们在每个阶段遇到的摩擦。当人们能够轻易的取得胜利时，他们会乐意去做更多事。
从你的文档开始：
- 让大家很容易使地用你的项目。 一份友好的 README以及清晰的代码示例将让大家很简单地开始你们的项目。
- 清楚的解释如何做贡献，使用你的CONTRIBUTING file以及持续更新issues。
好的文档能够邀请他人参与你们项目的互动。最终，一些人会开一个issue或者pull request。将这些互动视为机会，将他们转移到漏斗的下方。
- 当一些人选择了你们的项目，请对他们表示感谢！仅仅只是一次消极的经历就能让一些人不想再回来。
- 及时回应。如果你们一个月都没有回答他们的问题，他们可能早已忘记了你们的项目。
- 对你以后接受的所有贡献者持开放态度。 很多贡献者是从一份bug报告或者小的修复开始的。这里有很多为项目做贡献的方式。让大家选择他们喜欢的方式。
- 如果你不赞成一个贡献， 首先你需要对他们的想法表示感谢，同时 解释为什么它不适合项目，如果有必要的话你可以给出相关的文档链接。
为开源做贡献对一些人来说很简单，但对另外一些人可能就不是这样了。有很多人因为没有做正确的事而害怕叫喊，或者只是不适合。（。。。）通过允许贡献者参与一些对技术要求比底的工作（文档，web content markdown，etc），可以极大的减少你对这些情况的关注。
— @mikeal, "Growing a contributor base in modern open source"
多数开源贡献者是“临时贡献者”，因为他们只是偶尔参与项目贡献。一位临时贡献者可能没有充足的时间全程跟踪你的项目，所以你们的工作是能让他们很容易地参与贡献。
鼓励其他的贡献者也是对你们项目的一种投资。当你们授权大量的粉丝做他们感兴趣的工作时，你们的压力就少了很多。
记录一切
你是否参加过一个（技术）活动，你不认识在场的人，但是似乎每个人站在一个小组里像老朋友一样聊天？（。。。）现在想象下你想为一个开源项目做贡献，但是你不知道为什么或者这个是如何发生的。
— @janl, "Sustainable Open Source"
当你开始一个新项目，你会觉得保持工作的私有性是正常的。但是开源项目发开始于你在公共平台记录自己的工作进程。
当你门把事情记录下来，会有更多的人能够按照你们的方式参与每一步。你可能会得到意想不到的帮助。
书写东西不仅仅只是技术文档。任何时刻，你们有写一些东西或者私自讨论项目的冲动，请询问自己是否能将之公开。
保持项目透明的项目路线：你们期待什么类型的贡献者，如何审查贡献，或者你们为什么做某些决定。
如果你们注意到有多个用户遇到过同样的问题，那么你们应该将答案记录在README中。
对于经常遇到的问题，你们可以考虑发布你们的笔记或者相关的issue。在这种情况下得到的反馈将会令你们惊讶。
记录一切也适用于你们的工作。如果你正在进行大量的更新工作，请将其放入pull request并标记为正在进行（WIP）。这样，可以让其他人感觉参与过早期工作。
积极回应
一旦你推广项目，人们将会给你们反馈。他们可能会问项目是如何工作的，或者需要你们帮助开始项目。
当有人列出一条issue，提交一个pull request，或者询问项目的有关问题时，你们应该尽量回答他们。当你们快速地做出回应时，人们将感觉到他们参与了对话，以及他们将会更热情地参与。
如果你无法及时审查请求，请尽早确认，这样会有助于提高参与度。这里是@tdreyno在Middleman上如何回应一个pull request：
一份Mozilla研究发现 如果贡献者在48小时内收到代码审查，他们会有很大的可能返回以及重复贡献。
与你们项目有关的话题也可能发生在互联网的其它地方，例如Stack Overflow，Twitter，或者Reddit。你门可以在像这样的一些网站设置通知，这样当有人提及你们项目时可以收到提醒。
为你们的社区提供一个聚会的场所
有两个理由可以解释为什么要给社区提供一个聚会的场所。
第一个理由是为了他们。帮助人们相互认识。有着共同兴趣的人会想要一个可以聊天的地方。同时当信息是公开的而且是适宜的时候，任何人可以阅读过去的档案以至于能够快速的追赶以及参与。
第二个理由是为了你们。如果你们没有提供一个公共的场所来谈论你们的项目，他们可能会直接与你们联系。刚开始时，回复私有来信可能对你们来说很轻松。但是经过一段时间后，尤其是如果你们的项目变得流行的时候，你们就会感到累了。不要私下和人们谈论你们的项目，而是直接指明他们去指定的公共渠道。
公共交流和指明人们开一条issue一样简单，而不是直接发给你们发邮件或者在你们的博客发表评论。你们也可以为了方便人们谈论你们的项目设置一个邮件列表，或者创建一个Twitter账号，Slack，护着IRC渠道。或者尝试上述的所有方式。
Kubernetes kops sets aside office hours every other week to help community members:
Kubernetes kops 每隔一周抽出办公时间帮助社区成员：
Kops每隔一周都会留出时间为社区提供帮助和指导。Kops维护者已经同意留出时间专门与新手一起工作，帮助PRs，以及讨论新特性。
公开交流需要特别注意的异常有：1）安全的issues和2）敏感的行为准则。你们应该为大家提供一个私下报告这些issue的方式。如果你们不想使用自己的个人邮箱，那么就创建一个准用邮箱。
让社区成才
社区非常有能量。这种能量可能是祝福也可能是诅咒，这取决于你们如何执掌它。随着你们项目社区的成长，有办法帮助它成为一股有建设性的力量，而不是具有破坏性的。
不要容忍糟糕的角色
一些流行的项目将不可避免地回吸引来一些伤害它们的人。他们可能从一些没必要的争论开始，对一些细小的功能进行谬论，或者伤害他人。
对于那种类型的人你们必须采取零容忍的政策。如果发现较晚，那些消极的人将会社区中的其他人不舒服。他们可能会离开。
事实是，拥有一个支持性社区是关键。如果没有来自我的同事，互联网上一些友好的陌生人，以及聊天渠道IRC的帮助，我不可能做好这些工作。（。。。）不要太少。不要找麻烦。
— @karissa, "How to Run a FOSS Project"
定期对你们项目琐碎方便的辩论，使他人，包括你们不能把注意力集中于重要的任务上。新人如果看见这样的情景，他们是不会加入你们项目的。
当你们发现社区中有消极行为时，需要公然指出来。特别说明的是，要用坚定的语气解释他们的行为为什么是不可接受的。如果这种问题继续发生，你们有必要要求他们离开。你们的行为准则是为这些情景准备的建设性指南。
知道贡献者在哪里
随着你们项目的成长，好的文档只会变得越加重要。临时贡献者不可能对项目非常熟悉，通过阅读你们的文档他们能很快找到他们需要的。
在你们的CONTRIBUTING文件里，需要明确告诉新来的贡献者该如何开始。你们可能为了想要达到这个目的而准备一个专门的部分。
在你们的issue列表中，bugs标签需要适合不同类型的贡献者：例如，"first timers only", "good first bug", 或者 "documentation". 这些标签能够帮助新人快速浏览issues以及开始。
最后，使用你们的文档让人们在每一步都感到欢迎。
你们永远不会与登陆项目的大多数人互动。你们可能没有收到一些贡献，因为有些人感到害怕或者不知从和开始。即使是几个字也能阻止一些人沮丧地离开你们的项目。
我们想感谢你们使用Rubinius。这个项目是一个充满爱的劳动，我们希望所有用户查找bugs，取得性能上的提升，以及帮助完善文档。每一个贡献都是有意义的，所以感谢你们的参与。话虽如此，但我们还是要求你们遵守一些指南，这样我们就能够找到你们的issue。
分享你们项目的所有权
你们的领导者们将有不同的观点，因为这是所有健康社区都该做的！然而，你们会体会到粗暴鲁莽的做法不能得到大家的认同，反而谦虚低调的做法更容易让大家接受。
— @sarahsharp, "What makes a good community?"
当大家觉得拥有项目的所有权时，他们会乐意为项目做贡献。这并不意味着你们需要转变项目的愿景或接受你们不想要的贡献。但是你们越信任他们，他们就会越忠诚。
看你们是否能尽快地找出向社区分享所有权的方法。下面有些建议：
- 反对你们自己修复简单（非关键）的bugs。 相反，使用它们作为招募新贡献者的机会，或者指导想要参与贡献的人。开始时可能效果不是很理想，但经过一段时间你们会得到想要的结果。例如，@michaeljoseph要求一位贡献者提交一个pull request在一个Cookiecutter issue的下面，而不是自己修复它。
在项目中添加一个贡献者或者作者文件用于记录每一个参与贡献的人。
如果你们的社区有了一定的规模，那么发送一封信或者发表一篇博客感谢贡献者们。Rust的This Week in Rust和Hoodie的Shoutouts是两个非常好的示例。
给每个贡献者commit的通道。@felixge发现这样会使大家越发乐意斟酌他们的补丁，以及他甚至发现了他在一段时间没有工作的项目的新维护者。
如果你们的项目在GitHub上，那么将项目从你们的个人账号转移到一个组织，以及添加至少一个备份管理员。组织能让与其他人一起工作于同一个项目变得更加容易。
事实上很多项目只有一个或者两个做大量工作的维护者。随着你们的项目以及社区越来越大会更加容易得到帮助。
当你们不能总是发现一些人去回答问题时，你们可以释放一个信号增加其他人能接触到的机会。如果你们能尽早地开始，大家就能尽快地帮助。
你们最大的兴趣是招募喜欢你们项目以及能够做你们不能做的事的贡献者。你喜欢编码，但不喜欢回答issues？那么让社区中能做这件事的人去做。
— @gr2m, "Welcoming Communities"
解决冲突
在你们项目的早期，做主要的决定是件容易的事。你们想做什么就可以做什么。
随着你们的项目越加流行，会有更多的人对你们的决定有兴趣。即使你们的社区没有大量的贡献者，如果你们的项目有很多用户，你们会发现大家的重点在决策上或者增加他们的issues。
在大多数情况下，如果你们培养了一个友好，尊重的社区并公开记录你的过程，你们的社区应该能够找到解决方案。但有时候你们遇到一个issue，有点难以解决。
建立友好的氛围
当你们的社区正在讨论一个很难的issue时，气氛会很激烈。人们可能会变得愤怒或者沮丧，以及发泄在其他人或者你们身上。
作为一名维护者你们的工作是不要让这种情况出现。即使你们对话题有很强烈的观点，也要尽量站在一个主持者或者推动者的位置，而不是参与争吵以及推动自己的观点。如果有人不友好或者垄断话题，那么立即采取行动以保持有礼貌以及丰富的讨论。
作为一名维护者，尊重你们的贡献者非常重要。他们经常处理一些你们描述亲切的事情。
— @kennethreitz, "Be Cordial or Be on Your Way"
一些人希望你们指导他们。编写一个好的示例。你们仍然可以表达失望，不高兴或者忧虑，但得心平气和。
保持你们的酷并不容易，但是展示领导能力能促进健康的社区。互联网感谢你们。
将你们的README视为宪法
你们的README不仅仅是一组指令。它也是一个谈论你们目标，产品愿景和路线的地方。
如果人们过分专注于辩论特定功能的优点，它可能有助于重新审视您的README，并谈论你们的项目的更高的愿景。关注你们的README也会使对话变得个人化，所以你们可以进行建设性的讨论。
专注过程，而不是结果
一些项目用投票的方式做重要决定。虽然看上去是明智的，投票强调的是得到一个“答案”，而不是倾听以及解决每个人的顾虑。
投票会变成政治，社区成员在做感兴趣的事或者表决一个明确的方法时会感到压力。不是每个人都参与了投票，可能在你们的社区中保持沉默的人占了多数，或者用户不知道投票这件事正在发生。
有时候，投票是必要的手段。尽你们所能强调"寻求共识"而不是共识。
在寻求共识的过程中，社区成员讨论主要问题，直到他们感到他们已经得到充分的意见。当仅遗留下一些无关紧要的问题时，社区需要向前迈进。“寻求共识”不能确保社区能得到一个完美的答案。而是侧重聆听和讨论。
Atom Issues不存在投票系统的部分原因是因为Atom团队在所有情况下都不会遵循投票系统。有时我们必须选择我们认为是对的事，即使它不流行。（。。。）我能通过社区的反馈知道我能够提供什么以及做什么样的工作。
— @lee-dohm on Atom's decisionmaking process
即使你们不确定是否采用寻求共识的方式，作为维护者，让大家知道你们正在关注他们。让其他人知道，以及承诺解决他们的问题，这在很大程度上减少了敏感情况的发送。然后，按你说的去做。
不要为了获得决议而急于做出决定。在做一个决议之前请确保每个人已经知道以及所有的信息以及公开。
将对话的重点聚焦于行动
讨论很重要，但是富有成效和没有效果的对话时有区别的。
鼓励讨论，只要它正积极地朝着解决问题的方向进行着。如果对话已经无法再进行下去，只有很少的人在参与或者大家正在讨论无关紧要的问题，这时候就该结束对话了。
允许这些对话进行下去不仅对解决问题没有帮助，而且不利于社区的健康发展。它释放了这样一个信号，表示允许或甚至鼓励这种类型的对话，它可能阻止人们提高或者解决未来的问题。
当你们或者其他人每提出一个观点时，请自问：“这如何使我们更接近一个决议？”
如果对话开始有解散的征兆，问团队：“我们下一步该做什么?”才能重新对话。
如果一个对话没有清晰的方向，没有明确的措施可以采取，或者合适的措施已经被使用，那么关掉issue并解释为什么关掉它。
指导一件事朝着正确的方向发展是一门艺术。它对阻止人们浪费时间或者要求他们发表有建设性的看法没有作用。（。。。）反而，你们必须为接下来的进展给出条件：给大家一个路线，跟随一个可以得到你们想要的结果的途径，这样就不像是些无用的口头行为。
— @kfogel, Producing OSS
挑战你们的智慧
上下文很重要。考虑谁参与讨论，以及他们如何代表社区的其他人。
社区中的每个人都为这个问题而烦恼，或者参与讨论了吗？或者只是一部分人感到困惑吗？不要仅关心活跃的声音，也请不要忘记考虑社区中保持沉默的人。
如果这个问题不代表社区的更广泛的需求，你们可能要承认只是少数人的担心。如果这是一个反复出现的issue，没有一个清晰的解决方案，那么指向他们以前讨论的话题。
找出社区中的决策者
通过一个态度端正和目标清晰的对话，很多困难都是可以解决的。即使在富有成效的对话中，对于如何进行的意见也可能存在差异。在这些情况下，确定一个人或一组人，可以作为决策者。
决策者可以是项目的主要维护者，或者是大家投票选出的一个小团体。理想情况下，在你们使用GOVERNANCE文件之前，你们已经确定了决胜者和与之相关的事宜。
使用决策者应该是你们最后才能采取的手段。分离issues是一个你们社区成长和学习的机会。利用这些机会以及协同合作，尽量找出解决方案。
社区是开源的❤️
健康，蓬勃的社区每周都会为开源付出大量辛勤的劳动。许多贡献者指出其他人在开源工作或不在开源工作的原因。通过学习如何建设性地利用这个权力，你们会帮助他人有一个难忘的开源体验。## 建立成功的项目
你们已经启动了你们的项目，你们正在传播它，同时有人正在查看它。真棒！现在，你如何让他们坚持下去。
一个受欢迎的社区是对你们项目的未来和声誉的投资。如果你的项目才开始收到第一次贡献，那么你们需要尽早的给贡献者们一次积极的经历，以至于能让他们继续参与贡献。
让大家感到受欢迎
可以通过被@MikeMcQuaid称之为贡献者漏斗的方法思考你们项目的社区。
[图片上传失败...(image-677985-1510064984150)]
当你们建立了自己的社区，你需要考虑如何让那些处在漏斗上方的人（潜在用户）转移到漏斗下方（活跃的维护者）。你们的目标是减少贡献者们在每个阶段遇到的摩擦。当人们能够轻易的取得胜利时，他们会乐意去做更多事。
从你的文档开始：
- 让大家很容易使地用你的项目。 一份友好的 README以及清晰的代码示例将让大家很简单地开始你们的项目。
- 清楚的解释如何做贡献，使用你的CONTRIBUTING file以及持续更新issues。
好的文档能够邀请他人参与你们项目的互动。最终，一些人会开一个issue或者pull request。将这些互动视为机会，将他们转移到漏斗的下方。
- 当一些人选择了你们的项目，请对他们表示感谢！仅仅只是一次消极的经历就能让一些人不想再回来。
- 及时回应。如果你们一个月都没有回答他们的问题，他们可能早已忘记了你们的项目。
- 对你以后接受的所有贡献者持开放态度。 很多贡献者是从一份bug报告或者小的修复开始的。这里有很多为项目做贡献的方式。让大家选择他们喜欢的方式。
- 如果你不赞成一个贡献， 首先你需要对他们的想法表示感谢，同时 解释为什么它不适合项目，如果有必要的话你可以给出相关的文档链接。
为开源做贡献对一些人来说很简单，但对另外一些人可能就不是这样了。有很多人因为没有做正确的事而害怕叫喊，或者只是不适合。（。。。）通过允许贡献者参与一些对技术要求比底的工作（文档，web content markdown，etc），可以极大的减少你对这些情况的关注。
— @mikeal, "Growing a contributor base in modern open source"
多数开源贡献者是“临时贡献者”，因为他们只是偶尔参与项目贡献。一位临时贡献者可能没有充足的时间全程跟踪你的项目，所以你们的工作是能让他们很容易地参与贡献。
鼓励其他的贡献者也是对你们项目的一种投资。当你们授权大量的粉丝做他们感兴趣的工作时，你们的压力就少了很多。
记录一切
你是否参加过一个（技术）活动，你不认识在场的人，但是似乎每个人站在一个小组里像老朋友一样聊天？（。。。）现在想象下你想为一个开源项目做贡献，但是你不知道为什么或者这个是如何发生的。
— @janl, "Sustainable Open Source"
当你开始一个新项目，你会觉得保持工作的私有性是正常的。但是开源项目发开始于你在公共平台记录自己的工作进程。
当你门把事情记录下来，会有更多的人能够按照你们的方式参与每一步。你可能会得到意想不到的帮助。
书写东西不仅仅只是技术文档。任何时刻，你们有写一些东西或者私自讨论项目的冲动，请询问自己是否能将之公开。
保持项目透明的项目路线：你们期待什么类型的贡献者，如何审查贡献，或者你们为什么做某些决定。
如果你们注意到有多个用户遇到过同样的问题，那么你们应该将答案记录在README中。
对于经常遇到的问题，你们可以考虑发布你们的笔记或者相关的issue。在这种情况下得到的反馈将会令你们惊讶。
记录一切也适用于你们的工作。如果你正在进行大量的更新工作，请将其放入pull request并标记为正在进行（WIP）。这样，可以让其他人感觉参与过早期工作。
积极回应
一旦你推广项目，人们将会给你们反馈。他们可能会问项目是如何工作的，或者需要你们帮助开始项目。
当有人列出一条issue，提交一个pull request，或者询问项目的有关问题时，你们应该尽量回答他们。当你们快速地做出回应时，人们将感觉到他们参与了对话，以及他们将会更热情地参与。
如果你无法及时审查请求，请尽早确认，这样会有助于提高参与度。这里是@tdreyno在Middleman上如何回应一个pull request：
一份Mozilla研究发现 如果贡献者在48小时内收到代码审查，他们会有很大的可能返回以及重复贡献。
与你们项目有关的话题也可能发生在互联网的其它地方，例如Stack Overflow，Twitter，或者Reddit。你门可以在像这样的一些网站设置通知，这样当有人提及你们项目时可以收到提醒。
为你们的社区提供一个聚会的场所
有两个理由可以解释为什么要给社区提供一个聚会的场所。
第一个理由是为了他们。帮助人们相互认识。有着共同兴趣的人会想要一个可以聊天的地方。同时当信息是公开的而且是适宜的时候，任何人可以阅读过去的档案以至于能够快速的追赶以及参与。
第二个理由是为了你们。如果你们没有提供一个公共的场所来谈论你们的项目，他们可能会直接与你们联系。刚开始时，回复私有来信可能对你们来说很轻松。但是经过一段时间后，尤其是如果你们的项目变得流行的时候，你们就会感到累了。不要私下和人们谈论你们的项目，而是直接指明他们去指定的公共渠道。
公共交流和指明人们开一条issue一样简单，而不是直接发给你们发邮件或者在你们的博客发表评论。你们也可以为了方便人们谈论你们的项目设置一个邮件列表，或者创建一个Twitter账号，Slack，护着IRC渠道。或者尝试上述的所有方式。
Kubernetes kops sets aside office hours every other week to help community members:
Kubernetes kops 每隔一周抽出办公时间帮助社区成员：
Kops每隔一周都会留出时间为社区提供帮助和指导。Kops维护者已经同意留出时间专门与新手一起工作，帮助PRs，以及讨论新特性。
公开交流需要特别注意的异常有：1）安全的issues和2）敏感的行为准则。你们应该为大家提供一个私下报告这些issue的方式。如果你们不想使用自己的个人邮箱，那么就创建一个准用邮箱。
让社区成才
社区非常有能量。这种能量可能是祝福也可能是诅咒，这取决于你们如何执掌它。随着你们项目社区的成长，有办法帮助它成为一股有建设性的力量，而不是具有破坏性的。
不要容忍糟糕的角色
一些流行的项目将不可避免地回吸引来一些伤害它们的人。他们可能从一些没必要的争论开始，对一些细小的功能进行谬论，或者伤害他人。
对于那种类型的人你们必须采取零容忍的政策。如果发现较晚，那些消极的人将会社区中的其他人不舒服。他们可能会离开。
事实是，拥有一个支持性社区是关键。如果没有来自我的同事，互联网上一些友好的陌生人，以及聊天渠道IRC的帮助，我不可能做好这些工作。（。。。）不要太少。不要找麻烦。
— @karissa, "How to Run a FOSS Project"
定期对你们项目琐碎方便的辩论，使他人，包括你们不能把注意力集中于重要的任务上。新人如果看见这样的情景，他们是不会加入你们项目的。
当你们发现社区中有消极行为时，需要公然指出来。特别说明的是，要用坚定的语气解释他们的行为为什么是不可接受的。如果这种问题继续发生，你们有必要要求他们离开。你们的行为准则是为这些情景准备的建设性指南。
知道贡献者在哪里
随着你们项目的成长，好的文档只会变得越加重要。临时贡献者不可能对项目非常熟悉，通过阅读你们的文档他们能很快找到他们需要的。
在你们的CONTRIBUTING文件里，需要明确告诉新来的贡献者该如何开始。你们可能为了想要达到这个目的而准备一个专门的部分。
在你们的issue列表中，bugs标签需要适合不同类型的贡献者：例如，"first timers only", "good first bug", 或者 "documentation". 这些标签能够帮助新人快速浏览issues以及开始。
最后，使用你们的文档让人们在每一步都感到欢迎。
你们永远不会与登陆项目的大多数人互动。你们可能没有收到一些贡献，因为有些人感到害怕或者不知从和开始。即使是几个字也能阻止一些人沮丧地离开你们的项目。
我们想感谢你们使用Rubinius。这个项目是一个充满爱的劳动，我们希望所有用户查找bugs，取得性能上的提升，以及帮助完善文档。每一个贡献都是有意义的，所以感谢你们的参与。话虽如此，但我们还是要求你们遵守一些指南，这样我们就能够找到你们的issue。
分享你们项目的所有权
你们的领导者们将有不同的观点，因为这是所有健康社区都该做的！然而，你们会体会到粗暴鲁莽的做法不能得到大家的认同，反而谦虚低调的做法更容易让大家接受。
— @sarahsharp, "What makes a good community?"
当大家觉得拥有项目的所有权时，他们会乐意为项目做贡献。这并不意味着你们需要转变项目的愿景或接受你们不想要的贡献。但是你们越信任他们，他们就会越忠诚。
看你们是否能尽快地找出向社区分享所有权的方法。下面有些建议：
- 反对你们自己修复简单（非关键）的bugs。 相反，使用它们作为招募新贡献者的机会，或者指导想要参与贡献的人。开始时可能效果不是很理想，但经过一段时间你们会得到想要的结果。例如，@michaeljoseph要求一位贡献者提交一个pull request在一个Cookiecutter issue的下面，而不是自己修复它。
在项目中添加一个贡献者或者作者文件用于记录每一个参与贡献的人。
如果你们的社区有了一定的规模，那么发送一封信或者发表一篇博客感谢贡献者们。Rust的This Week in Rust和Hoodie的Shoutouts是两个非常好的示例。
给每个贡献者commit的通道。@felixge发现这样会使大家越发乐意斟酌他们的补丁，以及他甚至发现了他在一段时间没有工作的项目的新维护者。
如果你们的项目在GitHub上，那么将项目从你们的个人账号转移到一个组织，以及添加至少一个备份管理员。组织能让与其他人一起工作于同一个项目变得更加容易。
事实上很多项目只有一个或者两个做大量工作的维护者。随着你们的项目以及社区越来越大会更加容易得到帮助。
当你们不能总是发现一些人去回答问题时，你们可以释放一个信号增加其他人能接触到的机会。如果你们能尽早地开始，大家就能尽快地帮助。
你们最大的兴趣是招募喜欢你们项目以及能够做你们不能做的事的贡献者。你喜欢编码，但不喜欢回答issues？那么让社区中能做这件事的人去做。
— @gr2m, "Welcoming Communities"
解决冲突
在你们项目的早期，做主要的决定是件容易的事。你们想做什么就可以做什么。
随着你们的项目越加流行，会有更多的人对你们的决定有兴趣。即使你们的社区没有大量的贡献者，如果你们的项目有很多用户，你们会发现大家的重点在决策上或者增加他们的issues。
在大多数情况下，如果你们培养了一个友好，尊重的社区并公开记录你的过程，你们的社区应该能够找到解决方案。但有时候你们遇到一个issue，有点难以解决。
建立友好的氛围
当你们的社区正在讨论一个很难的issue时，气氛会很激烈。人们可能会变得愤怒或者沮丧，以及发泄在其他人或者你们身上。
作为一名维护者你们的工作是不要让这种情况出现。即使你们对话题有很强烈的观点，也要尽量站在一个主持者或者推动者的位置，而不是参与争吵以及推动自己的观点。如果有人不友好或者垄断话题，那么立即采取行动以保持有礼貌以及丰富的讨论。
作为一名维护者，尊重你们的贡献者非常重要。他们经常处理一些你们描述亲切的事情。
— @kennethreitz, "Be Cordial or Be on Your Way"
一些人希望你们指导他们。编写一个好的示例。你们仍然可以表达失望，不高兴或者忧虑，但得心平气和。
保持你们的酷并不容易，但是展示领导能力能促进健康的社区。互联网感谢你们。
将你们的README视为宪法
你们的README不仅仅是一组指令。它也是一个谈论你们目标，产品愿景和路线的地方。
如果人们过分专注于辩论特定功能的优点，它可能有助于重新审视您的README，并谈论你们的项目的更高的愿景。关注你们的README也会使对话变得个人化，所以你们可以进行建设性的讨论。
专注过程，而不是结果
一些项目用投票的方式做重要决定。虽然看上去是明智的，投票强调的是得到一个“答案”，而不是倾听以及解决每个人的顾虑。
投票会变成政治，社区成员在做感兴趣的事或者表决一个明确的方法时会感到压力。不是每个人都参与了投票，可能在你们的社区中保持沉默的人占了多数，或者用户不知道投票这件事正在发生。
有时候，投票是必要的手段。尽你们所能强调"寻求共识"而不是共识。
在寻求共识的过程中，社区成员讨论主要问题，直到他们感到他们已经得到充分的意见。当仅遗留下一些无关紧要的问题时，社区需要向前迈进。“寻求共识”不能确保社区能得到一个完美的答案。而是侧重聆听和讨论。
Atom Issues不存在投票系统的部分原因是因为Atom团队在所有情况下都不会遵循投票系统。有时我们必须选择我们认为是对的事，即使它不流行。（。。。）我能通过社区的反馈知道我能够提供什么以及做什么样的工作。
— @lee-dohm on Atom's decisionmaking process
即使你们不确定是否采用寻求共识的方式，作为维护者，让大家知道你们正在关注他们。让其他人知道，以及承诺解决他们的问题，这在很大程度上减少了敏感情况的发送。然后，按你说的去做。
不要为了获得决议而急于做出决定。在做一个决议之前请确保每个人已经知道以及所有的信息以及公开。
将对话的重点聚焦于行动
讨论很重要，但是富有成效和没有效果的对话时有区别的。
鼓励讨论，只要它正积极地朝着解决问题的方向进行着。如果对话已经无法再进行下去，只有很少的人在参与或者大家正在讨论无关紧要的问题，这时候就该结束对话了。
允许这些对话进行下去不仅对解决问题没有帮助，而且不利于社区的健康发展。它释放了这样一个信号，表示允许或甚至鼓励这种类型的对话，它可能阻止人们提高或者解决未来的问题。
当你们或者其他人每提出一个观点时，请自问：“这如何使我们更接近一个决议？”
如果对话开始有解散的征兆，问团队：“我们下一步该做什么?”才能重新对话。
如果一个对话没有清晰的方向，没有明确的措施可以采取，或者合适的措施已经被使用，那么关掉issue并解释为什么关掉它。
指导一件事朝着正确的方向发展是一门艺术。它对阻止人们浪费时间或者要求他们发表有建设性的看法没有作用。（。。。）反而，你们必须为接下来的进展给出条件：给大家一个路线，跟随一个可以得到你们想要的结果的途径，这样就不像是些无用的口头行为。
— @kfogel, Producing OSS
挑战你们的智慧
上下文很重要。考虑谁参与讨论，以及他们如何代表社区的其他人。
社区中的每个人都为这个问题而烦恼，或者参与讨论了吗？或者只是一部分人感到困惑吗？不要仅关心活跃的声音，也请不要忘记考虑社区中保持沉默的人。
如果这个问题不代表社区的更广泛的需求，你们可能要承认只是少数人的担心。如果这是一个反复出现的issue，没有一个清晰的解决方案，那么指向他们以前讨论的话题。
找出社区中的决策者
通过一个态度端正和目标清晰的对话，很多困难都是可以解决的。即使在富有成效的对话中，对于如何进行的意见也可能存在差异。在这些情况下，确定一个人或一组人，可以作为决策者。
决策者可以是项目的主要维护者，或者是大家投票选出的一个小团体。理想情况下，在你们使用GOVERNANCE文件之前，你们已经确定了决胜者和与之相关的事宜。
使用决策者应该是你们最后才能采取的手段。分离issues是一个你们社区成长和学习的机会。利用这些机会以及协同合作，尽量找出解决方案。
社区是开源的❤️
健康，蓬勃的社区每周都会为开源付出大量辛勤的劳动。许多贡献者指出其他人在开源工作或不在开源工作的原因。通过学习如何建设性地利用这个权力，你们会帮助他人有一个难忘的开源体验。
