社区反馈闭环

开源组件库的质量来自持续反馈。YH-UI 将 Issue、Discussion、PR、文档和发布记录纳入同一个闭环，确保问题能被看见、分类、修复和复盘。

反馈渠道

渠道	适用场景
GitHub Issues	Bug、功能请求、文档问题、兼容性问题
GitHub Discussions	方案讨论、设计提案、使用经验
Pull Requests	修复、文档补充、新功能实现
Changelog	发布说明、迁移提示、风险说明

Issue 模板建议

一个高质量 Issue 应包含：

• 问题类型：bug、feature、docs、question。
• 当前版本、Vue 版本、构建工具、浏览器或 Node 版本。
• 最小复现链接或代码片段。
• 实际行为和期望行为。
• 截图、控制台错误或构建日志。
• 是否愿意提交 PR。

分类和优先级

优先级	条件
P0	构建失败、SSR 崩溃、核心组件不可用、安全问题
P1	高频组件严重行为错误、数据丢失、破坏性回归
P2	明确 bug、兼容性问题、重要体验问题
P3	文档优化、低频场景、增强建议

处理流程

1. Triage：确认是否可复现，补充标签和优先级。
2. Design：涉及 API、视觉、Breaking change 的问题先讨论方案。
3. Implement：PR 聚焦单一问题，并补充测试或文档。
4. Verify：运行相关单测、构建、docs playground 或 consumer smoke。
5. Release：进入 changelog，必要时补迁移说明。
6. Review：复盘是否需要新增测试、文档或 lint 规则防止复发。

PR 要求

• 说明为什么改、改了什么、如何验证。
• 包含必要的测试或文档。
• 不混入无关格式化。
• 对公开 API 的改动必须说明兼容性。
• 对视觉变化建议附截图或 playground 链接。

维护者响应目标

类型	首次响应目标
安全或阻塞问题	24 小时内
可复现 bug	3 个工作日内
功能请求	7 个工作日内
文档问题	7 个工作日内

这些目标是协作承诺，不是绝对 SLA。维护者会优先处理影响面更大的问题。

关闭条件

Issue 可以在以下情况下关闭：

• 已修复并发布或合并。
• 缺少复现且长期无反馈。
• 与项目目标不匹配。
• 已有重复 Issue。

关闭时应尽量说明原因，并链接替代方案或相关问题。