开源代码： 社区的 PR 最终结果是，它们 99% 的时间都是糟糕的。 即使在看起来像是一个好的 PR 的情况下，也会有可疑的地方。 这会占用团队的时间。 我们必须准确重现这个 bug（因为在问题/PR 中没有步骤） 有一个 UI 变更，但没有前后截图/视频 代码很糟糕 - 我们需要拉取代码，重构/清理，之后再验证 有些测试根本没有测试任何东西 - 例如，它们总是通过，即使你故意把 bug 加回去 归根结底，大多数 PR 不值得花时间去认真审查。在糟糕的实现情况下，我们会选择从头开始自己修复/实现功能。 话虽如此，优秀的开源软件（OSS）人员仍然会脱颖而出，他们的贡献者会被合并，他们会获得更多的信任，以便能够进行更大的贡献。 即使我们合并了社区的贡献，他们在合并后也不拥有代码 - 如果出现致命的 bug，而我们对新代码并不完全理解怎么办？作为开源贡献者，消失一个月是完全可以的。但这是我们必须考虑的风险。 归根结底，团队必须照顾好这个花园，并执行一定程度的质量控制，有时这包括不合并看起来 80% 可以的 PR。 很多 PR 会说 '修复事情 紧急 这对每个人都造成了破坏 现在回滚这个'，但随后链接的 '修复' 社区 PR 又破坏了成千上万的其他东西。