前几天在闲暇之余浏览 Github ,发现不少开源项目都存在大量的 Issue 和 Pull Request 没有得到解决。这其实也是比较正常的情况,对于大多数没有稳定收入来源的开源项目来说,你不能要求核心团队提供任何多余的服务,而是应该发起一个 PR 来帮助项目的成长。于是我突然想起了 Elixir ,这门我已经写了 3 年,在我心中最适合 Web 开发的函数式编程,也许我也有什么能帮上忙的说不定。
令我惊讶的是,Elixir 的 Issue 仅有 20 条左右,PR 也仅有 5 条以内,并且很多陈年老 Issue ,原因可能一方面是 Elixir 经过了 10 年多的迭代进入了稳定期,更重要的原因那就是创始人 José Valim 和他的团队铁人般的提交数量,整个 Elixir 项目,José Valim 一人就提供了接近 5000 的 commits ,断崖领先其他人。而除了 Elixir 外,他也是 Phoenix/Livebook 等一系列核心生态项目的主力负责人和开发者。
Issue 列表中每一条都有 José Valim 的回复并且打上了各种标签著名 Issue 类型,有些是需要 Issue OP 提供更多信息的 bug ,有些则是简单的 Feature 描述,还有一些 Chores 相关的杂活,整体 Issue 都比较清晰。我浏览 Issue 列表发现了一个 bug 标签的帖子,主要问题是:
当前 IEx 中对于三种 `normal` 类型的 EXIT 信号不会提供任何报错信息,José Valim 的目标是将这些报错信息全部展示(尽管可能会造成一些报错信息的重复)。
我想这是个很简单的改动,我应该不在话下。于是我果断 Fork&Clone Elixir 项目,新建分支。得益于 Elixir 清晰易懂的 Contribution 文档,编译,测试,整个开发过程非常丝滑(虽然丝滑,但是实际上还是超出了我的预期用时,一门编程语言的代码量还是花了我不少阅读时间,并且再一次让我体会到: 阅读源码真的是学习的最佳手段 )。完成后我果断上传了分支,提交了 PR 请求。当时时间是北京时间晚上 11 点左右,令人惊讶的是提交十分钟后 José 就提供了回复, 他很有礼貌的表示感谢 PR ,同时表示我不需要通过颜色来区分显示 `normal` 类型的 EXIT 信号,直接全部显示就行了 。我在接到他回复之后马上提交了修改,再 10 分钟后他就启动了线上测试,通过之后立即合并了代码,就这样短短 1 个小时内,我完成了一次对 Elixir 的开源贡献!
这一切完成后,我当晚体会到了难以言喻的纯粹的快乐,这种感觉比我第一次学习代码跑起 'Hello, World' 更甚。我一时间十分有分享的想法,但是我不太好意思向身边的人诉说,一方面这个 Bug 改动并不困难,另一方面熟人中程序员也不多,最终我只是兴奋地和女友和最要好的朋友说了这件事。不过他们并不是开发者,所以理解不了我的感受,但还是耐心地听我的分享,十分感谢他们。
后日谈
昨天是周末,我很有动力地继续前往 Elixir Issue 列表找“活”,发现了一个 2022 年就开的 Feature 并开始工作,花了一个下午的时间提交了 PR。遗憾的是我在应用场景上误会了需求,虽然 José Valim 很客气地对 Issue 不够详细说明表示抱歉,但我知道主要还是我太想当然了。第一次的 Merge 过于顺利让我有点冲动了,下一次我要更加详尽地去准备(惭愧)。