小陈第一次给 Vue 官方文档提 PR，改了两行错别字，等了五天没回音。他忍不住在 issue 下补了一句：‘请问这个 PR 还需要我做什么？’ —— 结果三天后收到回复：‘请先阅读 CONTRIBUTING.md，描述清楚修改背景和影响范围。’
开源不是‘扔完代码就跑’
很多人以为贡献开源 = 写完代码 + push + 提 PR。其实，真正的门槛常卡在沟通上：issue 描述不清、PR 标题像谜语、评论里用‘我觉得’代替事实依据、遇到分歧直接退群……这些细节，往往比技术本身更决定你能不能长期参与进去。
别把 issue 当备忘录，当‘轻量需求文档’
好的 issue 不是‘按钮点不动了’，而是：
✅ 复现步骤（含环境）：
1. 打开 https://example.com/login
2. 输入 test@test.com / 123456
3. 点击‘登录’按钮（非回车）
4. 页面卡住，控制台报错 Uncaught TypeError: Cannot read property 'token' of null
✅ 期望结果 vs 实际结果
✅ 已尝试的排查（比如清缓存、换浏览器）
PR 标题不是日记标题
❌ ‘修复了个 bug’
❌ ‘改了点东西’
✅ ‘fix(login): prevent null token error when login fails’
✅ ‘docs: correct props description for v-model in Input component’
前缀（如 fix/docs/chore）+ 模块名 + 冒号 + 具体行为，三要素缺一不可。维护者扫一眼就知道要不要点进来。
评论区不是辩论赛现场
别人质疑你的方案时，少说‘我觉得这样更简单’，多说：
• ‘当前实现对 SSR 友好，服务端渲染时不会触发重复请求’
• ‘已测过 Chrome/Firefox/Safari，兼容性无问题’
• ‘这个改动不影响现有 API，已加回归测试用例（见 test/unit/login.spec.js 第 42 行）’
用事实锚定讨论，而不是感受。
学会‘异步同步’
海外项目常见时差 8–12 小时。别在对方深夜发‘紧急！请尽快看下！’。试试这样：
Hi @maintainer, I've updated the PR per your feedback:
- Added unit tests for edge case
- Updated docs in README.md (line 88–92)
No rush — feel free to review when time permits.尊重节奏，反而更容易被记住、被信任。
最后一条：别怕问‘笨问题’，但要自己先搜三遍
GitHub 搜索框输关键词 + ‘site:github.com/org/repo’，Discord 历史记录翻 20 条，README 和 CONTRIBUTING.md 至少通读一遍——再提问。大家愿意帮认真做过功课的人，而不是把别人的劳动当搜索引擎使的人。