本文档定义 Shellsmith 的公开功能需求收集、统计和评审流程。目标是让用户能够清楚描述需求，让维护者以后可以快速了解需求背景、支持度和处理状态。
| 载体 | 职责 | 不负责 |
|---|---|---|
| GitHub Issue | 收集使用场景、讨论方案、用 👍 汇总公开支持度 | 承诺发布时间、保存敏感材料 |
| Issue 标签 | 表示需求分类和当前评审状态 | 代替评审结论说明 |
| 功能路线图 | 记录已采纳且准备实施的方向 | 收纳所有未经评估的想法 |
当前不启用自建需求数据库、GitHub Discussions 或 GitHub Projects。有效需求积累到需要集中排期时，再评估是否启用 Projects；需要开放式方案讨论时，再评估 Discussions。
用户通过 功能建议表单 提交需求。提交前应先搜索已有 issue：
- 已有相同需求：使用 👍 表情表示支持，并在有新信息时补充具体使用场景。
- 需求相近但目标不同：说明差异，避免用一句“同上”创建重复 issue。
- 安全漏洞或攻击细节：不得公开提交，改用 GitHub Security Advisories。
- APK、证书、密码和业务代码：不得上传到公开 issue。
功能建议表单应持续收集以下信息：功能分类、使用场景、当前问题、期望结果、影响程度、相关平台和替代方案。
每条功能建议保留 enhancement 类型标签，并使用一个评审状态标签：
| 状态标签 | 含义 | 下一步 |
|---|---|---|
待评估 |
新提交，尚未完成范围、价值和风险判断 | 检查重复项并补齐信息 |
需要更多信息 |
缺少真实场景、边界或复现依据 | 等待提交者补充 |
已采纳 |
方向认可，但尚未进入明确开发阶段 | 必要时同步路线图 |
计划中 |
已进入近期计划或正在实现 | 关联提交或拉取请求 |
暂不考虑 |
当前不实施，但保留需求和讨论记录 | 说明原因后关闭或保留 |
状态发生变化时，应移除旧状态标签，避免一条需求同时处于多个状态。重复需求使用 GitHub 的 duplicate 标签，并链接到主 issue；支持票统一累计在主 issue。
公开支持度使用 Issue 首帖的 👍 数量。评论数量、其他表情和重复 issue 数量不直接作为票数。
票数仅表示公开关注度，不等于开发承诺。评审还需要综合考虑：
- 是否符合 APK 加固工具的产品范围
- 是否有明确且可复用的真实场景
- 安全性、兼容性和维护成本
- 对现有用户和发布节奏的影响
- 是否已有可靠替代方案
- 实现和长期测试成本
维护者可以在票数较低时采纳重要的安全或兼容性需求，也可以拒绝票数较高但超出范围、风险过高或不可持续维护的需求。
- 新需求自动添加
enhancement和待评估。 - 检查是否重复、是否包含敏感信息、描述是否足够。
- 信息不足时改为
需要更多信息，明确列出还需要什么。 - 完成评审后改为
已采纳或暂不考虑，并在评论中记录理由。 - 已采纳且进入近期开发计划时改为
计划中，同步到 功能路线图。 - 发布后关闭 issue，并在关闭说明中标注包含该功能的版本。
建议定期查看按 👍 排序的功能建议，但不要求固定周期。进行版本规划或累计出现多条新需求时，应集中评审一次。
满足以下任一条件时，可考虑增加自动化：
- 有效开放需求达到约 10～20 条，人工浏览难以比较。
- 需要跨多个版本集中排期和展示负责人。
- 用户经常提出需要长期讨论、尚不适合形成具体需求的想法。
届时优先顺序为：GitHub Projects 管理排期、GitHub Discussions 承载开放讨论。任何自动榜单都应直接读取 GitHub 数据，不另建投票账户或复制需求正文。