与机器共生

与机器共生,第1张

概述最近写代码比较少,干脆分享一点八卦,博诸君一笑:)   几年前,在GitHub上建了几个golang的项目,主要是练手用的,也没几个人关注。最近几天,忽然几个仓库同时收到PR,类似这样的,大意就是对仓库跑了下gofmt,其他别的都没干,请合并修改。然后在issue里写明了项目的地址,原来还是用golang写爬虫做的。自动用GitHub的API爬取golang的仓库,clone到本地,跑完gofmt

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

 

几年前,在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互动,也是重要的贡献方式。代码是很重要,代码承载的思想同样重要,你必须要有能力传播你的观点,感化更多人与你一道参与,开源事业才会顺利

总结

以上是内存溢出为你收集整理的与机器共生全部内容,希望文章能够帮你解决与机器共生所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/1270475.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-08
下一篇 2022-06-08

发表评论

登录后才能评论

评论列表(0条)

保存