开源不必从大项目开始：把一个数据问题写成别人能复现的 Issue

我想做的开源分享，不一定是一套组件库。一个复现清楚的 Issue，也能节省维护者不少时间。数据分析里的报错尤其容易带着一堆环境和口径：同样叫“求平均”，空值、字符串数字和分组方式都可能不同。

如果我要把一个内部问题整理出去，第一步会是拿掉业务数据和公司地址，再造一份足够小的教学样本。不是把客户名字换成 A、B 就算脱敏；能通过数量、时间和金额重新识别的记录，也不该跟着报错贴到公开仓库。

一份有效报告，先让别人走到同一处

报告里写清运行时与包版本、操作系统、最短命令、输入、期望结果和实际结果。错误堆栈可以保留必要部分，但凭证、内部主机名和个人信息应先检查。不要只发一张红色截图，也别让维护者先安装一整套公司的服务。

例如“分组平均值不对”可以缩成：东区 100 单合计 1000 元，西区 1 单合计 100 元；期望总客单价为 1100/101，而不是地区均值的平均 55。这样即使别人没用过你的 BI 工具，也能理解要验证什么。

升级问题，不等于代码一定写错了

10 月 21 日的 DuckDB 2.0 是一次包含迁移变化的版本更新。官方迁移文档说明了新建存储文件的兼容性限制，并建议用影子环境测试。遇到升级后打不开文件时，先记录创建文件的版本和读取版本，比直接写“新版本彻底不可用”更有帮助。DuckDB 2.0.0 LTS 发布说明、DuckDB 2.0 迁移指南

我也会把修复建议与事实分开：“我在这个最小样本上看到了结果变化”是一条可核事实；“问题一定由解析器造成”仍是推测。如果没有时间确认原因，提供可运行样本就够了，不必为了显得专业而猜一个底层机制。

给分享设一个能完成的范围

我的小目标可以是整理一份复现、补一处文档或复核一条指标定义。README 说支持什么，就提供对应例子；没试过 Windows 或某个数据库版本，就写未验证，不写“全平台兼容”。

Null 大概不会关心仓库有几颗 Star。它会在桌旁睡着，等我把下一步写进便签。我更愿意把分享的标准也定得这样具体：别人能否在自己的电脑上走到同一条结果，能否知道这份结果到底证明了什么。

本文是一份写作方法与计划，没有声称已经维护某个公开项目、收到某位开发者的 Issue，或通过某项跨平台测试。一个诚实的小报告，比一个没有证据的“大型开源生态”故事更适合当起点。

延伸阅读

• DuckDB 2.0.0 LTS 发布说明
• DuckDB 2.0 迁移指南