外部贡献者评审要点
开源项目评审外部改动有其特殊性：作者不了解内部上下文，也未必熟悉项目惯例。评审时先对齐范围与贡献指南，再进入实现细节；表达上保持友好，把必须修改的项列成清单，让首次贡献者清楚下一步该做什么。
基本信息
| 前置对齐 | 先开 issue 讨论方案与范围，避免做完被拒 |
|---|---|
| 必查项 | 测试、文档、变更日志与贡献者许可流程 |
| 沟通原则 | 描述自包含，外部作者看不到内部上下文 |
| 目标 | 让贡献者知道下一步，而不是被沉默拒绝 |
典型使用场景
- 首次贡献者：给出规则链接，而不是口头习惯
- 范围过大的改动：先拆成可以独立合并的小步
- 与项目方向不符：尽早说明并给出替代方案
- 缺少测试与文档：列出必须补齐的清单
- 长期无人处理的改动：定期回复状态，避免沉默
外部改动的必查项
- 是否有对应的 issue 或讨论记录
- 测试是否覆盖新增行为
- 文档与变更日志是否同步
- 许可与贡献者声明是否完整
回复结构模板
回复结构模板
感谢贡献：说明哪一部分解决了实际问题。
范围说明：本次改动超出计划范围，建议先合入测试部分。
必须项：补一条集成测试；更新变更日志。
后续：完成后我会重新评审，预计一个工作日内回复。常见情形与处理方向
| 情形 | 处理方向 |
|---|---|
| 方案与项目方向不符 | 尽早说明并给出替代方案，避免继续投入 |
| 缺少测试 | 列出必须补齐的清单，并提供参考实现 |
| 格式与规范有差异 | 给出规范链接与自动修复命令 |
| 长期无人跟进 | 定期同步状态，明确是否继续推进 |
外部贡献者看不到内部上下文：评审描述要自包含，别用只有团队才懂的简称。
沉默关闭改动：伤害社区口碑，也让作者无从改进。