第 7 章 Issue 规范
Issue 用于记录任务、Bug、实验和文档需求。所有非代码协作都通过 Issue 完成。
7.1 四类 Issue
| 类型 | 标签 | 适用场景 | 责任人 |
|---|---|---|---|
| Bug | `bug` | 运行错误、结果异常、编译失败 | Developer |
| Feature | `feature` | 新功能、算法改进、模块扩展 | Developer |
| Experiment | `experiment` | 实验验证、参数调优、对比 | Developer |
| Documentation | `documentation` | 文档缺失、格式、注释 | Developer / 维护者 |
7.2 模板字段
- Bug：问题描述 / 复现步骤 / 实际结果 / 预期结果 / 环境信息 / 测试数据 / 备注。
- Feature：需求描述 / 使用场景 / 验收标准 / 参考实现或论文 / 优先级（P0–P2）/ 备注。
- Experiment：实验目标 / 假设 / 方案设计 / 预期指标 / 前置条件 / 后置操作 / 备注。
- Documentation：问题描述 / 建议修改 / 关联代码或 Issue。
完整模板在 .github/ISSUE_TEMPLATE/。
7.3 生命周期
创建 → 维护者分类 + 打标签 + 分配 → 开发者接受
→ 开发中（建分支、关联 PR）→ 提交审核 → 合并 → 关闭（写说明）- 标题格式
[类型] 简短描述，例[Feature] 支持 RINEX 4.0。 - 维护者 2 个工作日内分类分配；P0 级 24 小时内响应。
- 开发时建对应分支，PR 里
Closes #/Refs #关联。 - 关闭须由负责人标记、维护者确认，并附关闭说明。
7.4 一事一 Issue 与 MVP 切分
- 一个问题 / 需求一个 Issue，不相关的拆开。
- 大功能拆成多个最小完整功能 Issue，每个对应一个完整 PR。
- 创建前先搜重；Experiment 关闭须附实验记录。
7.5 常见错误
| 错误 | 正确做法 |
|---|---|
| 不选模板直接写 | 按模板逐项填 |
| 标题不明确（如 `Bug`） | 用 `[类型] 简短描述` |
| 一个 Issue 描述多个问题 | 拆分为多个 |
| 不关联 PR 直接关闭 | 关联 PR 后关闭 |
| 关闭无说明 | 写明关闭理由 |
7.6 练手：提一个规范 Issue
在自己 Fork 的 Gitea 上练一个四类模板之一的 Issue，并与 PR 关联。
- Gitea 网页
Issues → New Issue，选一个模板（建议先提feature或documentation）。 - 标题写成
[类型] 简短描述，例[Feature] 成员卡片增加"年级"字段（反例只写Bug）。 - 按模板逐项填全对应字段（见 7.2）。
- 在第 2 关或第 6 关的 PR 里用
Closes #<本 Issue 号>关联，PR 合并后 Issue 自动关闭。
一事一 Issue，不相关的拆开；创建前先搜重；Experiment 类关闭须附实验记录。
目视自检（网页关）： 在 Gitea 上对照以下清单逐项确认即可（纯中文界面，无需脚本）：
- 标题为
[类型] 简短描述 - 按对应模板逐项填写；一事一 Issue
- 若有对应 PR，用
Closes #<Issue号>/Refs #<Issue号>关联