我的第一个开源贡献：从提 Issue 到合并 PR 的完整记录
给开源项目提交第一个 PR 之前，我浏览了 GitHub 上十几个项目，反复打开贡献指南，然后默默关掉。这种”不知道从哪下手”的感觉，大概是每个开源新手的必经阶段。
寻找合适的切入点
对于第一个贡献，选对项目和 Issue 比技术能力更重要。我的筛选标准：
- 标签
good first issue：项目维护者明确标记为适合新人的任务 - 近期活跃：最近一周有 commit 和 Issue 回复，说明项目有人维护
- 文档或测试类 Issue：修复文档错误、补充测试用例、改善类型定义——这些不需要深入理解项目架构
- 技术栈匹配：至少能看懂项目的主要语言
GitHub 搜索语法：label:"good first issue" language:typescript state:open
我最终选择了一个使用中的工具库，Issue 是补充某个函数的 TypeScript 类型定义。代码量不大（约 30 行），但需要理解该函数的输入输出行为。
贡献流程中的关键细节
Fork 之后别忘了设置 upstream
git clone https://github.com/your-username/repo.git
cd repo
git remote add upstream https://github.com/original-owner/repo.git
upstream 的意义在于同步原仓库的更新。在 PR 审核期间，原仓库可能合并了其他人的提交，你需要 rebase 到最新：
git fetch upstream
git rebase upstream/main
分支命名要描述意图
fix/typo 比 my-first-pr 好得多。维护者从分支名就能大致判断这个 PR 的意图。
PR 描述模板
好的 PR 描述可以大幅降低维护者的审核成本：
## 问题
`parseConfig` 函数的返回值缺少类型定义，目前是 `any`，
导致调用方无法获得类型检查。
## 修改
- 新增 `Config` 接口，包含 `port`、`host`、`timeout` 字段
- 修改 `parseConfig` 的返回类型为 `Config`
## 验证
- [x] 现有测试全部通过（`npm test`）
- [x] 新增类型测试用例
- [x] 本地 TypeScript 编译无类型错误
## 关联
Closes #123
与维护者沟通的注意事项
- 先读 CONTRIBUTING.md：它包含了项目的贡献规范、代码风格、测试要求。忽略它等于浪费维护者的时间
- 不确定就先开 Issue：不要闷头写几百行代码然后发现方向完全错了。先描述你的想法，等维护者确认后再动手
- 接受修改请求：PR 被要求修改是正常的，不是对你能力的否定。维护者比你更了解项目的整体架构，他们的反馈通常是有道理的
- 不要催促：维护者大多是志愿者，PR 审核可能要等几天。如果超过一周没回复，可以在 PR 下礼貌地 ping 一下
第一个 PR 被合并后的实际影响
我的第一个 PR 是一个 30 行的类型定义补充。合并后，那个库的下一个版本中，所有使用 parseConfig 的开发者都能获得类型提示——这 30 行代码产生的实际影响远超它的体积。
开源贡献的复利效应在于：你修复的每一个小问题，都在被成百上千的开发者使用。这和在公司内部写代码有本质区别——你的代码的用户群体从”十几个同事”扩大到了”所有使用这个库的开发者”。你的质量标准也会因此提升。
从小处着手，从你认为”太简单了不值一提”的 Issue 开始。第一个 PR 合并后，开源就不再是遥不可及的事情。