从一个小白的踩坑经历说起
去年我第一次想给一个 GitHub 上的开源工具提 PR，改了个简单的文档错别字。结果等了三天没人理，再一看 CONTRIBUTING.md 里写着‘所有提交必须关联 Issue’，而我压根没开 Issue。白忙活一场。
后来慢慢摸索出一些门道，发现很多人和我一样，不是不想贡献，而是不知道怎么“正确打开”。
选对项目比猛敲代码更重要
别一上来就盯着 React 或 Vue 这种顶级项目。维护者每天收几百个 PR，你的小修小补很容易被淹没。不如找那些 star 数在 500 到 3000 之间的项目，活跃但竞争小，维护者也更愿意帮新人。
可以搜 GitHub 上带 good first issue 标签的问题，这类任务通常是拆解好的小需求，比如修复拼写、补充测试用例、优化日志输出。完成一个，就能建立信任。
先聊天，再动手
看到 bug 想直接改？先别急。去 Issues 里发条评论：“这个现象我复现了，打算修一下，你们觉得方案 A 还是 B 更合适？”
很多项目维护者最怕不沟通就甩个 PR 过来，因为可能方向完全不对。你一句简单的提前沟通，反而让人觉得靠谱。
PR 描述不是走形式
别只写“fix typo”或者“update docs”。写清楚：
- 为什么改？（比如“用户反馈注册页按钮文字有歧义”）
- 改了什么？（比如“将‘提交申请’改为‘立即注册’”）
- 怎么验证？（比如“本地启动后点击测试通过”）
格式整洁点，别人看起来不费劲。有些项目甚至要求用特定模板，照着填就行。
让工具帮你避坑
不少项目用了自动化检查。比如 Prettier 格式化、ESLint 规则、CI 跑测试。你在本地跑一遍，省得 PR 上去红一片错误。
举个例子，如果你要提交 JS 代码，可以先装好依赖：
npm install然后运行项目自带的检查命令：
npm run lint
npm run test提前发现问题，比等人指出再改要体面得多。
别怕被拒，但要会看反馈
PR 被打回来太正常了。有人提建议，说明他们在意质量，而不是直接关掉完事。
有一次我提了个功能，维护者说“逻辑没问题，但接口设计不够通用”。我没生气，按建议拆成可配置的形式，第二轮就合并了。后来他还主动邀请我参与后续讨论。
长期露脸比单次贡献更有价值
偶尔来一次像路人，经常冒泡才像自己人。可以定期看看 Issues 回复几个简单问题，或者帮忙验证别人报告的 bug。
时间久了，维护者记住你了，下次 PR 自然更容易被优先处理。开源圈子不大，口碑比技术还管用。