开源项目维护指北 —— 写于 1k Followers 有感
可能了解我面试习惯的朋友们知道，我的最后一问一定是：
介绍三个你最喜欢的开源库。
问的是面试者对于开源的敏感度与学习的热情度。根据回答的内容（是否常见/关注理由），我能大致了解对方的学习偏好作为一个比较重要的参考。
我算是个比较狂热的开源爱好者。一直以来就想写一篇关于开源的文章，但一直找不到好的机会。恰巧最近，我的 GitHub 关注者突破了 1k，并且进入了中国区 top500，于是我觉得是时候写点什么了。
仅为个人的经历和想法，可能不太成熟，欢迎提出指正。对了，如果看到这里，欢迎顺便关注我的 GitHub 配合阅读：https://github.com/ddiu8081。
开源是什么，贡献是什么？
请允许我先唠叨几句，从概念开始讲起。顾名思义，开源就是开放源代码，它可以允许任何人几乎出于任何目的查看、修改和分发源代码。而贡献，就是指为开源项目做出有价值提升的行为。
不管是提交代码，还是简单的提交 issue，都属于为项目做出贡献，都能为开源项目壮大力量。
创建项目的契机：从玩具到 7k star
其实我还处于开源的一个很浅的领域，并没有深度参与和贡献过大型项目，只是创建和维护过一些 side project，或许没办法很全面地讲解开源领域。但是碰巧也是在这两个月，我的其中一个 side project 获得了一些关注，3个月内累计收获了 7k star，有31名贡献者为项目做出了自己的贡献。于是借着这个项目，讲一讲开源项目的开端——如何创建项目吧。
首先介绍一下这个项目：ddiu8081/chatgpt-demo（目前已经创建和转移到了 anse-app 组织下打理）。这是一个 OpenAI gpt-3.5 接口的 WebUI，它提供了一套前端+后端的极简实现，允许用户在大陆网络环境下，就获得类似ChatGPT 的体验，并可以一键部署到任意服务器。
这个项目做出后，获得了完全没有预料到的关注度。在 GitHub 的 star 数在第一天就破了千，提供的演示站点也达到了每日十万次查询。为此我也收到了来自 OpenAI 的 8700 刀巨额账单：
至于为什么想到创建这个项目，其实从它放荡不羁的名字也看得出来，最初做出来只是当做个自用的玩具。3月初一个平静的早晨，刷着手机突然发现 OpenAI 发布了 ChatGPT API。因为之前短暂地体验过 ChatGPT，我知道它对于大陆的体验是不太好的——注册难、登录难、回复慢，还有过半的失败率。因此如果有 API 的话，其实是可以解决这些问题的，这不就有了一个好用的私人聊天助理？
于是在API发布当天，我花了两个小时做出了 chatgpt-demo 这个项目，并且绑了一个域名给自己使用——然后发到粉丝群和 V2EX 给网友们玩一玩。然后它就变成了如上的样子。
因此我觉得，或许启动一个项目并不需要什么很正式的理由，也不需要是多么严肃的项目：可以是个练手的轮子，可以是个玩具，甚至也可以是个菜谱（Anduin2017/HowToCook）。但最好是符合自己兴趣的方向，因为兴趣是最好的驱动力。
开源项目的维护
虽然作为参与者维护开源项目的经历有限，但我大概可以以项目管理者的角度讲一讲怎么维护开源项目：
积极回应
在开源项目达到一定规模之后，伴随而来的往往是很多的 issue 或 pr。多的时候，一天能收到项目的上百条通知。
绝大部分 issue 都是为项目提交 bug，也有一部分是 Feature Request，即为项目建议新功能。
在茫茫 repo 海中找到了这个项目，这本身是一种缘分，不妨在回复栏中表达自己的感谢，感谢对方提交的问题。
当然也会有想要拒绝的请求，这在 pr 中居多。大部分是贡献者提交的代码格式有问题、影响面太大或是改动内容偏离了自己对于项目的规划。对此，我建议仍然感谢对方的付出，然后指出自己不赞成的点。
但 issue 不总是友好的
在用户提交的 issue 中，确实存在一些质量不佳的issue，比如：
- 一条标题为“为什么无法使用”的issue，而没有附带任何信息；
- 在issue中发广告；
- 在issue中不描述问题，而直接展开diss或无意义的争论。
为了避免其他人带来不愉快的感觉，甚至是出现劣币驱逐良币的现象，需要及时地进行回复或关闭，保持社区的健康性。
建立 issue 模板
在项目初期，issue 提交是没有规范的，用户可以提交任何内容。但是对于 bug report 来说，如果缺少信息是很难定位问题的，就变成了无效 issue。
为了让无效 issue 少一些，建立 issue 模板是一个好办法。
仍然以 anse-app/anse 的issue创建页面（https://github.com/anse-app/anse/issues/new/choose）举例子。我设置了 Bug report、Feature request、Typo fix 三个提交入口分别代表 Bug 提交、功能请求与语法内容修复。此外，在下面还列举了一些可能用到的链接（项目文档、路线图、讨论区）用来分流。
拿 Bug report 来说，首先我列举了几个必读项：
- 确认自己使用的是最新版本，确保自己上报的不是已经修复的问题；
- 确认这个问题没有被其他人提过，避免产生重复 issue；
- 使用英语交流，这可以让更多人参与到项目和 issue 的贡献中来。
然后在表单中需要填写系统环境、浏览器环境等附加信息，协助维护者定位问题。
这样，通过添加模板，就可以很大提升 issue 的质量。
提供贡献指南
当路人对项目的贡献产生兴趣时，一个好的指南是有必要的——毕竟临时贡献者很难一下子就熟悉整个项目。因此，在开源项目中，建议有一个名为 CONTRIBUTING 的文档部分，用来欢迎新晋贡献者，为他们讲解代码的主要架构、如何运行与修改代码。
保持交流的公开
我曾收到过不少邮件，都是私下询问项目中的问题。这其实是不利于信息共享的，可能会导致不同用户之前产生信息差。为此我的做法是，不会回答通过私聊方式提问的项目问题，而是引导对方发布 issue，在所有人都能看见的地方。
开源的精神是协作
先不要亲自修 bug 。听起来或许很奇怪，但一些简单、不太紧急的 bug 其实适合用来引导他人参与到贡献团队中来。
为此，就像很多开源项目一样，我在 anse-app/anse 项目的 issue 模板中也加入了一个复选框：
I am willing to submit a pull request for this issue.
我愿意为这个issue提交pr。
这其实能引导 issue 作者思考：这个 bug 能否自己修复，feature 能否自己完成？如果愿意的话，其实这就是从问题提交着 → 代码贡献者的转变。当然如果没有勾选此框，其他用户也可以选择为它贡献。
如果在此期间出现了一些特别积极的贡献者，我可能会选择邀请对方成为项目的成员，从而能够更加深度地参与到项目的决策中来。
让大家觉得自己是项目的一份子，我觉得这就是开源的协作精神。
做开源能收获什么
开源指北结束了，再讲一讲个人从开源项目的维护中得到了哪些收获吧。
开源也是一种学习
通过维护开源项目，我累计收到了上百条 Pull Request，看到了上百个人对我项目的修改。从他们的代码提交中，确实能发现一些值得学习的东西，比如某个 API 的使用、某个能大大降低逻辑复杂度的重构。其中一些改动是我之前还不了解的，看过他人的代码之后，确实能学到一些知识。
接触志趣相投的朋友
虽然我维护的项目还没有建立诸如 Discord 之类的聊天社区，但是在 Issue 及 Discussions 等地方，可以看到很多人在友好地交流，互相分享自己的想法。
虽然其中的一些提议会被我否决，但不可否认的是，每个参与者都在为项目变得更好而努力着。
学习管理的艺术
最开始收到对于项目的 Pull Request 其实是比较手足无措的——不愿意接受，但又感觉不好拒绝。随着收到的pr越来越多，感觉已经能够自如地关闭了；除了做决策方面，还有其他一些领导力和个人能力的提升。
最后，一些你可能关心的
Q: 真的花掉了 8700 刀？
A: 是的，但 OpenAI 为我买了单。因为接口推出才一两天，或许是 OpenAI 计费网关出现了延时故障，实时消费额出现了数天的滞后，所以我设置的最高额度没有拦住。事后 OpenAI 把这8000刀作为信用额度，因此我并没有实际未这笔钱付费。
Reference
