我建议你补缴，不需要熟人，自己去问政策

最近在 github 提 PR 时已经遇到了几次 coderabbitai 了，体验还不错

@Donaldo #107

> 独立完成 fork brunch commit push pr 这一套流程

关于这一点我认为你想复杂了。她更可能是在文档页点击 Edit this page （ https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/ ），就自动 fork 了，Edit 后就可以在网页上提交，提交后就会自动提示 PR 到上游，整个流程都可以网页上完成。因为看她 PR 的 commit 恰好是 GitHub sign 的（ GPG key ID: B5690EEEBB952194 ）。

@cinlen #111 确实，我当时看到主页也觉得是老油条演的。不过看她的评论区里她提到参与过阿里的文档项目，那可能是以前有过经验或者有朋友指导也说不定。

总之，论迹不论心吧，毕竟还没干出什么坏事。

@accelerator1 #112

> 她的这 pr 的修改内容是什么？你看了么？加个毫无意义的换行也算社区贡献？

有意义，页面都有变化。我也想问，你看了么？

> 最后这个 pr 合入了吗

提 PR 32 分钟后被 LGTM：
https://github.com/kubernetes/website/pull/47399#issuecomment-2275301619

两天后被 approve 并 merge ，并且提醒她以后注意避免 trivial edits：
https://github.com/kubernetes/website/pull/47399#issuecomment-2281231488

现在这个小小的变化已经被应用到文档站：
https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

所以她已经确确实实地对 kubernetes 项目做出了开源贡献，尽管是很微小的贡献。

> 开源项目要真是大量这种 pr ，那才是毒害社区

是，但按照我的经验，社区对于新人会更宽容（再次提醒，这是 kubernetes/website 文档 repo ），她要是未来不听劝继续提这样的 PR ，才应该被社区批评——没错，她的另一个 PR 虽然很不恰当，但由于是和这个 PR 同时提的，所以具有相同的“新手度”，依然应当被宽容对待，事实上 kubernetes 也是这么做的： https://github.com/kubernetes/website/pull/47414#issuecomment-2277646230

> 真心是想做开源贡献的人不会提这种 pr 的，你是多瞧不起 985 的含金量？

我衷心希望你没有在维护任何开源社区，我认为任何开源社区有你这样的想法都不会是好的社区。

@julyclyde 不赞同，举例一个场景：一个用户配置或者被迫配置了奇怪的 DNS 导致 AAAA 被丢弃，但一些 APP 又会有内置的解析，导致用户可能在意识不到的情况下依然在使用 IPv6 访问，而当用户使用这样的查询 IP 的网页服务时，我的方案可以消除掉这类影响，覆盖更多场景

”想读书的人，不会找不到目录“到底源自哪本书？看到很多次了

E5 订阅扩容上限是不是 25T ？

@julyclyde #8

需求是一个查 IP 的网站，没办法自定义解析，那么 API 用域名就会增加对解析服务的依赖。例如有的人会在 adguardhome 里屏蔽掉 AAAA ，而实际上设备有 IPv6 。所以直接用 IP 当 hostname 的 API 可以去掉这层依赖。

@julyclyde #4

1. 我认为这个需求比较稳妥的办法是干脆跳过解析这一步，即直接访问 IPv4/IPv6
2. 2024 年提供服务却没有 HTTPS 保护是 **绝不应该的**，所以要给 IP 申请证书

同 #1

另外我觉得更稳妥的办法是给 IPv4 申请个证书，例如 https://1.12.12.12/

中文的 AI 、独立开发相关内容看 V2EX 、X 这些平台更丰富更专业吧？

对我来说，这些号大都无趣或遥远，就像这个白叔，他到底是计算机相关还是独立开发者还是有趣的博主？我就觉得他既不计算机又不开发还不有趣，那几个富婆富哥发的内容更是让我觉得没劲透了。我觉得对于一个社交账号除了关注博主的 title ，更应该关注 Ta 在这个平台实际发的内容，否则不如追到 Ta 真正在运营的平台去关注。

不点进来我都没想到国区还上架过 Telegram

@yanyao233 #36

其实我觉得还好，k8s 文档有说明 trivial edits https://www.kubernetes.dev/docs/guide/pull-requests/#trivial-edits 。她第一个 PR 有截图有说明，很合理，毕竟可能真的没能力发现更多的错误，那只改一下发现了的错误是没错的。而她第二个 PR 才是不恰当的，不说明为什么改，但对于还没表现出屡教不改的新手来说，这也不是什么该被侮辱的滔天大罪。

根据我的使用经验，电池技术进不进步和 iPhone 也没啥关系，落后 Android 多少年？

没觉得这个 PR "不该提"，这个换行确实造成排版上的小问题，我觉得这类 typo PR 作为人生第一次来熟悉流程和获得正反馈很合适啊，何况这个 repo 是 kubernetes/website 不是 kubernetes/kubernetes 。至于说垃圾 PR 浪费维护者精力这种说法真的没意思，再次重复，这是 kubernetes/website ，我认为遵循它的 CONTRIBUTING.md 即可，例如：

- https://github.com/kubernetes/website/pull/46336/files
- https://github.com/kubernetes/website/pull/47175/files

提了第一个 PR 被 LGTM 了，在别的平台炫耀一下也无不妥，我第一次被 merge 也发朋友圈了。。。尽管这个人的平台主页确实怪怪的，更像引流的，但她不还没来得及干坏事么？万一真的就是一个喜欢这些形式的人呢？

至于追到 github 骂的人，我觉得素质很差，你去她炫耀的平台骂不就好了？从 github 角度，真正在污染环境的反倒是这些追过去骂的吧？

另外在这个 PR 下面评论的人，有些人甚至一个给开源项目的 PR 都没有，真论对开源的贡献还不如这个引流的吧？