从用户到贡献者#
每个开源项目都始于代码和一位或多位开发者。而将项目转变为社区的，正是围绕这些代码进行互动的人们。无论项目处于何种成熟阶段，确保其成功最重要的事情之一就是鼓励并维持与用户及贡献者的互动。
当项目用户主动与开发者互动时，请将这份贡献视为挚友馈赠的馈赠。对方本可将时间用于其他事务，却选择投入你的项目——无论是提交错误报告、功能建议还是拉取请求，这些初次互动都将直接影响他们对项目及社区形成积极或消极的印象。
以下是营造友好文化的几个步骤，将用户互动视为珍贵的馈赠。
接受馈赠#
如果用户因为你项目中的某些内容不如预期那样工作而感到沮丧，积极回应用户参与可能会很困难。在这种时候，请记住这个人正在努力告诉你他们的问题。想想你善意的阿姨给你买便宜仿制积木而不期望的乐高套装的那次；当有人第一次参与你的项目时，你只有一次机会留下良好的第一印象。
首先，感谢对方的贡献并予以肯定。很多时候，当人们带着不满情绪来到你的项目时，他们最需要的首先是确认问题并非由自己引起——确认这个项目确实存在使用难度过高的问题。帮助他们解决当前遇到的具体障碍，就能将这些批评者转化为项目的支持者。
提供具体可行的有效反馈#
对于新贡献者的反馈，只有在具备可操作性时才有价值——也就是说，贡献者能够根据你提供的建议采取具体行动。
当有人提出问题时，你可能需要获取更多信息才能解答。例如在审查包含不符合项目编码规范的拉取请求时，你会希望贡献者对其提交内容进行修改。在提供反馈或提出要求时，关键要以新手的视角审视项目。最令人沮丧的莫过于得到一个完全晦涩的答复——"只要调整 dollygagger 就行！"——然后挠着头问："这到底该怎么做？"
审查代码时，切勿预设对方对编程语言、项目本身乃至 GitHub 上如何更新拉取请求具有高度熟练度。如果你的项目基于 Kubernetes 运行，不要默认认为对接人员是 Kubernetes 集群管理员或熟悉 Kubernetes 内部机制。
如有疑问，不妨先询问一些基础性问题。但若需指导他人修改配置文件中的选项，务必说明文件位置及格式规范。
为积极参与的用户提供良好体验#
当有人参与你的项目时，请全力确保他们在互动后获得良好体验。这不仅关乎当前接触的对象，更会影响无数潜在观察者——比如半年后查阅 StackOverflow 问题的读者，或是社区论坛的旁观者。当这些用户见证他人的愉快经历时，也会对项目产生更多好感。
以人为本胜过流程至上#
大型开发团队依赖流程保障高效运作。无论是通过缺陷跟踪系统的工作流管理来验证变更能否及何时合并，还是对每个拉取请求执行冒烟测试，他们构建层层工具链，帮助开发者在处理海量变更时保持理智。
对项目活跃成员而言，这类基础设施极具价值！但对初来乍到的新手来说，这一切都显得神秘莫测。
作为注重社区建设的开发者，你需要特别关照项目新人。若他们的首次 PR 未通过冒烟测试，多花一分钟解释测试内容及其重要性，远比干巴巴地评论"CI 失败"或"空格问题"更有意义。
简而言之，要将贡献者本人看得比其贡献更为重要。
建立人际关系#
最后，当有新贡献者出现在你的项目里时，请记住你正面临一个与项目使用者互动的宝贵机会，去了解他们如何发现项目、喜欢和不喜欢哪些方面等等。这些信息价值不菲；直接接触用户是开源软件开发相较于专有软件开发的一大优势。好好利用它吧！
这些对话还会带来另一个副产品：对于那些可能曾将你的软件视为无名企业产品的用户来说，你正在为项目赋予姓名和面孔。简而言之，你正在建立一种关系。
试想初到新学校、新社区或新公司时的情景。让你产生归属感的，正是与几分钟前还是陌生人的那种人际联结。这种关系虽微小且初生，却能让对方重返你的项目，从使用者转变为社区参与者。
帮助开发者参与社区项目#
经验丰富的专业软件开发者在开始参与社区软件项目时，最常见的问题之一是不愿使用邮件列表等公共沟通渠道。理解其中的原因并帮助开发者融入社区，是与你所合作的社区建立成功且富有成效关系的关键。
造成这种犹豫的常见原因包括：对英语写作能力缺乏信心、自认为技术水平不足、对公开同行评审感到紧张，以及将社区互动视为"沟通"或"营销"——他们认为这不属于本职工作范畴。
缺乏信心#
传统上，大学工程类课程并不十分重视清晰的书面沟通能力培养。这可能导致专业软件开发人员缺乏写作技能锻炼。而在开源项目中，书面交流对于与社区团队进行异步协作至关重要：无论是通过博客宣传工作成果、编写功能提案文档，还是在邮件列表中讨论路线图项目的利弊。
此外，虽然大多数工程师都推崇逻辑严谨，但修辞学和辩论技巧通常不属于工程学课程范畴。最终结果是，当需要撰写工作报告或在公共论坛提问时，他们往往会犹豫不决。
对于非英语母语者而言，英语水平不足导致的信心缺失也可能成为阻碍邮件列表参与的障碍。
我记得曾共事过一位工程师，他对撰写我们讨论过的问题邮件显得十分犹豫，即便我们都认为有必要与社区进行探讨。当他终于动笔时，他似乎又对社区成员的回复或质疑置若罔闻。后来与他谈及此事，才发现他对于在公开存档的邮件列表中进行书面讨论感到不适——他担心任何失当之举或礼节疏忽都会遭到社区的严厉指摘。
解决这个问题的最佳方式是循序渐进。
一个很好的开端是让工程师们参与解答问题。有效的方法是在邮件列表中公开将问题转给某位工程师，同时肯定他们在该领域的专长。"Tammy 对 RLE 算法了如指掌。Tammy，能否请你回答 Franz 的问题？"
这有点像绝地武士的心理技巧，能达成三个目的。首先，当问题面向群体时，个人很容易忽略，但直接向某人提问时很少有人会不回答——这是人性使然。
其次，肯定工程师的技能可以强化他们在相关领域被视为专家的认知，从而增强他们回答问题的信心。第三，通过明确指定具备特定技能的个人工程师，你让外部人士得以窥见公司内部的情况。你让团队显得人性化——这是一群各有所长、各有所短的个体，而非面目模糊的"Acme 公司开发组"整体。
另一件值得做的事是让开发者养成定期写作的习惯。仅仅站在一旁要求每个人都开博客是不够的。如果写作令人畏惧，那么更频繁地练习会让它变得不那么可怕。实现这一点有很多方法——奖励博客文章、要求定期提交状态报告、在关闭工单时撰写更详细的提交信息或评论，或是安排时间举办创意写作研讨会。目标不是把开发者变成小说家，而是让你的团队养成写作的习惯。
最后，你应该对工程师进行基本的网络礼仪和邮件写作培训。开发者对待写邮件应该像对待代码补丁一样认真。当你生成一个补丁时，通常在发送前最后一步是检查它，确保没有包含任何愚蠢的错误。将同样的习惯应用到邮件中，就能发现措辞不当或模糊的地方，从而写出更好的邮件。
同行评审的严苛考验#
对于许多软件工程师来说，写作本身已令人望而生畏，而将自己的作品交给一群不太熟悉的人进行同行评审更是令人紧张不已。
根据我的经验，系统性同行评审在软件行业并非惯例。部分管理者将同行评审视为额外负担——毕竟开发者是因胜任工作才被聘用，没人喜欢被"社区"反复质疑。当工程师积累到一定经验后，同行评审对我们行业的专业软件开发人员而言，更像是例外而非常态。
在社区项目中，同行评审是常规要求。事实上，这是区分成功社区项目与普通项目的关键最佳实践之一。社区开发者期望在功能开发前就能参与讨论，并有机会提出更优的实现方案。他们要求新贡献者提交可供审查的补丁——这是新人获得提交者或维护者身份前建立信任的必经之路。
让专业软件团队成员适应同行评审的最佳方式，是制定公司规定禁止"首日提交权限"——即禁止员工入职当天就获得开源项目代码库提交权限的做法。对于企业赞助的项目，新开发人员提交的代码应当与外部贡献者一样经过完整的评审流程。
对于企业参与社区项目的贡献，这意味着要避免内部分支和"守门人"式的项目结构——即由一两名开发人员负责提交团队其他成员的工作成果。
开发者在向内部提交代码的同时，也应将工作成果提交至上游社区。对于那些仅适用于内部分支的变更，仍需在私有代码库中进行同行评审。随着基于 git 的代码库成为软件开发新常态，这对企业而言已不像过去那样具有挑战性，但让团队顺利转型为成功的社区贡献者仍是必要之举。
让新晋开发者经历这段评审期具有重要意义——最重要的是这能证明企业员工与非员工贡献者同样需要经过项目验证，同时也为新员工提供了熟悉项目编码规范、沟通惯例的适应期，并在此期间向整个社区进行自我介绍。这一过程对于资深社区开发者指导新人而言至关重要。
沟通和营销不是我的职责#
在某些开发者看来，将项目计划发布到邮件列表等同于"发布公告"，需要做大量准备工作。这些开发者把在邮件列表上与社区用户交流视为"支持"或"沟通"行为，而非项目职能的核心组成部分。
如果开发者将"给邮件列表发邮件"框定为"发布公告"，这在他们脑海中就被归入"市场宣传"范畴。曾有开发者告诉我，她没时间给邮件列表发邮件，因为还有"真正的工作"要做。在她看来，"处理社区事务"是我作为社区管理者的职责。她认为社区信息传递属于支持性工作，并非其本职范畴。
《Cluetrain 宣言》的作者们提出，在当今互联互通的世界里，营销部门已不复存在——公司员工与外部人员的每次互动，都是赢得或丧失声誉的机会。
在自由软件开发团队中，这一点尤为显著。项目传播没有专门的营销部门。要想高效工作，就必须与同行交流，因此对于从事社区项目的人员而言，对外沟通的制度性障碍必须消除。
即使在那些对开源沟通有明确期望的组织中，工程师们也可能会自我设限。他们可能会花上数小时打磨提案后才提交。这在社区项目中适得其反，因为初始提案越是精致，投入的情感成本就越高。精雕细琢的提案也更难被评审和修改，因为它们看起来已经完成了。更好的做法是发布粗糙的早期草案，让作者有机会整合早期反馈。
向团队证明"早发布、常发布"优势的最佳方式是以身作则。作为团队负责人或管理者，你可以通过尽早公开团队计划并频繁迭代来引领示范。实施时，要向团队明确指出由此带来的益处。打破这种心理障碍需要时间，但通过明确表示不追求完美、奖励早期信息发布并鼓励反馈，你的团队很快会意识到外部参与者是协作伙伴，而非观众。
另一个有用的技巧是要求工程师将任务分解为更小的部分，这样即使他们坚持等到第一部分达到高标准，信息也能更快地传播出去，从而让反馈可以指导后续阶段的工作。
阻碍早期沟通目标实现的是人们普遍渴望的"重磅发布"心态。企业往往希望将产品发布和公告与大型贸易展会同步。这可能导致公司要求工程师在内部秘密开发重要功能，唯恐提前曝光会破坏惊喜效果。另一种做法是在项目启动时就宣布，而非等到有成果展示时——但这会导致产品上市前经历漫长等待，引发主流媒体的不耐烦和负面报道。
可以将工程师讨论重大功能的设计决策和实现细节的邮件列表，与通过新闻稿和营销活动来宣传公告区分开来。这样当最终公告发布时，社区不会感到完全意外，你也不必为自己数月来秘密工作、突然提交大量难以审查的代码而被迫辩解。
建立关系#
这里的关键在于，要让你的开发者感受到与公司外部工作者的联系。这同样需要外部人员也能与他们建立联结。通过揭开团队的面纱，展示成员们的技能与工作重点，你正在为项目参与者创造相互欣赏的契机，让他们能基于功能与补丁本身的价值自在交流。
当你达成这一境界时，便已赢得这场战役。团队中的开发者会将其他项目贡献者视为同行、同事，乃至朋友。