开源项目要受到开发者的欢迎，我们应为项目的成功做好一些必要准备：
第一点：我们需要让开发者感受到被欢迎
从开发者漏斗的视角，我们考虑一下处于漏斗顶部的人（潜在用户）理论上如何到达底部（活跃的维护者）。
要实现漏斗的转换，首先我们应先从文档开始：
● 让开发者轻松使用开源项目。Readme和清晰的代码示例能帮助Ta们更容易的加入项目贡献。
● 清楚地解释如何贡献，有明确的项目贡献说明。
● 第一个issue的良好开端。为了帮助新的贡献者上手，考虑明确标记足够简单的问题，让入门者可以解决，获得成就感。项目要解决的问题应由浅入深。
● 问题列表中，标记适合不同类型贡献者的问题。（一些好话有助于使人们感到宾至如归，降低流失）
GitHub's Open Source Survey显示不完整、令人费解的文档是开源用户面临的最大困难：
好的文档有助于驱动开发者与开源项目互动。
● 当有人新登陆你的项目时，感谢Ta们对于开源项目的关注!一次负面的经历就能让一个开发者放弃参与开源项目。（致谢：礼貌很重要）
● 及时响应。如果长时间，如一个月内，没有回复开发者的问题，Ta们很可能已经忘记了你的项目。（及时响应：减少用户流失）
● 对接受的贡献类型持开放态度。许多贡献者从小问题小修改开始。（开放心态）
● 如果您认同开发者的修改，感谢Ta们的想法，并解释为什么该修改不适合项目的范围。（问题闭环：争取用户理解）
● Readme不仅仅是一组说明，更是展示目标、产品愿景和路标的地方。如果用户过于关注某个特定特性的优点，那么重温一下Readme并探讨项目的远景可能会对其有所帮助。
第二点：记录好一切
被记录的应不仅仅只有技术文档：
● 帮助开发者透明地了解项目的路标、您正在寻找的贡献类型、如何审查贡献等。（路标规划）
● 如果多个用户遇到同一问题，请在Readme中进行说明澄清。（在Readme中描述常见问题及解决方案）
● 考虑在会议中针对相关问题上发布用户沟通的笔记和观点或结论。从这种透明度水平中得到的反馈可能会让使我们获得意想不到的效果。（展示每一次和用户沟通的笔记和观点或结论）
● 记录一切也适用于你所做的工作。如果我们对项目进行实质性更新，应将其放入PR，并将其标记为在进行中的工作(work in progress，WIP)，以便其他人能感受到参与整个过程。
第三点：及时响应
当我们推广开源项目时，开发者会为我们提供反馈。Ta们可能对项目如何开展有疑问，或者需要一些关于如何开始的帮助。
当有人提交Issue、提交PR请求或询问有关开源项目的问题时，请尝试做出响应。当我们迅速做出反应时，开发者会觉得他们是交互的一部分，他们会更热情地参与。
即使我们不能立即查看PR请求，也应尽对其进行确认，这样也有助于提高开发者的参与度。
第四点：提供交流互动的机会
提供社区成员交流互动的机会，主要有两方面的好处：
● 社区成员相互了解（扩大社交圈）
● 减少单点沟通（提升沟通效率）
值得注意的是，我们应设置独立的时间用于为社区成员提供帮助。对于安全问题以及敏感行为准则违规，应避免的公共场合交流。
第五点：关注旅程而非终点
尽可能强调“寻求共识”而不是“共识”。一个社区可能无法达成一个完美的答案。相反，它优先重视倾听和讨论。
第六点：设置友善的标尺
开源社区应培养了一个友好、尊重的氛围。当社区正在处理一个棘手的问题时，脾气可能会上升。人们可能会变得愤怒或沮丧，并把它发泄到对方或你身上。作为Maintainer，你需要防止这种情况升级。即使你有自己的看法，也应尽量保持中立的立场，而不是参与到争论中去，强加你的观点。如果有人不友善或垄断了谈话，立即采取行动，使讨论保持文明和富有成效。
要有明确的行为规范。当有人蓄意挑起不必要辩论，对琐碎问题的争论，或侮辱Ta人时，要及时制止。如有必要，将其'退群'，避免负面的人群将会对真正的参与者造成伤害。
第七点：建立归属感
当人们感到主人翁感时，Ta们会兴奋地为项目做出贡献。一些值得关注的方面：
● 避免抵制修复简单（非关键）错误。相反，利用其作为招募新贡献者的机会，或者作为意愿贡献者的导师。
● 在项目中提供CONTRIBUTORS或AUTHORS文件，其中列出了为项目做出贡献的每个人。
● 发送newsletter或写一篇博文感谢贡献者。
● 授予每个贡献者提交访问权限。
参考：
How to Build a Vibrant Open-Source Community in 5 Steps（https://adevait.com/blog/workplace/build-open-source-community）
The Open Source Contributor Funnel (https://mikemcquaid.com/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/)