上周，小林给一个热门的 Vue 插件提了个 PR，改了三行样式 bug，结果被 maintainer 一句“请先读 CONTRIBUTING.md”打回来了。他挺委屈：代码没问题啊，为啥连讨论机会都不给？
开源不是“交作业”，是“进群聊天”
很多人以为贡献开源 = 写完代码 → 提 PR → 等合并。其实第一步卡住的，往往是沟通——不是技术不行，是没说对人、没说到点上。
比如你在 issue 里写：“这个按钮点不动，修一下”，不如说：“点击登录按钮后控制台报 TypeError: Cannot read property 'submit' of null（复现步骤：1. 进入 /login 页；2. 不填任何字段直接点按钮），我本地调试发现是 formRef 在 mounted 阶段尚未绑定。”
三条不费力但很管用的沟通习惯
1. 问问题前，先搜一遍已有 issue 和 PR
别发“这个功能有计划支持吗？”，先搜关键词。如果已有类似讨论，直接跟帖补充你的使用场景，比另开一个更易被看见。维护者每天扫几十个 issue，重复提问=自动沉底。
2. 提 PR 时，用“动词+影响”开头写标题
❌ “修复按钮样式”
✅ “fix(login-btn): 修复移动端点击区域过小导致误触”
括号里的模块名（如 login-btn）让维护者一眼定位范围，“误触”点出实际影响，不是只讲改动。
3. 被要求修改时，别只回“好的，已改”，补一句“这次调整后，我在 iOS Safari 和 Chrome 124 上都验证通过了”
主动闭环，省去对方再问“测了吗？”“在哪测的？”
一段真实 PR 描述，抄作业用
feat(date-picker): 支持自定义禁用日期范围
- 新增 `disabledDateRange` prop，接收 `[start, end]` 数组格式
- 若 start 或 end 为 null，则单向禁用（如 `[null, '2024-06-01']` 表示禁用所有早于该日的日期）
- 已在 demo 页面添加对应示例，并通过 Jest 测试覆盖边界情况（含 null 输入、非法日期字符串）没有“我觉得”“可能”，全是可验证的动作和结果。维护者扫一眼就知道改了啥、怎么用、有没有测。
开源项目的沟通本质是降低他人理解成本。你多写清楚 20 字，别人少花 5 分钟确认；你多跑一次真机测试，别人少开一次本地环境。这些细节不炫技，但决定了你的 PR 是被快速合入，还是静静躺在“waiting for response”里。