From 5c6e19d889134b1fe1241adb07569a7d73103068 Mon Sep 17 00:00:00 2001 From: ORH <512574561@qq.com> Date: Tue, 24 Nov 2020 10:14:35 +0800 Subject: [PATCH] =?UTF-8?q?update(4.4):=20=E6=8E=92=E7=89=88?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...44\345\222\214\347\256\241\347\220\206.md" | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git "a/\347\254\254\345\233\233\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\347\273\264\346\212\244\345\222\214\347\256\241\347\220\206.md" "b/\347\254\254\345\233\233\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\347\273\264\346\212\244\345\222\214\347\256\241\347\220\206.md" index 7c84cd5..015f247 100644 --- "a/\347\254\254\345\233\233\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\347\273\264\346\212\244\345\222\214\347\256\241\347\220\206.md" +++ "b/\347\254\254\345\233\233\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\347\273\264\346\212\244\345\222\214\347\256\241\347\220\206.md" @@ -1,6 +1,6 @@ ### 如何推广开源项目 -“酒香也怕巷子深”这句话在互联网时代特别适用。我在 N 年前看过一本创业公司老板写的研发项目管理方面的书，到现在还记得一句话 “一个公司的核心竞争力，一是技术，二是营销”。对于一个开源项目，将代码放发布到代码托管平台仅仅是一个开始，真正重要的是社区运营工作。如何让更多的人能够快速了解你的项目而不是无人问津？如何让有兴趣的人更积极的参与项目而不是永远仅仅依靠一己之力不可持续？这些都是非常现实的挑战，也是一个开源项目能否健康发展的重要基础。 Apache 软件基金会（ASF）的 Apache Way 的核心理念就是 Community over Code （社区重于代码），也说明开源项目建立社区的重要性。 +「酒香也怕巷子深」这句话在互联网时代特别适用。我在 N 年前看过一本创业公司老板写的研发项目管理方面的书，到现在还记得一句话 「一个公司的核心竞争力，一是技术，二是营销」。对于一个开源项目，将代码放发布到代码托管平台仅仅是一个开始，真正重要的是社区运营工作。如何让更多的人能够快速了解你的项目而不是无人问津？如何让有兴趣的人更积极的参与项目而不是永远仅仅依靠一己之力不可持续？这些都是非常现实的挑战，也是一个开源项目能否健康发展的重要基础。 Apache 软件基金会（ASF）的 Apache Way 的核心理念就是 Community over Code （社区重于代码），也说明开源项目建立社区的重要性。 要做好一个开源项目的推广，项目内容中除了源代码之外，完备的文档体系对吸引大家关注以及参与都是非常有帮助的。总之，如果仅仅只有一堆源代码，会让很多人都望而却步，以下简单列举两个非常必要的文档和规则说明。 @@ -12,11 +12,11 @@ 任何一个开源项目，肯定都是希望有更多的社区参与者和贡献者，但是对于参与者可以如何参与项目贡献，并且需要遵循哪些基本规则，比如提交问题的规范，如果是做代码贡献，还有代码相关规范等，以及参与贡献的完整操作流程，这些内容我们可以通过贡献说明文档来说明。另外，我们也可以对项目的社区治理架构及不同等级的贡献者的要求及权力做进一步说明，这些内容整体上构成了本项目在社区参与过程中的一些基本规范。 -具体的开源项目推广方式比较多，宣传和更新维护都是一个漫长的过程，如果你不是明星账户，如Google或者twitter或者gitee上高star项目作者，我们新人能做的只能是坚持。以下列举一些常见的方式。 +具体的开源项目推广方式比较多，宣传和更新维护都是一个漫长的过程，如果你不是明星账户，如 Google 或者 Twitter 或者 Gitee 上高 Star 项目作者，我们新人能做的只能是坚持。以下列举一些常见的方式。 -1、选择一个平台作为你博客的唯一主页。例如用wordpress建自己的站点，但考虑到建站还需要购买服务器或者空间，国内建站需要备案等，你可以考虑使用github pages来搭建属于自己的个人网站。 +1、选择一个平台作为你博客的唯一主页。例如用 Wordpress 建自己的站点，但考虑到建站还需要购买服务器或者空间，国内建站需要备案等，你可以考虑使用 Github Pages 来搭建属于自己的个人网站。 -2、写作投稿。将你博客的文章推送到各大流量较高的社区，比如国内比较活跃的知乎问答社区、前端人员聚集的掘金社区，以及segmentfault和博客园等。回答别人的问题用心和详细，回答字数只能多不能少，最好图文并茂，语言风趣或者讲一些笑话效果更佳，切记胡乱回答，尤其专业问题没经过自己验证和测试就胡乱回答。并且在文章中说明项目地址、参与方式等，通过这些方式能够较低成本的将对项目内容感兴趣的人员引流到项目社区中； +2、写作投稿。将你博客的文章推送到各大流量较高的社区，比如国内比较活跃的知乎问答社区、前端人员聚集的掘金社区，以及 Segmentfault 和博客园等。回答别人的问题用心和详细，回答字数只能多不能少，最好图文并茂，语言风趣或者讲一些笑话效果更佳，切记胡乱回答，尤其专业问题没经过自己验证和测试就胡乱回答。并且在文章中说明项目地址、参与方式等，通过这些方式能够较低成本的将对项目内容感兴趣的人员引流到项目社区中； 3、建立微信群、 QQ 群、钉钉群、微博、公众号等沟通渠道。通过社交工具，可以更精准及频繁的传递项目信息，建立与社区参与者更高的黏度，充分挖掘社区参与的活跃分子并且通过各种活动方式，让项目社区逐渐形成并壮大； @@ -27,32 +27,32 @@ ### 项目被提交 Issue 时应该怎么做？ -当我们的开源项目上线之后，后期是需要维护和版本迭代的。Issue 是记录各类 BUG、需求的方式，也是开发者之间非常重要的的交流工具。参与者可以通过各种状态的 Issue，看到针对各种问题或者需求的详细内容，也可以通过提交 comment 的方式参与沟通讨论。 Issue 的数量、打开和关闭的比例以及针对 Issue 的处理是否及时等，这些都成为衡量一个开源项目是否健康且受欢迎的重要指标。 +当我们的开源项目上线之后，后期是需要维护和版本迭代的。Issue 是记录各类 BUG、需求的方式，也是开发者之间非常重要的的交流工具。参与者可以通过各种状态的 Issue，看到针对各种问题或者需求的详细内容，也可以通过提交 Comment 的方式参与沟通讨论。 Issue 的数量、打开和关闭的比例以及针对 Issue 的处理是否及时等，这些都成为衡量一个开源项目是否健康且受欢迎的重要指标。 下面我们来探讨一下在不影响工作、生活的情况下如何有效率的持续迭代，如何将用户的提问引导到项目的Issue上来。因为： -1 你没有那么多精力去很多个平台回复问题。这一点与上一章节并不产生矛盾，项目宣传的时候可以去大流量平台做推广，但是当用户对项目有疑问或者BUG反馈时，尽量引导他们到项目的Issue上来。 +1 你没有那么多精力去很多个平台回复问题。这一点与上一章节并不产生矛盾，项目宣传的时候可以去大流量平台做推广，但是当用户对项目有疑问或者BUG反馈时，尽量引导他们到项目的 Issue 上来。 -2 你没有那么多时间天天盯着 QQ 群解答问题。刚开始入群的新人遇到问题会直接在群里艾特你，尤其是一些伸手党看都没看过别人是否提问过该问题，就想让你做他的客服。所以你不必理会，引导他们到你项目的Issue上来，这样久而久之用户就知道下一次遇到问题的时候先去你的项目提交Issue。 +2 你没有那么多时间天天盯着 QQ 群解答问题。刚开始入群的新人遇到问题会直接在群里艾特你，尤其是一些伸手党看都没看过别人是否提问过该问题，就想让你做他的客服。所以你不必理会，引导他们到你项目的 Issue 上来，这样久而久之用户就知道下一次遇到问题的时候先去你的项目提交 Issue。 3 问题应该被集中起来，供使用者反复查阅。 -当项目维护者看到有 Issue 提交时，最重要的是迅速反馈，无论是 bug 还是需求，都可以跟提出者通过 comment 方式进行充分的沟通，达成共识，也可以对 Issue 打上标签，便于分类管理。另外，还可以将 Issue 分配给其他参与者，或者将 Issue 添加到项目的看板，关联到某个里程碑等操作，当 Issue 中的问题被解决后，应该及时做关闭。 +当项目维护者看到有 Issue 提交时，最重要的是迅速反馈，无论是 Bug 还是需求，都可以跟提出者通过 Comment 方式进行充分的沟通，达成共识，也可以对 Issue 打上标签，便于分类管理。另外，还可以将 Issue 分配给其他参与者，或者将 Issue 添加到项目的看板，关联到某个里程碑等操作，当 Issue 中的问题被解决后，应该及时做关闭。 -当用户量增多，Isssue中会提到各种各样奇葩的需求，这时候就需要你判断该需求是否应该被添加，以下是可以几个可以参考的指标： +当用户量增多，Isssue 中会提到各种各样奇葩的需求，这时候就需要你判断该需求是否应该被添加，以下是可以几个可以参考的指标： -1 该 Isssue 是用户提出的BUG,则应当给与解决。 +1 该 Isssue 是用户提出的 Bug,则应当给与解决。 -2 该 Issue 是很多用户提过的需求，即大众需求。我们的产品只需要满足90%以上用户需求即可，我们不可能把产品做的面面俱到。当用户提出的是大众需求时，可以把该Issue纳入下一版本的更新。 +2 该 Issue 是很多用户提过的需求，即大众需求。我们的产品只需要满足90%以上用户需求即可，我们不可能把产品做的面面俱到。当用户提出的是大众需求时，可以把该 Issue 纳入下一版本的更新。 2 你判断这个需求对大部分用户是否有用。 3 该需求符合产品的定位以及未来发展方向，或者该需求能抹平和竞品的差距，或者能和竞品差异化竞争。 -符合上诉条件的Issue可以纳入下一版本的升级计划，如果不符合可以予以拒绝。总之是围绕 Issue 能够展开积极互动和响应，这样才可以让社区始终保持活跃，形成一个良性循环。 +符合上诉条件的 Issue 可以纳入下一版本的升级计划，如果不符合可以予以拒绝。总之是围绕 Issue 能够展开积极互动和响应，这样才可以让社区始终保持活跃，形成一个良性循环。 ### 项目被提交 Pull Request 时应该怎么做？ 当项目有 Pull Request 提交时，上面处理 Issue 时的一些原则同样适用，关键是能够快速反应，坦诚沟通，对提交的 PR 进行 Code Review，最终决定是采纳或者拒绝。当然做必要的自动化检查及测试，这是 Code Review 的前提，一个好的开源项目，应该利用各种工具链做好持续集成持续发布服务（CI/CD），尽量先用自动化的方式完成一些测试和验证，这样也可以提高代码输出的质量及 Code Review 的效率，同时，也可以在贡献说明中对代码要求规范、PR 提交规范等做好说明，避免让参与者在贡献过程中由于这些方面的原因感觉到挫败。 -总之，一个开源项目的运营，透明化是最重要的一个原则，包括各种规则的透明、交流过程的透明等。 \ No newline at end of file +总之，一个开源项目的运营，透明化是最重要的一个原则，包括各种规则的透明、交流过程的透明等。 -- Gitee