上周给一个挺火的 Markdown 编辑器提了个 PR，改了行号显示的样式。结果被维护者一句“这个改动没说明动机，先关了”直接拒了。我没急着辩解，翻了下 issue 记录，发现之前有人提过类似需求但附了三张截图+一段用户反馈——我立刻补了 PR 描述，加了对比图和一句话场景：“当用户横向滚动长代码时，行号错位容易误判行数”。第二天就合并了。
别把 PR 当代码提交，先当一封邮件写
很多人习惯在 PR 标题写“fix bug”或“update xxx”，但维护者每天扫几十个 PR，根本记不住你修的是哪个按钮的点击延迟。试试这个结构：
feat(editor): 在侧边栏添加实时字数统计
- 点击编辑区任意位置即触发更新，无额外性能开销
- 适配深色/浅色主题（复用现有 CSS 变量）
- 已覆盖 3 种典型文档长度测试（100/1000/5000 字）标题带作用域（editor）、类型（feat）、功能点；正文用短句分点，不解释原理，只说“做了什么+谁受益+怎么验证”。维护者扫一眼就知道值不值得点进去。
问问题前，先证明你搜过了
在 Slack 或 Discord 里发“请问 build 失败怎么解决？”大概率石沉大海。换成这样：
“我在 macOS 14.5 + Node 18.17 下运行 npm run build 报错：
TypeError: Cannot read properties of undefined (reading 'version')查了 #211、#304 和文档的 ‘Local Dev Setup’ 章节，试过重装 node_modules 和切换 Node 版本（16/18/20），仍复现。是否遗漏环境变量配置？比如需要提前设置
ENV=dev？”把错误粘全、系统环境写清、已尝试方案列明白——这比“求帮看”有用十倍。维护者不用再反问你三次，直接给答案。
被指出问题时，别急着解释，先确认理解
有次我提了个新组件， reviewer 评论：“建议用 Composition API 重写，Options API 维护成本高”。我第一反应是想回“但老代码都是 Options 啊”，忍住没发，转而回：“明白，你是希望统一代码风格并降低后续扩展难度，对吗？我今晚重写，用 defineComponent + useXXX hooks 封装逻辑，你看这样是否符合预期？”
对方秒回：“对，顺便把 props 类型检查加上就行。”——沟通卡点不在技术，在是否听懂对方真正在意什么。
日常刷 issue，比写代码更能摸清项目脾气
我固定每周五下午花 20 分钟扫一遍新 open 的 issue：不急着动手，就看三样——谁提的（社区新人？公司用户？）、标签（bug/enhancement/docs）、维护者回复语气（是耐心引导，还是直接贴文档链接）。慢慢就摸清了：这个项目讨厌模糊描述，喜欢带复现步骤的 bug；那个文档仓库欢迎翻译，但要求每句英文原文+中文对照；还有个工具库的 maintainer 只在周二周四上线……这些细节，从贡献指南里可读不出来。
开源不是交作业，是进群聊。话说到点上，代码才容易被看见。