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

[cwp374240920]

原文链接，评论区一片叫好声说学会了这就去提... 个人觉得文章可能只是破事水，没啥产出硬产出提高曝光度，但是这也在一定意义上教会了某些人去提这种垃圾 issue，给作者徒增了不少破事，如何评价这种行为呢？ PS：作者不会是那个公司的吧？

[Rainshaw]

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

[datasone]

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

[rapiz]

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

[minami]

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

[datasone]

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

[NewTab12138]

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

[dasbn]

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

[learningman]

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

[iyear]

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

[g0thic]

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

[krixaar]

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

[gy0624ww]

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

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

[ChefIsAwesome]

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

[Jaosn]

这种就是 开课吧 的 lj

[cyrbuzz]

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

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

[xarthur]

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

[wolfie]

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

[Rainshaw]

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

[kuro1]

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

[Showfom]

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