用 GitHub Discussion 组织会议
我们用 GitHub Discussion 在会前异步收集议题，让主持人和参会者共同维护同一条记录。它天然按时间排序、支持讨论回帖、可以给帖子投票，还能把已解决的问题「标记为答案」。
适用多种会议：
- Sprint 复盘会议 —— 核心团队在会前提交「做得好 / 待改进 / 行动项」。
- Office Hour 会议 —— 面向公开，参会者在会前把想问的问题贴上来。
为什么用 Discussion 而不是别的
| 需求 | Discussion 是否满足 |
|---|---|
| 会前异步收集议题 | ✅ 帖子 / 评论 |
| 时间有序、留存历史 | ✅ 自带时间戳 |
| 主持人与参会者共同编辑同一条记录 | ✅ |
| 议题投票排序 | ✅ 👍 / upvote |
| 标记「已解答」 | ✅ Q&A 类别 |
| 给每条议题打类型 / 字段 / 看板（type / field / project） | ❌ 这些是 Issue 才有的能力 |
什么时候改用 Issue
Discussion 的评论不支持类型、字段、项目看板这类结构化元数据 —— 那些是 GitHub Issue（及 Projects）的能力。如果某条议题需要跟踪到关闭（指派负责人、设优先级、进看板），会后把它转成 Issue 跟踪，Discussion 页面上方的 "Convert to issue" 一键完成。
如果迭代过程中Discussion出现明显短板，可以考虑升级为Issue
分类（Categories）设置
在仓库的 Discussions → Categories 里：
- Sprint 复盘 —— 用
Show and tell（开放讨论）格式。 - Office Hour —— 用
Q&A（问答）格式，这样可以「标记为答案」。
Sprint Retro 复盘会议
一个 Sprint 建一个 Discussion，标题带上日期，例如 Sprint 复盘 2026-07-01。
会前
每位成员在该 Discussion 下发表评论，按三类填写：
✅ 做得好的（Went well）：
⚠️ 待改进的（To improve）：
🎯 行动项建议（Action items）：对认同的观点用 👍 投票，方便会中按热度排序。
会中
主持人按票数从高到低过一遍，逐条讨论。达成一致的改进点整理成行动项。
会后
把每个行动项用 "Convert to issue" 转成 Issue，指派负责人并进看板跟踪；在 Discussion 里回帖贴上对应 Issue 链接，形成闭环。
Office Hour 会议
用 Q&A 类别，一个 Office Hour 场次建一个 Discussion，标题带日期，例如 Office Hour 2026-07-04。
会前
参会者把想问的问题作为评论贴到该 Discussion 下；相似问题可以用 👍 投票合并关注度。主持人会前浏览、排序，准备回答。
若希望每个问题都能单独「标记为答案」并独立跟踪，也可以让参会者每个问题各开一条 Q&A Discussion，代价是列表会更长。
会中 / 会后
主持人逐条回复，把解答的评论「标记为答案（Mark as answer）」，未讲完的问题留待下次或转成 Issue 跟进。
隐私与注意事项
涉及个案信息请勿公开发布
公开仓库的 Discussion 会被搜索引擎索引。通用问题（如「STEM OPT 的失业期怎么算」）放公开仓库没问题；一旦涉及客户 PII、个案细节、工资/签证具体材料，请改用私有仓库或私下渠道，不要贴到公开 Discussion。