9月17日，openKylin社区将邀请单位会员相聚郑州，参加社区单位会员沙龙。对于关注国产操作系统、开源协作和产业应用的团队来说，这类线下交流的价值不只在于听分享，更在于把真实需求、使用经验和合作想法带到同一张桌子上讨论。
把沙龙当成一次技术对接
单位会员通常同时关心几个问题：openKylin在实际业务中的适配情况如何，团队如何参与社区协作，现有项目能否形成更稳定的上下游连接，以及企业或机构的反馈如何进入社区后续建设。
因此，参会准备不必停留在“到场听会”。可以提前整理一页材料，内容包括当前使用的系统版本、适配过的硬件或软件、遇到的兼容性问题、希望社区支持的方向，以及能够贡献的代码、测试、文档或场景资源。材料不需要复杂，但要有具体事实和可讨论的问题。
会前准备：把问题写成可交流的清单
建议在出发前完成以下准备：
- 明确本次参会人员，以及每个人负责了解的主题。
- 汇总团队当前使用 openKylin 或相关开源组件时遇到的问题。
- 准备一个真实案例，说明系统在业务、教育、科研或行业场景中的使用方式。
- 列出希望认识的伙伴类型，例如硬件厂商、软件开发团队、集成服务商或高校机构。
- 为会后跟进预留负责人和时间，避免交流结束后信息无人整理。
可以用一个简单的 YAML 文件管理参会事项。下面的示例不依赖额外工具，保存为 salon-checklist.yml 后即可作为团队协作模板改造：
event:
name: "openKylin社区单位会员沙龙"
date: "9月17日"
city: "郑州"
team:
attendees:
- name: "参会人A"
focus: "系统适配与技术问题"
- name: "参会人B"
focus: "社区协作与合作机会"
questions:
- "当前项目最需要解决的兼容性问题是什么？"
- "哪些测试、文档或代码可以贡献给社区？"
- "会后需要与哪些团队继续沟通？"
actions:
- item: "整理使用案例"
owner: "参会人A"
status: "todo"
- item: "准备问题清单"
owner: "参会人B"
status: "todo"
- item: "建立会后跟进记录"
owner: "项目负责人"
status: "todo"
如果团队使用 Git 管理资料，还可以把清单和案例文档放在同一个目录中，通过提交记录保留会前更新和会后结论：
mkdir -p openkylin-salon/{cases,notes}
printf '%s\n' '# 参会问题清单' > openkylin-salon/notes/questions.md
printf '%s\n' '# 使用案例' > openkylin-salon/cases/use-case.md
cd openkylin-salon
git init
git add .
git commit -m "prepare openKylin salon materials"
这里的仓库命令只是会前资料管理示例，实际项目可以替换为团队已有的代码仓库、文档平台或知识库。
现场交流：用事实缩短沟通距离
现场讨论时，尽量把“系统很好用”或“存在兼容问题”具体化为可验证的信息，例如：
- 使用的版本、硬件型号和软件版本。
- 可以稳定复现的操作步骤。
- 预期行为与实际行为的差异。
- 日志、截图或最小复现案例。
- 对修复优先级、测试方式或文档补充的建议。
对于暂时无法现场解决的问题，至少确认三个信息：问题由谁跟进、后续在哪里同步、下一次检查时间是什么时候。这样，沙龙中的交流才会转化为可持续的社区协作。
会后跟进：让一次见面产生后续结果
回到团队后，可以在一天内完成一次简短复盘：记录认识的伙伴、确认的事项、待验证的问题和下一步负责人。对于技术问题，优先补充最小复现材料；对于合作议题，明确双方下一次沟通的目标；对于社区贡献，尽早拆分成代码、测试、文档或反馈任务。
参加开源社区活动的关键，不是带着一份完美答案出发，而是带着真实场景、清晰问题和可执行的下一步到场。9月17日，郑州见，把一次单位会员沙龙变成技术经验交换和长期协作的起点。
参会检查清单
- [ ] 确认时间、地点和行程安排
- [ ] 准备团队介绍与一个真实使用案例
- [ ] 整理版本、环境和问题复现信息
- [ ] 明确现场希望交流的伙伴和主题
- [ ] 指定会后跟进负责人
- [ ] 安排复盘和后续同步时间