最近写代码比较少，干脆分享一点八卦，博诸君一笑 :)

几年前，在 GitHub 上建了几个 golang 的项目，主要是练手用的，也没几个人关注。最近几天，忽然几个仓库同时收到 PR， 类似这样的 ，大意就是对仓库跑了下 gofmt，其他别的都没干，请合并修改。然后在 issue 里写明了项目的地址，原来还是用 golang 写爬虫做的。自动用 GitHub 的 API 爬取 golang 的仓库，clone 到本地，跑完 gofmt 后，看看有没有修改，有修改就提交 PR。

当时有点郁闷，仿佛多年黑历史被挖出来了 :( 但是 golang 的规范就是建议用 gofmt 的，这样大家写的代码风格一致，不用再为风格吵架，节省时间，方便阅读。于是除了一个仓库外，其他都默默合并了。去爬虫仓库里看了一下，居然没有任何 issue，看来还是新项目，立马给他 贡献了第一个 issue。作者回复说会检查是否已经有 PR 了的，会考虑到 open 和 close 了的 PR，不会反复提。还提到了爬虫里比较智能的地方，如果仓库里任何地方有提到 ROBOTS NOT WELCOME，或者 NO ROBOTS，就会自动忽略掉，这些关键词可以商量，有新的建议可以加上，比如 NOFMT。最后还教会了我一点小技巧，对于不想维护的仓库，可以放入只读模式，这样其他人就没法提 PR 和 issue 了。

默默跟踪了一下这个项目，最近又多了一个 issue。老外说话简单直接啊，标题就说你这个仓库不一定会受欢迎。具体是：1. 不同版本的 gofmt 格式会有细微变化，协作者之间不一定用相同的 go 版本，gofmt 的结果不可靠。2. 你这是自动化操作的，都没有看过人家的代码，就可以刷 GitHub 的小绿点，夸大自己在 GitHub 的贡献。你这是虚伪 3. 我有些格式是 golang 代码规范允许的，你这个机器人给我改坏了。

作者的回应也很精彩，建议大家读下原文。我简单总结一下：1. 你来这里发 issue 了，其他人也能找到这里来。我这个仓库就是提供一个讨论的空间，让不满和忧虑可以得到表达。我不开仓库，默默的用匿名账户提交，机器人跑完了事，才是虚伪。2. 我都是小批量的跑，跑完会人肉去跟进 PR，跟普通人一样，签 CLA（签名表明提交不涉及版权内容）、跟进代码覆盖和整理提交信息。3. 关于机器人，GitHub 目前已经有很多机器人了，比如 CLA 机器人、安全检查机器人、格式检查机器人等等，既然仓库主人都用机器人管理了，那有人用机器人提交 PR 也很合理。

回到标题，你说的对，没有办法可以令一个产品让所有人满意的。但是管理低质量提交是 GitHub 公开仓库管理者的日常啊，高质量的提交也不一定受欢迎，因为大家对架构、优先级、实现方式的构想也可能不同。具体到我这场实验，提出的 155 个 PR 中，关闭了 55 个，其中 40 个都合并了，成功率有 72%，所以总体而言，我还是受欢迎的。农夫如果用机械作业，就不配得到他的粮食吗？为什么要歧视机器人呢？

这次事件最大的触动是，以前会自己弄 CI，搞个机器人检查代码覆盖，单元测试通过率，代码格式化等等。现在，即使你不搞，依然会有人用爬虫逐个逐个遍历 GitHub 的项目，帮你搞完，给你提 PR。这一切还是自动化的，就好比你开源在 GitHub 了，就会有机器人鞭策你前进一样。学会与机器人共生变成越来越重要的技能了。另外，写作也是一个重要的技能，GitHub 上通过 issue 互动，也是重要的贡献方式。代码是很重要，代码承载的思想同样重要，你必须要有能力传播你的观点，感化更多人与你一道参与，开源事业才会顺利