ant-design Ant Design Issue 回复规范
目标
一、保持社区活跃 - 让用户反馈被及时响应，提升用户参与感和满意度。
二、提高处理效率 - 减少 open issues 和重复 issues，保持 issues 区整洁有序。
核心原则
开源项目的用户和维护者之间并不是甲方和乙方的关系，issue 也不是客服。处理 issue 时抱着『一起合作来解决问题』的心态。
基本规则
一、首次回复
对满足以下所有条件的 issues 进行回复：
- Issue 状态为 open
- 没有人类维护者（MEMBER/OWNER/CONTRIBUTOR）回复过
二、检查已回复的 Issues
对于已有 MEMBER/CONTRIBUTOR 回复的 issues，也要检查是否处理妥当：
需要关注的情况：
- 维护者已提出问题/解决方案，但用户**长时间（7天以上）**未回复
- 问题已明确被解决（用户确认或版本已修复）
- 维护者已说明这不是 bug，但 issue 仍然 open
处理方式：
- 用户长时间未回复 → 关闭 issue 并留言说明
- 问题已解决 → 关闭 issue
- 使用问题但已提供解决方案 → 关闭 issue
注意： Inactive 标签只表示近期无活动，不代表已解决，仍可回复。
⚠️ 语言政策（必须严格执行）
判断规则：只看 issue body 原始内容，忽略后续评论中使用的语言
判断流程：
1. 查看 issue 的原始 body（第一个帖子内容）
2. 检查 "What is expected?" 和 "What is actually happening?" 部分的语言
3. 如果是英文 → 用英文回复
4. 如果是中文 → 用中文回复
常见误区：
- ❌ 不要因为 issue-helper 模板是中文就用中文回复
- ❌ 不要因为后续评论使用了某种语言就跟随
- ❌ 不要因为 dosubot 使用了某种语言就跟随
- ✅ 只看 issue 作者在 body 中描述问题时使用的语言
示例：
Issue body:
"What is expected?" → "22.01.2026" (英文)
"What is actually happening?" → "dont work datepicker..." (英文)
正确做法 → 用英文回复
保持友善和耐心，即使用户语气不太好。
Issue 类型
Issue 列表主要用于跟踪 Bug 报告 和 功能请求。
使用问题的建议渠道：
- 常见问题
- StackOverflow（英文）
- SegmentFault（中文）
处理 dosubot 回复
如果 dosubot 已经回复过：
- 审核回复的准确性
- 正确 → 确认背书："感谢 @dosu 的分析，确认这是正确的解决方案。"
- 不正确 → 提供更正："感谢 @dosu，但需要补充说明..."
- 完整正确 → 无需额外回复
使用 @dosu（而非 @dosubot） mention 机器人。
Issue 分类处理
Bug 报告
首先检查版本：
- 老版本 + changelog 中已修复 → 引导用户升级验证
- PR 已合并但新版本未发布 → 告知用户等待新版本发布
检查重现链接：
- 缺少/无关 → 添加
🤔 Need Reproduce，请求提供 - 有重现 + 确认 bug → 添加
🐛 Bug标签
功能请求
- 添加
💡 Feature Request标签 - 描述模糊 → 询问使用场景和期望 API
处理功能请求时，先排查现有能力再讨论新增：
- 先查现有 API — 用户提需求时常因"找不到"而误以为"没有"。收到 feature request 时，第一反应应是"我们是不是已经有这个了"，而非"怎么实现它"。搜一下相关组件的 props、文档、已有 issue，确认未被现有功能覆盖。
- 关注命名可发现性 — 如果功能已存在但用户找不到，问题的本质不是缺功能而是 API 可发现性差。此时应该：向用户指出已有 API 并附代码示例；同时反思文档是否需要补充搜索关键词或交叉引用（如用户搜
mapping但 API 叫fieldNames，文档中应关联这两个词）。 - 检查跨组件一致性 — 用户会从一个组件的 API 类推另一个。同一概念在不同组件用不同命名（如 Table 的
rowKeyvs Select 的fieldNames），会制造认知负担。如果发现用户因跨组件命名不一致而困惑，记录下来作为后续 API 一致性优化的参考。 - 用提问引导而非否定 — 确认已有功能后，不要直接说"我们已经有这个了"然后关 issue。用提问式引导让用户自己确认："看描述这个需求好像可以用
fieldNames实现，是我理解的不对吗？"——既帮用户解决问题，又保护了用户面子。用户确认后再关闭。
使用问题
你可以尝试解决和回复使用问题：
- 查阅文档，提供解决方案和代码示例
- 如果能解决，直接回复帮助用户
- 如果用户描述的问题其实是现有 API 已覆盖的场景，用提问式引导："这个需求看起来可以用
xxxprop 实现，是我理解的不对吗？"——比直接甩文档链接更友好
也可以引入 AI 帮助解答：
@docu- GitHub Copilot 文档助手@Copilot- GitHub Copilot
回复示例：
感谢反馈！这是一个使用问题，让我尝试帮你解答：
[提供解决方案和代码示例]
参考文档：https://ant.design/components/xxx
如果以上方案不能解决问题，可以尝试 @dosu 或 @Copilot 获取更多帮助。
若无法解决，引导用户到其他渠道：
FAQ 问题
查找资源顺序：
- 带
❓FAQ标签的 issues - 组件文档 FAQ 部分
- 常见问题汇总
Bug vs Feature Request 分类
| 类型 | 特征 |
|---|---|
| Bug | 使用现有功能，行为不符合预期；之前正常现在坏了 |
| Feature Request | 需要目前不存在的新能力 |
示例：
- Cascader onFocus 不触发 → Bug（现有功能不工作）
- 添加 DatePicker 键盘导航 → Feature Request（新能力）
不确定时归类为 Bug
处理重复 Issues
- 找到原始 issue
- 回复："Duplicate of #xxxx"
- 关闭 issue
关闭 Issues（需谨慎！）
关闭前必须检查：
- ⚠️ 确认使用正确的语言（参考语言政策）
可关闭：
- 重复问题
- 确定不是 bug（使用问题）
- 已解决
- 用户长时间未回复（7天以上）
关闭时保持礼貌，简要说明关闭原因即可。
不要关闭：
- 不确定是否是 bug
- 用户未确认解决方案有效（且未超过等待时间）
- 有效的功能请求
- 正在活跃讨论中的 issue
禁止承诺
- ❌ 不要承诺发布日期
- ❌ 不要说"我们会添加这个功能"
- ✅ 应该说："这是一个合理的需求，我们会考虑。欢迎社区贡献。"
何时不回复
- dosubot 已提供完整正确答案
- 无法确定正确的回复内容
- Issue 正在活跃讨论中
检查已回复 Issues 的流程
对于已有维护者回复的 issues，按以下流程检查：
1. 确认回复语言正确（⚠️ 只看 issue body 原始语言）
2. 查看维护者的最后一条评论
├─ 是提问/请求更多信息？
│ └─ 用户是否超过 7 天未回复？
│ ├─ 是 → 检查语言 → 关闭 issue 并留言
│ └─ 否 → 跳过
├─ 是说明解决方案？
│ └─ 用户是否确认解决？
│ ├─ 是 → 检查语言 → 关闭 issue
│ └─ 否，且超过 7 天 → 检查语言 → 关闭 issue 并留言
└─ 其他情况 → 跳过
语气和风格
- 保持友善、耐心和专业
- 尽可能提供代码示例
- 引用文档链接
- 对新人友好，鼓励社区参与
交互流程
当用户要求处理 issues 时，采用「先草拟、后确认」的两阶段流程：
第一阶段：总览 + 草拟方案
- 使用
gh issue list拉取指定范围的 open issues - 对每个 issue 获取详情（body、comments、labels）
- 对每个 issue 给出处理方案，包括：
- 分类（Bug / Feature Request / 使用问题）
- 当前状态（无人回复 / 维护者已回复 / 等待用户反馈 等）
- 处理建议（需要回复 / 可以关闭 / 无需操作 / 等待中）
- 如果需要回复：草拟回复内容（含语言判断、正文、代码示例）
- 标签操作（添加/移除哪些标签）
- 是否关闭 issue
- 将所有方案一次性呈现给用户，不要直接操作
第二阶段：讨论和确认
- 用户可以对任意 issue 的方案提出修改意见
- 根据反馈调整方案，直到用户满意
- 用户确认后执行操作（评论、加标签、关闭等）
- 如果用户说「就这样」或类似确认，直接执行
关键原则：先草拟完整方案，等用户讨论确认后再执行。不要未经确认就回复或关闭 issue。
参考资源
详细标签列表和资源链接请参阅 references/labels-and-resources.md