发表于 2024年8月25日1年前 前一段时间，有一个小红书的博主，向大家展示自己向 Kubernetes 提交一行文档错误修复的 PR ，并获得批准的过程。那时候，不少人指责博主这么做是在浪费开源软件维护者的时间。 值得一提的是，有一种观点认为，提交这一类 PR 的人，并不是真心愿意参与开源项目，只是期盼未来出现形如 HNS 或者 STRK 这样的加密货币空投，发放给在开源社区有过贡献的人，从而让自己也获取数百美元的空投加密货币，带来经济利益。 在过去，即便提交的 PR 很细小，维护者也会为了鼓励这些人再次来参与贡献，从而走完正常的 PR 审批流程，最终让这些 PR 获得通过。 如果有加密货币空投这个因素需要考虑的话，那么作为具有一定数量的 star 的开源软件维护者，是否需要在 PR 审核的策略上，做出一些调整，把这些并非真正参与开源项目，而是博取针对开源贡献者的加密货币空投的人，来过滤掉？但是这也没有一个有效的策略，可能需要对这个人以及这个 GitHub 账号进行深入的背景调查，才能得出这个人对这个开源项目的忠诚程度。
前一段时间，有一个小红书的博主，向大家展示自己向 Kubernetes 提交一行文档错误修复的 PR ，并获得批准的过程。那时候，不少人指责博主这么做是在浪费开源软件维护者的时间。
值得一提的是，有一种观点认为，提交这一类 PR 的人，并不是真心愿意参与开源项目，只是期盼未来出现形如 HNS 或者 STRK 这样的加密货币空投，发放给在开源社区有过贡献的人，从而让自己也获取数百美元的空投加密货币，带来经济利益。
在过去，即便提交的 PR 很细小，维护者也会为了鼓励这些人再次来参与贡献，从而走完正常的 PR 审批流程，最终让这些 PR 获得通过。
如果有加密货币空投这个因素需要考虑的话，那么作为具有一定数量的 star 的开源软件维护者，是否需要在 PR 审核的策略上，做出一些调整，把这些并非真正参与开源项目，而是博取针对开源贡献者的加密货币空投的人，来过滤掉？但是这也没有一个有效的策略，可能需要对这个人以及这个 GitHub 账号进行深入的背景调查，才能得出这个人对这个开源项目的忠诚程度。