Tomas Vondra：体谅他人的时间
内容提要
作者以Postgres社区为例，建议开源贡献者珍惜评审者时间：提交前尽量完成可自行完成的修改；实验性补丁应标注WIP、记录已知缺陷并明确所需反馈；大型补丁应拆分为小片段，便于增量开发和评审。核心原则是不要让他人承担本可自己完成的工作，避免浪费社区评审资源。
延伸解读
评审者如何选择补丁
文章指出，开源社区中评审者时间有限，他们会在多个补丁中做选择，核心问题是“这是否高效利用我的时间”。因此，作者在提交补丁前会考虑如何让补丁成为评审者的高效选择。这提醒贡献者，补丁能否被评审不仅取决于主题，还取决于是否节省评审者时间。
实验性补丁的正确提交方式
对于实验性或WIP补丁，作者认为完全可以分享，但必须明确标注，并记录已知缺陷和需要反馈的高层问题。这样评审者能进行高层级评审，而不是误做常规评审。文章强调，实验性补丁需要不同的评审类型，提前说明可以避免浪费双方时间。
大型补丁的拆分策略
文章提到，100KB到500KB甚至1MB的补丁很难被有效评审，因为评审者需要投入大量连续时间。作者建议将大补丁拆分为小片段，最好能增量开发：先加基础设施，再实现最小可行功能，然后逐步放宽限制。即使无法自然拆分，也可按修改区域人工拆分，以便评审者选择部分评审。
AI时代对评审资源的冲击
作者预计AI会加剧评审资源紧张，因为它能轻松生成大量看似合理的补丁和评审。尤其是“氛围编码”的补丁，作者可能无法回答相关问题。文章警告，如果持续浪费他人时间，贡献者的补丁会被移到待办列表末尾甚至被忽略。
Q&A
为什么开源贡献者应该珍惜评审者的时间？
因为评审者时间有限，他们也有自己的补丁要处理，可能只在空闲时间工作。评审资源是项目瓶颈，浪费评审时间会降低补丁被评审和合并的机会。
提交补丁前，作者应该做哪些准备工作来节省评审者时间？
作者应尽量完成自己能做的修改，比如修复已知的设计问题，而不是留给评审者。如果运行了静态分析工具，应先调查哪些问题是有效的，避免让评审者调查误报。
实验性补丁（WIP/PoC）应该如何提交才不会浪费他人时间？
应明确标注为PoC/WIP，记录已知的缺陷或未处理的情况（如用XXX/FIXME注释或README说明），并明确指出需要反馈的高层次问题，以便评审者提供有针对性的意见。
为什么大型补丁难以评审和提交？应该如何改进？
大型补丁（如100KB-500KB甚至1MB）需要评审者投入大量连续时间，可能一周，导致评审者不愿冒险，补丁容易被搁置。改进方法是拆分成小片段，可以按增量开发或按修改领域（如catalog、executor）拆分，便于增量评审和提交。
作为提交者（committer），对补丁拆分有什么偏好？
提交者强烈偏好增量开发的拆分方式。这样初始部分可以清理、打磨并提交，后续部分逐步跟进，即使跨版本也能让用户尽早受益。一次性提交巨大补丁几乎不可能，因为需要大量时间进行预提交审查。
AI生成补丁对开源社区评审有什么影响？
AI使得生成大量看似合理的输出（补丁、评审等）变得容易，这会加剧评审需求，而好的评审资源本就稀缺。特别是“凭感觉编码”的补丁，作者往往无法回答相关问题，进一步浪费评审者时间。
