想参与开源项目，门槛其实比想象中低，绝大多数维护者都乐意看到新贡献者出现。第一步不是急着写代码，而是挑一个你平时真的在用、或者至少熟悉其技术栈的项目——对项目解决的问题越了解，越容易找到合适的切入点。
找 issue：从 good first issue 和文档入手
新手最友好的入口是 GitHub 上的 good first issue 标签，很多项目会专门准备这类标签，标注范围小、上下文清晰的待办事项，可以直接在 GitHub 搜索框用 label:"good first issue" 加上语言或领域关键词来筛选。另外，改进文档、补充测试、修正 typo、翻译 README，都是容易被低估但很受欢迎的贡献方式，特别适合第一次上手。挑选 issue 时留意两点：一看近期是否有人维护，如果一堆 issue 三个月没人回复，说明维护者可能不活跃；二看有没有别人已经认领，避免重复劳动。
确定目标后，先把项目的 CONTRIBUTING.md 读一遍。正规项目基本都有这份贡献指南，写明代码风格、分支命名、commit 规范、测试要求和 PR 流程，跳过它直接动手，PR 大概率因为格式问题被打回。顺手翻翻 README 和相关 issue、PR 的历史讨论，了解维护者的沟通习惯，能少走不少弯路。
提 PR：小步走，把改动说清楚
第一次贡献尽量把改动控制在小范围内，修一个 bug、补一段文档，都比重构一堆代码容易被合并。流程一般是：fork 仓库、克隆到本地、开一个新分支、改完跑一遍项目要求的测试、push 回自己的 fork，再向原仓库发起 PR。PR 描述里写清楚改了什么、为什么改、怎么验证的，有关联的 issue 就带上编号，方便维护者查看。如果改着改着发现范围膨胀了，果断拆成几个小 PR 分别提交。
沟通礼仪同样重要
- 动手前先在 issue 下留言说明想认领，得到确认再开工；
- 维护者给了修改意见就尽快响应，暂时没空也回一句进度；
- PR 挂久了没动静，礼貌地 ping 一次即可，不要反复催；
- code review 时被指出问题很正常，对事不对人，别当成针对自己。
第一个 PR 哪怕只改了一行文档，被合并时你就正式进入了这个项目的贡献者名单，这份成就感是实打实的，后面的路也会越走越顺。