最近写代码比较少，干脆分享一点八卦，博诸君一笑:)
几年前，在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互动，也是重要的贡献方式。代码是很重要，代码承载的思想同样重要，你必须要有能力传播你的观点，感化更多人与你一道参与，开源事业才会顺利