大家是怎么看待开源项目的 typo 类 pr 的

[kingcanfish]

我在学习某个知名框架源码的时候 发现某个函数的注释有个单词 typo, 但是注释嘛 也无伤大雅，纠结要不要提个 pr 这种 pr 好像又没啥水平 但是又怪打扰人家 maintainer 的，所以想问问大家怎么看待这种事

[ztm0929]

之前我有过类似的问题，得出的最合适的做法可能是先发起一个 issue 讨论看看，然后提出再看后续情况提起 PR 。

https://www.v2ex.com/t/1066865

[paradox8599]

正常提就行了吧，不改动其他东西光修一个 typo ，review 也没什么压力

[crackidz]

这类 Review 处理都很简单，直接提就行。但是如果你一连提一堆 typo PR 就不行了，属于骚扰了。如果你有多个其实考虑放到一个 PR 里，可以更好的解决问题。

[Sayuri]

我觉得这种 typo 类 PR 有可能是为了博取加密货币空投（如 HNS 、STRK 等）。一些人可能通过提交低价值的 PR 来增加开源贡献记录，从而获得更多空投机会。

建议维护者在处理这类 PR 时，观察提交者的历史贡献。如果他们经常提交类似的 typo 修复或其他轻量级的修改，而这些改动没有真正提升项目的质量或功能，那么就有可能是为了刷贡献记录。这种行为虽然对项目的影响不大，但如果动机不纯，可能需要引起注意。

[Kauruus]

提个 CI 的改进 PR ，直接用工具（例如 typos ）检查整个仓库的 typo 。而不是每个（或每几个） typo 提一个 PR 。

[yhxx]

直接提就行吧，别拿这个营销造人设感觉就没啥问题
有些网红会给自己立一个 xx 学姐 xx 开源项目贡献者的人设，结果点开一看全是这种就很烦
还有某公司那种已经过分到了直接被人家官方开喷别刷 KPI 的。。。

[Esec]

人工看过去能看的出错误，且没有歧义导致严重的后果，又手痒的话，翻翻他的 CONTRIBUTING.md ，以及主要贡献里曾经的注释语法错误是怎么处理的，以前大家欢迎路人发补丁大多因为是发邮件，而邮件格式又会有很大一部分礼貌用语，要是都标题 typo 正文 rt 的那肯定秒进垃圾邮件，应该还漏了不少细节，冷门项目也推荐先联系，搞这个还放代码出来大多数还是希望有个人来聊聊天的，带不带码是其次

[chendy]

正常提就行，没啥大问题作者直接 merge ，结束
利益相关：翻译 spring 文档的时候，给 spring 的文档修过一堆 typo 和格式错误，最后忘了哪位大神把我 pr 给拒了自己开了个 issue 把一大段有问题的文档都重新写了一遍

[GeekGao]

"但是注释嘛 也无伤大雅" 如你所言。这种注释 typo 是优先级最低的事项，除非你改动了 typo 附近的代码，不然，建议你不要自行修改，直接在讨论组联系相关的 maintainer 即可。

想起了前几年，某大厂员工给 linux kernel 修改 typo ，被社区大佬们和网友吐槽的故事了。。。

[GeekGao]

@Sayuri 想起某爱国品牌的员工行为了，2333