掘金上居然有文章教人怎么给开源软件提 typo issue

这就是抓字眼式 issue 吗，爱了爱了

我竟分不清他是在反讽还是在自嘲还是在沾沾自喜

感觉不太合适

当参与开源项目变成了一种时髦。。。。。

这教会我们要好好学英语，单词要拼对，码代码时不要忽视 ide 对错误拼写的单词的警告。

@Jsonz 检查代码拼写的

感觉很 low 但改 typo 也没错

有人免费帮你做了你自己不想做的事情，而且这个事情本身也能够提升项目质量，何乐而不为？

今日无事，我溜达到文昌发射中心，从地上抠下块口香糖，如获至宝。打开简历，郑重写下一行：

“参与过文昌发射中心的火箭发射活动”

深藏功与名，文昌发射中心收获了我免费的劳动，我挥洒了我的汗水，面试官和 HR 都对我刮目相看。
啊，又是美好的一天。

@mercury233 看评论吧...明显是在沾沾自喜啊，评论里面有人反馈这样做是不是不太好文章很水，作者很开心的说我这文章就是来水的...总感觉这样带动了一股风气

我觉得改 typo 不适合单拉一个 merge 提过去给作者吧，在用开源库发现代码需要 fix 的时候提 issue 过去，刚好改到的部分有 typo 顺手改了才是正常行为吧，没事把代码拉下来贴到 word 里面打开字符校正看有没有错别字，有错别字拉个分支提 issue...怎么看都很像之前的华为事件啊

我记得之前有个新闻，一个国外的小女孩给 linux 代码注释加了一个 "-" ，评论区全是夸赞，轮到国人修改 typo 就不行了
我记得在哪看过，有些开源项目会留一些 typo 给新人熟悉 PR 流程，增加参与度

@leo108 这个事情真的有提升项目质量吗？我真没觉得提升了。

如果哪个变量名拼写错了，帮忙改，我觉得还可以。掘金那文章里的就是改的注释啊。

@Rainshaw 你这个例子最重要的点不是国内与国外的差异，而是小女孩跟混迹技术论坛老油子的差异，要是国人小学生看开源代码提 typo issue 我觉得很了不起。但是文章作者起码是工作了的，再不济也是大学生，教别人提无效 issue 让人来增加自己简历的闪光面，你觉得合适么？

您这回复还真是个典型，挑起对立面引发攻击，你是要个女的肯定是微博打拳的一类人，要是 V 站有踩我必送您

怎么说呢，本质上是好事但不要“刷 kpi”和错误的引导别人。可以攒一攒再 PR，不然那个不懂 vue 的家伙也会很困扰。而且比起我看到也懒得 pr 说不定他慢慢参与改着改着就改到核心代码了呢。

@Rainshaw 因为是两拨人吧,夸赞的那一波都是非技术的,以为源码,linux 是多高深的东西,然后开始联想到国外人真 nb 从而夸赞
国内的批评的肯定是同行啊,提一些无营养的东西...比如代码格式有问题,改一行格式提一个 pr......,遇到这种气不气?你就算改了也要全改后再提,而不是蚂蚁搬家

看他文章和评论就是报着玩的心态弄的，不过确实引起不好的示范

@cwp374240920 每个 pr 或者 issue 都仅解决单一问题哦，你这个顺手改其他的话，就违背了这一原则。

新手从 fix typo“入门”开源项目，是一个比较容易上手的选择。提 pr 的时候可以顺便熟悉一下社区的文化和贡献流程。

@cwp374240920 如果污了您眼了我很抱歉，建议 block 我，谢谢。改 typo 并不是无效 issue 。对于一个初学者，无论是字词 typo 还是其它 typo 都会很影响其对于项目的第一感觉，并且提个 typo 让文档更加规范在我看来也是很好的。项目核心开发者可能没有太多精力去进行校对工作，那即便他们是为了刷 pr，为了增加简历内容，提 PR 来完善文档我认为对于社区也是有帮助的。且，不会真有 HR 直接把提 PR 当闪光点吧，非核心开发者就算是提 PR 修了几个 bug 也只能显示他熟悉 git 流程，对于其”闪光面“我认为无任何帮助。

@wszgrcy 哎，代码格式有问题也可以提 pr 哇，比如之前没有用过 eslint 或者 black，提个 PR 整理一下格式也没啥，主要还是看 PR 的内容。如果 PR 里就是单纯的加个回车啥的那确实恶心人。

@Rainshaw #13 不要混淆概念，这和国不国人有什么关系？小女孩捡到五块钱交给警察叔叔，发在网上肯定会被广泛称赞。你一个二三十的大老爷们还想靠这种事提升自己的形象，丢不丢人啊？流汗黄豆是吧

任何一个对代码库有利的 PR 都是值得提交的，包括修复代码中的 typo 或者静态检查错误。

哈哈哈，点进来之前我就猜是不是这个帖了，我昨天看到的，一阵不适

这事儿也不伤天害理，自己干了就干了，吹牛逼的时候，悄悄跟人说自己是某项目的贡献者，这就得了。
但让人恶心的是，他还把这当做一件莫大的光荣，到处跟人翩，恨不得写在他家家谱里。

@vain 为了混好看的简历，也不应该批评。而是如果其 PR 内容是纯粹没事找事，该批评，如果确实修复了 typo 就毫无问题。

@acmore #10 你不捡我不捡，火箭首席设计师会去捡？最终还不得雇佣全职的清洁工？

开源项目会请人专门来改 typo ？

@Rainshaw 如果是国内的小女孩的话也会赞扬的。因为修改这个并完成整个流程，对于一个小女孩来说本身是一件困难的事情。
但是一个成年人整天关注这种东西，好像就已经不太对了。

改 typo 发 PR 比某校先提交漏洞再自己修掉刷 paper 要好的多吧，那一种才是真正浪费开发者时间

一个开源项目如果有人会花费 ta 自己的时间来修 typo 。维护者应该感恩，更不会认为这是所谓的垃圾 /无效 PR 。

很多人的第一个 PR 就是修 typo，对于提交者而言，这是破除「心魔」的一次好机会。并不是你要会完美的添加一个模块或者接口才有资格向开源项目提交 PR，正如前面所说的，任何能够改善代码库的 PR 都可以。对于维护者而言，typo 通常是很难注意到的，修掉 typo 一般不会改变软件功能，review 起来也很容易，风险很低，为什么不接受呢？

@learningman 我持不同意见，应该是对初学者来讲是困难的事而不是小女孩，因为在熟练的开发者看来，不过是点几下鼠标，输入几个字符而已。成年人也可以通过提 typo 来破除 @ayase252 所说的”心魔“。


对楼上持反对意见者：
”诸君的辫子长在心里“，认为提 typo 实在是太简单、太”蠢“了，不能彰显技术水平，却能和其他功能代码贡献者享有同等地位“Contributor”标签这是一种傲慢。

这是教人类来做工具的事情么。开发都和工具卷起来了。。。

这种 typo 的 PR 有人写 bot 全自动地提。fix typo 我觉得没什么，但是只 fix typo 并且动机根本就不是想对项目有贡献就有点……但是一般的项目作者都不会去这么 judge 别人的动机，至少表面上还是很友善的。

正常思维不是有需求了才去看代码，顺手改掉 typo 么。改掉的应该也是自己 IDE 配了插件检查出来的。

@Rainshaw #33 https://elinux.org/images/0/06/Lca13-gregkh-I-dont-want-your-code.pdf
请先看一下这篇文章
就不讨论动机是不是不纯了，这种 pr 本身带来的收益，也不能说有多大。

@learningman 太长。。。但这种 PR 在 Github 上只需要负责 merge 的人，点两下鼠标即可，所带来的开销也是很小的。

@Rainshaw #38 但是如果是 100 个这样的 PR 呢，你可以看看 Vue 的 PR 列表里面有多少个活动的 PR，这种无意义的 PR 还是好一点为佳。

@leo108 我想我已经说得很清楚了，爱捡就捡。
但以此把不属于自己的成就挂在自己头上就是无耻了。

@learningman 所以争论点还是这种 pr 有没有意义，有人认为有意义有人认为无意义。

@learningman 这个文章和你的论点毫无关系，修复 typo 并不属于文中提出的任何问题（既没有违背 coding style，对注释的更改也不会产生任何影响 compile 的行为，一般来说对变量的更名也不会产生程序行为上的任何变化，GitHub 在 PR 方面也比传统的 mailing list 更加友好）
这类 PR 对项目本身以及开源社区的意义我认为上面 ayase252 也已经说的非常清楚了。

@cwp374240920 应该在 feat pr 里夹带 typo fix 吗？这和我印象里的最佳实践不太一样

提 typo issue 是没有错的，但必须要整合提交，如果一行 typo 就发一个 issue 的话，再好脾气的开发者也受不了这种刷屏行为

@learningman 即使相比于代码修正、文档在技术层面问题上的修正，typo fix 对项目的贡献更低。typo 始终是一个已存在的问题，这类 PR 不应当被认为是无意义的。

掘金里的文章都太水了,各种标题党,乱起名字,早就不看了

想起来提的第一个 PR 也是 typo，兴致勃勃的以为自己也能参与一下开源，然后就被嘲讽了，记得别人说这也行？于是我参与的想法一下被浇灭了。现在回想是很简单的事情，对于新人第一个这样的感觉还是可以鼓励可能会更好。像之前某为那种甚至刷内核 pr 感觉也不好：
https://www.zhihu.com/question/466111598

@datasone 我想说的是，维护者的精力也是成本的一部分，这种重复的机械的劳动，对社区并没有好处。

我的角度，很欢迎开源社区的初学者和入门者提 typo 或者对 message 进行语法修复和完善，这种脏活累活有人愿意花时间我还挺感动的，不过那种一次修一个错误的 pr 就算了

不用看 猜肯定是搞前端的吧 掘金上各种前端的水文

我倒是觉得 typo 这种事儿提个 issue 顶天了，单纯为了这个提 pr 有点过分，有人提了 pr 最好也婉拒掉，下次自己 pr 的时候顺带改了然后 changelog 写个鸣谢带个名字就得了。
毕竟，谁告诉你的注释里的 typo 改了 100%不会崩掉整个项目

说好吧，让更多人享受参与这个项目的参与感
说不好吧，对代码质量没有实质的改变

只能说还是看提交的人，是为了获得一个称号还是真心想共同维护这个项目。

第一次上掘金，点到列表页瞅了一眼。“土豆不要这样炒，多这么一步比肉还香” 这种类型的欢快标题就给我镇住了。

这种就是 开课吧 的 lj

利益相关= =，提 Typo 还好吧= =...，以前尝试翻译文档的时候，发 Issue 作者让直接提 PR= =.....提了人生第一个 PR，真的可以破除心魔。

https://github.com/aio-libs/aiohttp/issues/2760

我觉得第一个 pr 是 typo 一点问题也没有，fix typo 也是给项目做贡献，同时也是熟悉项目的维护流程。
但是如果每个项目都只有 fix typo 就很有问题了。

@Rainshaw #12
《 Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk)》
我寻思菊花被警告才过了几个月啊。
按照你的逻辑，因为菊花是国内公司才被质疑的是吗？

@wolfie 我也寻思不提菊花厂就难受是吗？有没有完整看完帖子啊，笑

typo pr 完全没问题，错的就是错的

typo 的 pr 完全没问题，还有一些 documentation 里的文件途径错误之类的，都是可以接受的呀

就事论事，这四个字，说说容易啊，身体力行又何其难？

我有发言权
首先我是开源作者： https://github.com/flipped-aurora/gin-vue-admin
其次，认识我的都知道我英文很差很差很差
最后也感谢 typo issue 帮我少丢了人

补充一下 如果用这种 pr 来给自己简历增光...那大可不必..我们都希望开源是非功利性质的 是 兴趣使然谈的 而不是有目的的

这不是前一阵碰瓷 element 那个吗，整活很 6

@wtf12138 不好意思，你认错了。。。那是 beautiflu 。。

@wtf12138 我这是 golang+vue 项目。。。不是纯前或者纯后项目

@Rainshaw
现在一群人认为随意提 typo issue 没问题
另一群人认为随意提 typo issue 有问题
现在用华为相关的那篇文章来论证随意提 typo issue 不好是有什么问题吗？为什么不能提？

以前在 gayhub 上用过一个小工具, 代码写得很漂亮, 注释写的很巨魔, fork 下来 ide 里打开 150 多个 typo 报错.

刚好我写过两篇类似的文章 [如何成为 golang 贡献者]( https://www.ixiqin.com/2021/08/how-to-become-golang-contributors/)，[如何为任何项目贡献]( https://www.ixiqin.com/2021/08/how-to-contribute-to-any-open-source-project/)，我个人的观点是这样的：

1. typo 类的 issue 本身是没有问题的，即使修改很小，对于开源项目来说，也是很好的改动。这不应该成为我们批判的目标。难道一个项目中满是 typo 才是正常的？
2. 我们应该鄙视 /摒弃的是拿 typo 当 KPI 用。
3. 对于开源的新人来说，你应当明确，typo 修改只是你快速加入社区的一个方式，但如果你希望长期在一个社区成长、贡献力量，甚至是以此放在自己的简历上，那仅仅是修改 typo 是不够的。也无法锻炼你自己的。长期刷 typo 并不会让你的简历更好看，甚至对于懂行的人来说，这是一个扣分项 ”为什么这么多年你只做 typo ？你是在这个方向毫无建树么？那我为什么要让你进来给我添堵“

这事根本问题在于用 pr 数量来考察 kpi/资历的人，HR 或者面试官。开源贡献是好的，但是应该点开几个查证。
hr 不懂技术就不应该参与到技术人员的 performance review 里，而是应该交给中层管理人员。
我第一个 pr 也不是 typo 啊。实现一个新功能也许只需要几行代码。真没必要为了 pr 而 pr 。

@cwp374240920
> 你这个例子最重要的点不是国内与国外的差异，而是小女孩跟混迹技术论坛老油子的差异，要是国人小学生看开源代码提 typo issue 我觉得很了不起。但是文章作者起码是工作了的，再不济也是大学生，教别人提无效 issue 让人来增加自己简历的闪光面，你觉得合适么？

> 您这回复还真是个典型，挑起对立面引发攻击，你是要个女的肯定是微博打拳的一类人，要是 V 站有踩我必送您


非常赞同

@Rainshaw 确实在 wb 女的的话，我觉得就是典型打拳

重点是先参与进去了 ，没啥问题吧

要是第一个 PR 提提 typo 没啥所谓，老是提 typo 的别人一看你 PR 历史就会露馅吧。

写了一篇文章， 阐述了我自己的观点 ，如果对我在 69 楼的观点感兴趣的话，可以继续阅读： https://www.ixiqin.com/2021/09/give-well-known-project-typo-to-repair-whats-the-problem/

卷起来了

@Rainshaw

一会儿瞎搞国内国外对立，一会儿我觉得您觉得，你这种人就是自以为是的来恶心人。真别觉得自己有多懂道理，就请问下你给哪个开源项目贡献过？你参与过开源项目维护和开发了吗？

改 typo 别说开源项目了，就是公司内部，也没见过单独提一个 PR 的。即使提一个 PR 去改，就至少得把那个 module 全改完。毕竟代码不是文学巨著，代码的美丽不在乎错别字与否，而是能跑起来。

更别说改了个 typo 就像强行夸大自己的成果的恶心人了。

hacktoberfest 骗 T 恤衫正常招数。

其实只要合并多个修改到一个 PR，并且注明是 fix typo only，这类 PR 也是没啥大问题。

我倒是觉得无伤大雅，假如某开源作者哪一天真因为收到一堆 typo issue 很烦的话，那他最先做的应该是下载一个代码拼写检查工具。

楼主：“要是真有一天开源项目的作者看到自己的项目里一堆这种 pr 刷屏，好几个 merge 抢着改 typo，那会是啥感觉？”
开源作者：“淦，丢人丢大发了”

只看文章，感觉就是用表情包编出了一篇 gpbt 的水文，看到就烦。

“技术 Blogger 离开表情包就不会写作了吗？”

现身说法，我懂个锤子的 PR

也是所谓的 typo pr 吧，但当时是我看文档，被坑了，才想着去改的

https://github.com/DHI-GRAS/terracotta/pull/168

写了篇感慨，还被维护者看到了，“第一次”遇到这样友善的维护者，很感激！

https://blog.yuhang.ch/posts/stories/first-pull-request/

话说回来，目的性很强的去做感觉还是怪怪的

这种玩法我最早看到是在 4 年前了，记得那会逼乎有个网红“程序员”妹子叫秋风，回答里能看到她的 github 上都是参与了各项知名项目，包括大名鼎鼎的 angular，反正 github 首页的项目 star 数没有一个低于一千的，后来被人扒发现这纯粹就是改 markdown 提 issue/PR 的水货

pr 是可以的，issue 就没必要了。

作者好像是开课吧的讲师，提 typo issue 这件事本身是好的，但是文章里那种沾沾自喜的语气，以及可能会导致一部分人专门到各种开源项目下蹭 contributor 的后果，就还挺恶心的。

@cassyfar 您就不是自以为是了？好笑 您就不是您觉得我觉得哈哈哈哈哈

如果想参与的那么多 help 的 PR 不是在那儿放着吗

我觉得就和 cr 的时候，指出拼写错误一样。即便这个拼写不影响意思，但是指出来了，我就会改。毕竟还能给人家说，你指的不对，我没拼错？
但是没指出来，没看到，那就不改了

@pliex #65 我是说那篇文章的作者，不是说你

@yuhangch 看了一眼你的链接，你这个严格来说，不算 typo，你这个是正确性的内容。而不是 简单的 typo 毋需妄自菲薄

菊言菊语

浓浓的菊厂风

早些时候不就专门抨击过菊厂的某个资深程序员吗？

@wtf12138 哎呀 尴尬了 碰瓷 element 的太多 被误伤好几次 神经大条了 哈哈哈和

@Geo200 对妹子比较感兴趣，有她的链接么？