开源项目维护：Issue 分流、版本边界与可复现信息

开源维护最耗时间的往往不是写修复，而是从不完整描述中判断问题属于用法、缺陷还是兼容性。流程要帮助贡献者补齐证据，也要保护维护者的时间。

Issue 模板只收必要信息

至少需要版本、环境、复现步骤、预期与实际结果。日志和最小示例先脱敏，不要求用户上传完整项目。无法复现时直接说明还缺什么，不用自动化套话假装问题已经处理。

标签用于路由，不等于修复承诺。确认缺陷后再标出受影响版本、修复分支和验证方式；安全问题进入私密披露渠道。

先复现，再讨论方案

维护者应尽量把问题缩到最小输入，并记录构建与运行命令。修复补丁需要对应测试，避免下个版本重新出现。涉及公共 API 时，兼容性、迁移说明和废弃周期一起评审。

新 Issue -> 信息完整性 -> 复现 -> 分类 -> 修复/文档/关闭 \-> 需要补充

自动化适合做分流，不适合代替判断

机器人可以检查版本字段、重复问题和贡献协议，但误判时要允许人工改回。自动关闭前给出清楚理由与恢复入口。

回看重复问题、长期缺复现信息和版本文档造成的误报，比追求“处理数量”更有价值。社区运营不是把队列清空，而是让问题从出现到结论都有清晰路径。