前言
在一些大型项目中，单兵作战方式已经成为过去式，团队合作开发成为主要方式。对于一个开源项目来说，这个团队就是开源社区，一群人为各自的原因聚在一起，做成一件事，在这个过程中，每个人都能收获自己的成长。开源社区就像一个发动机，驱动着开源项目的发展。
X6 在 2020 年 11.22 正式对外开源，在这一年多内有了很多用户，同时也有一些贡献者参与到项目中来，但是还远远达不到一个活跃的开源社区的水平，我们最近也一直在探索怎么将社区建设得更好。正好 X6 2.0 正在开发中，有很多小伙伴来问我怎么参与到 X6 的开发中来，所以有了这篇文章，主要目的是吸引更多对 X6 感兴趣的贡献者，以及为想参与贡献的同学推荐一个适合的方向。
本文主要以自己的一些经验谈谈下面三个问题，一些观点可能不够成熟，希望各位大佬指正：
- 为什么参与开源
- 如何参与开源
- 怎么快速参与 X6 开源开发
为什么参与开源
参与开源通常不会获得物质报酬，为什么很多人放弃自己的周末时间来参与到社区活动呢？大概有下面原因。
提升自己技能。工程师需要靠技术视野一步步打开更广阔的职业生涯，在这期间我们需要走出舒适区，接触更优秀的代码、项目以及伙伴，不断磨练自己的技能。开源社区就是一个很好的场所，汇集着各领域的大佬和各巨头公司的明星项目，绝对是提升能力最好的地方。以我个人经验来看，开源社区的代码质量比业务开发中代码质量要好很多，很多人参与开源贡献完全是出于对代码的热爱和追求，而且有这么好的场所展示自己的能力，至少会用心去写代码。
在 X6 的社区，我们会认真对待每一个 PR，经常出现一个 PR 中提出多个修改意见，在他们的后续 PR 中，代码质量有着很大的进步，这其实是一个互赢的过程。除了 PR，我们有很多技术决策、版本功能都出自于 Issue 区的讨论，大家集思广益，找到合适的解决方案，这估计是开源社区的魅力吧。
还有要补充的是，其实参与开源也不一定必须要写代码， 我们还可以设计户界面、撰写文档、或是组织活动，只要有意愿，坚持长期主义，就能做出亮眼的地方。
遇到志同道合的人。Github 号称程序员必须逛的同性交友网站，很多人因为线上互相欣赏成为线下好友。在 X6 社区，我遇到过很多有趣的人，他们大多数非常热心，不遗余力的帮助别人快速上手，也不乏一些领域的大佬，对项目功能和代码进行指点纠正。
寻找导师。我们都是从学生时代过来，深知一名好的导师对个人的影响是非常大的。工作中我们往往缺少在关键时刻给我们指点迷津的人。但是在开源社区，我们可以向他人求助，询问别人是如何做的，与此同时，也会去帮助一些需要的人，相互学习和彼此教学。
提升行业影响力。开源社区是一个很好展示实力的地方，可以通过开源代码建立起自己在行业中的口碑。如果成为知名开源项目的贡献者，这个经历会成为简历上的一个亮点。很多公司的技术团队在招聘的时候是会看应聘者的 GitHub 的。我曾经就为多名 X6 社区贡献者内推过。
如何参与开源
这里为一些新手用户给出一些经验和建议，开源大佬请跳过。
编写文档。当我们在查看文档的时候，发现了 404 链接，或者是一些拼写错误，这是一个非常好的机会，马上动起手来提一个 PR，这类 PR 很容易被合并。又或是你在学习教程过程中，发现文档不全或者表述有问题，我们可以用一些更简单的方式将内容描述清晰，让更多的人少走弯路。总之一句话，遇到问题，不要坐视不理，把眼前的问题一个一个地解决掉。
其实第一次贡献不需要小心翼翼，很多人的第一次贡献都很简单，可以访问这里查看第一次提交记录，你会发现，很多开源大佬的第一次都是奉献给修改错别字。
提交Issue。当我们在一个项目中遇到问题时，可以大胆的在 Issue 区提出我们的问题，大多数标准的开源项目都提供 Issue 模板，不要怕麻烦，尽可能的将关键信息描述出来，这样会节省双方不少时间。不过在提交 Issue 之前，我们还是需要去历史记录中检索是否有类似的问题，而且不要期待维护者能马上回复你。
在 X6 的社区， 我经常会看到一些完全无法理解的 Issue，没有完整的上下文，只能通过猜的方式来了解作者意图，最后沟通了半天发现，发现两人说的完全不是一回事，这样一来一回浪费了双方不少时间。我发现问题出现在，有的人无法用最简短的语言描述出自己遇到的问题，这里推荐一篇经典文章，提问的智慧。在这过程中，还有一个非常容易犯错的地方，就是 X-Y Problem。
修改 Issue。如果发现有一些问题在我们的能力范围内，可以很快的去解决掉，然后参考贡献指南进度第一次代码提交，当项目维护者合并我们的提交后，一天都会充满成就感。
如果还没有参与过开源项目，可以先找到一些易于解决的问题，社区为了帮助新人快速参与，很多项目都会在一些比较简单的 Issue 上打上 good-fist-issue、first-timers-only 等标签，可以通过下面的链接来找到这些问题。
- https://goodfirstissues.com
- https://goodfirstissue.dev
- https://www.codetriage.com
- https://github.com/search?q=label%3Afirst-timers-only&state=open&type=Issues
- https://gauger.io/contrib/#/language/javascript
提交 Feature。如果想为一个项目开发一个功能，首先需要在 Github Issue 提一个新的 Issue，并且在描述中表明自己来解决这个问题的意愿和思路。这里注意千万不要憋大招，悄悄地完成开发和提交代码，维护者在没有语境的情况下看到一大坨代码，会非常懵，而且很多情况下，这样的 PR 需要经常反复修改才能被接受，还不如在开发过程中一直和社区保持沟通，减少不必要的返工成本。
完成功能提交后，我们需要去 PR 界面查看我们的代码是否通过 Github Actions 的检测，这是最基本的要求，没有通过检测的代码是一定不会被采纳的。然后等待维护者进行代码 review，这个过程可能会比较长，但是有一个人来仔细看你的代码细节，来分析你的实现是否最优，并给出你最诚挚的反馈，是非常有助于个人成长的。
是不是有点儿心动呀，想不想来个项目实践一波，那快来参与到 X6 开源开发！
快速参与 X6 开源开发
容我先简单介绍一下 X6，X6 是 AntV 旗下的图编辑引擎，提供了一系列开箱即用的交互组件和简单易用的节点定制能力，可以很方便的搭建流程编排应用。更多的介绍可以看官网与 Github。正逢 X6 2.0 的开发，有很多地方可以参与进来，下面简单罗列一下，有意向的小伙伴可以在 Github Issue 区深入交流。
修复 Issue。我们每天都会收到很多的 Issue，有些用户因为 X6 的缺陷被迫加班，对于这些遭遇我们感同身受，但是毕竟精力有限，照顾不周的地方还希望谅解，我们需要有人来帮忙管理 Issue，包括参与到 Issue 内容讨论和解决一些能力范围内的问题，同时我们会尽最大可能帮忙 review 代码设计和实现。
补充测试用例。一个通用框架测试覆盖率达标不一定靠谱，覆盖率不达标肯定不靠谱（X6 应该是非常不靠谱了）。缺少测试给我们带来了很多困扰，修改代码的时候变得如履薄冰。我们需要有人帮忙补充测试用例，提高测试覆盖率。在这个过程中，大家可以了解不同分支运行逻辑，快速熟悉代码。
开发功能。如果想参与到 X6 的功能开发，可以先读一遍 X6 2.0 规划，在里程碑列表中找到自己感兴趣的方向。并在 Github Issue 区与我们沟通意愿，从方案设计开始，一直到代码合并结束，我们会全程帮助你解决遇到的各种问题。下面列出一些比较独立、难度适中的事项以供参考：
- 去除项目对 lodash 的依赖
- 支持 WebComponents
- 兼容 Firefox 与 Safari
- 新增 x6-vue 包，是 X6 和 Vue 相结合的一个图编辑组件库
编写博客。很多用户在上手的时候会遇到很些问题，如果这时候能参考一些现成的实践案例，会少走很多弯路。我们非常希望有经验的同学能将 X6 在自己业务中的实践沉淀成文档，我们会这些文档标明作者后收集在我们的博客专栏，让更多的人看到。
当然，将 X6 运用到项目中、持续关注 X6 的发展，也是对我们非常大的支持。还是那句话，希望我们都能收获成长。