开源项目的会议如何记录和跟进

本文目录导读：

1. 第一阶段：会前准备（决定记录质量的50%）
2. 第二阶段：高效记录（使用结构化模板）
3. 第三阶段：快速发布与同步
4. 第四阶段：强力跟进（从记录到执行）
5. 最佳实践与常见陷阱
6. 推荐工具组合

开源项目的会议记录和跟进,核心在于高效、透明、异步协作，由于社区成员分布在全球各地、时间有限，会议记录不能只是流水账，而必须成为后续行动的驱动力。

以下是一套被广泛验证的实践方案,分为四个阶段：

第一阶段：会前准备（决定记录质量的50%）

开源项目中,没有参会的人比参会的人多，会前准备能让会议更高效。

1. 发布议题（Agenda）：

   • 在项目的公共论坛（如GitHub Discussions、邮件列表）或议题（Issue）中，提前24-48小时发布会议议程。
   • 格式建议：使用列表或表格，每一项标注提议人、讨论时长、期望结果（决策/信息同步/头脑风暴）。
   • 关键：如果有人无法参会，可以在会上提前发表评论，由记录员代为传达。

2. 指定角色：

   • 主持人：控制节奏，确保不跑题。
   • 记录员：负责记录关键点，而非逐字稿，这个角色最好由了解项目背景的人担任。

第二阶段：高效记录（使用结构化模板）

不要试图记录每一句话,使用统一的模板，聚焦于“决策”和“行动项”。

推荐记录模板（Markdown格式）：

# 项目名称 - 第X次例会
- **日期**：YYYY-MM-DD
- **时间**：UTC 时间 / 北京时间
- **参会者**：@username1, @username2, ...
- **缺席者**（可选）：@username3
- **记录人**：@record_username
## 1. 上次会议行动项跟进
- [x] @userA 已完成 PR #123 的代码审查。  *（关联最新进展）*
- [ ] @userB 负责的文档翻译 (Issue #456) 仍未完成，延期至下周。 *（状态更新）*
## 2. 本次议题
### 2.1 议题一：关于新功能X的技术方案
- **讨论摘要**：社区成员 @dev1 提出了使用微服务的方案，@dev2 认为当前单体架构更合适，因为维护成本低。
- **关键争论点**：性能 vs 运维复杂度。
- **最终决策**：（如果没有达成决策，写“待定”）
  - 决定：**暂不引入微服务**，先通过优化现有代码提升性能。
  - 理由：团队当前人力不足以维护微服务基础设施。
### 2.2 议题二：版本发布计划 v2.0
- ***：预计下个月15号发布RC1。
- **阻塞项**：需要 @qa_user 完成安全审计。
## 3. 新的行动项（Action Items）
- **责任人** @userA 在 **48小时内** 提交优化PR (关联 Issue #789)。
- **责任人** @userB 在 **下周五前** 完成安全审计文档初稿。
- **所有人** 在 **明日中午前** 在对应议题下投票选择会议时间。

记录原则：

• 写结论，不写过程：只记录“最终决定是A”和“支持/反对的核心理由”，不写“张三说了XXX，李四反驳了XXX”的流水账。
• 写分歧，不写妥协：记录未解决的分歧点，方便后续异步讨论。
• 关联链接：每个行动项必须关联一个具体的GitHub Issue或Pull Request，没有Issue的行动项几乎等于没存在过。

第三阶段：快速发布与同步

会议结束后,记录要像代码一样快速提交。

1. 发布位置：

   • 首选：在GitHub仓库的 wiki/ 目录下新建一个 Meeting-Notes 文件夹，或直接使用 docs/meetings/ 目录，通过Pull Request提交，这样记录是版本化的，可追溯。
   • 或者：创建一个GitHub Issue为 [Meeting Notes 2024-XX-XX]，并将此Issue置顶，这是最轻量的做法。
   • 同步到：在Slack/Discord频道、邮件列表中发送简短通知和链接。

2. 发布时限：

   • 会议结束后 2小时内 发布草稿。
   • 24小时内 根据参会者反馈修正，并催更行动项。

第四阶段：强力跟进（从记录到执行）

记录不被跟进,就是浪费大家的时间。

1. 自动化催办（推荐）：

   • 利用GitHub Actions，当你合并包含会议记录的PR后，可以触发一个Workflow，自动解析Action Items表格中的 - [ ] @user，并为每个责任人自动创建一个GitHub Issue包含 [Action] 标签，内容包含截止日期和原始会议链接。

2. 下次会议的起点：

   • 每次会议的第一件事,不是讲新内容，而是逐一过一遍上次会议的行动项（State of the union）。
   • 如果行动项过期：不要批评，直接问“是否需要帮助？还是这个任务不再重要？”并决定是延期还是删除。

3. 异步回滚：

   如果有人无法参会,可以要求他们在会前或会后，在对应Action Item的Issue下更新进度，这比会议中点名要高效。

最佳实践与常见陷阱

推荐工具组合

• 记录编辑：项目内的Markdown文件 + VS Code / GitHub Web Editor。
• 发布与跟踪：GitHub Issues（作为记录载体） + GitHub Projects（看板管理行动项）。
• 自动提醒：Slack/Discord Bot + GitHub Actions。
• 会议录制（可选）：如果社区规模大，可以录视频上传YouTube，并在会议记录底部注明“视频见链接”。

一句话总结：开源会议的记录不是为了“回忆”，而是为了“生成可执行的Issue”。 如果你的会议记录中没有出现新的GitHub Issue或PR号，说明这次会议可能没有解决实际问题。