[RFC] 项目可持续：Discussions First

[ocetars]

项目可持续 RFC ：Discussions First

背景与问题

如图为 2025.12.30 13:00 时刻本项目的 Issue 类型和数量分布，当前仓库的开放 Issue 中 enhancement 占比最高，其次是 bug，同时存在一定数量的无标签 Issue。

在维护资源有限的情况下，bug 类工单本身已存在较高的待处理量；与之相比，大量未经过问题定义与范围收敛的 enhancement 往往难以直接进入排期与交付。
同时，目前已经针对 bug 采用 stale 作为自动化清理措施，通常可以有效处理长期无反馈/不可复现的 bug 条目；但对于以想法为主、缺少可验收标准的 enhancement，则极其容易长期堆积。

建议遵循 GitHub 最佳实践，将 Issue Tracker 定位为开发执行队列（工单）：每个 Issue 应是范围清晰、可复现、可验收、可分配的工作项。

即：将"想法/需求/提议"从 Issue 入口分流至 Discussions，让 Issue 回归可被执行与分配的工作项。

这种 Discussions First 的分流方案，已被 Next.js、Node.js、Tailwind CSS 等众多 100K+ star 开源项目成熟验证并采纳：GitHub Discussions 官方社区示例

为便于直观理解，该方案已在我的个人仓库中做了完整模拟落地（包含 Issue 入口分流与 Discussions 承接），可先查看实际交互路径与最终呈现效果：MangaColor-Banana Issues

方案概述

1) Issue：建议仅保留 Bug 类和发布插件入口

• Bug：继续使用 Issues，并使用结构化表单收集复现信息。
• 重定向分流：通过 .github/ISSUE_TEMPLATE/config.yml 配置 blank_issues_enabled: false，并通过 contact_links 将需求/想法/问答重定向至 Discussions，实现从 Issue 到 Discussion 的分流效果。

2) Discussions：承接需求/想法/展示/问答

建议将原本容易落入 enhancement 或无标签的内容引导至 Discussions。

3) 从 Discussion → Issue：建议由开发组人工"收敛后转化"

开发组认为一项 discussion 达到"可执行"标准后，手动将 Discussion 转为 Issue（并补齐标签/负责人）。

**变更落地参考：**相关改动已整理为一个 PR：[Draft PR](#4261)

Discussions 类型（Categories）建议

建议设置以下 Discussions 类型（Categories）：

• Q&A：描述文案：使用问题与排错问答 / Usage issues and troubleshooting Q&A
• Ideas：描述文案：你对现有功能的想法或对新需求的讨论 / Your thoughts on existing features or discuss new requirements
• Show：描述文案：在这里展示和宣传你的插件，或者其它有关 Astrbot 的一切 / Showcase and promote your plugins here, or anything else about Astrbot.

补充说明：Discussion 的发起也可配置自定义 YAML 格式模板（类似 Issue templates），通过结构化表单引导用户提供更高质量的问题描述和想法内容，具体内容也涵盖在了上述 #4261 PR 中。