我 2021 年给一个 2.3k star 的 Go 项目提过 1 行 PR，把配置里的默认超时从 30s 改成 60s。 维护者两小时后就关了，留言只有一句：有没有 issue？有没有复现？为什么是 60 不是 45？ 当时我觉得他傲慢。后来我自己帮朋友维护一个 400 star 的小库，三天收到 9 个 PR，才明白他不是傲慢，是累。 开源贡献最反直觉的地方在这儿：你以为你在交代码，维护者看到的是一个新的决策包袱。
先别找项目，先算三笔账
很多人搜“开源贡献入门”，第一反应是找 good first issue。 但 good first issue 这个标签已经被玩坏了：有的项目 2020 年贴的标签，2025 年还没关；有的 issue 下面 20 个人说“Can I work on this?”，没人真提 PR。 我现在会先看三笔账。第一笔，代码账：这个改动大概多少行，会不会碰公共 API，要不要改测试。第二笔，上下文账：我能不能在 30 分钟内把项目跑起来，能不能复现 issue。第三笔，注意力账：维护者 review 我这个 PR 要花 10 分钟还是 2 小时。 三笔账里，新手最容易忽略第三笔。一个 500 行的重构 PR，哪怕代码写得像诗，维护者也要开本地分支、跑测试、看 diff、想兼容性；一个 20 行的补丁，带上“复现步骤 + 失败日志 + 修复后日志 + 测试”，可能 10 分钟就合并。
我常用的搜项目和验项目步骤，别只点 star 数
第一步，用 GitHub 搜索语法缩小范围：label:"good first issue" language:Python state:open，再按 updated:>2024-01-01 过滤。
第二步，别只看 star。打开 Issues，看最近 30 天有多少 issue 被关闭，看 Pull requests 里有没有 3 个月没回的 PR。一个 20k star 但 PR 队列堆到 300 的项目，不一定适合第一周就去。
第三步，读 CONTRIBUTING.md、CODE_OF_CONDUCT.md、.github/PULL_REQUEST_TEMPLATE.md。有些项目要 CLA，有些要 DCO。Linux 内核常见 Signed-off-by，也就是 git commit -s；Kubernetes 要 CNCF CLA，还要 Prow 的 /lgtm、/approve；CPython 要 PSF contributor agreement，还常要 blurb 写 news entry。
第四步，本地跑起来。Python 项目先 python -m venv .venv && pip install -e .[dev]，再 pytest -q；Go 项目 go test ./...；Rust 项目 cargo test 和 cargo fmt --check。跑不起来就先别改代码，先提 issue 问环境。
PR 被关，通常不是技术差，是这几件事
我见过也踩过的关闭理由：重复 issue、没有复现、CI 红、改了 API 没先讨论、PR 太大、没签 DCO、没加测试、语气像命令。
解决方法不玄：找到 issue 后先留言“我按这个步骤复现了，准备改 X 文件，范围控制在 Y，是否合适？”等 24-48 小时；没回复就换一个。
写代码前开 draft PR：gh pr create --draft。把复现命令、失败输出、修复后输出、测试命令贴进模板。CI 挂了先自己看日志，别直接 @ 维护者。
DCO 项目用 git commit -s，CLA 项目按机器人链接签。代码格式先跑 pre-commit run --all-files、ruff check .、gofmt -l .、cargo fmt。
PR 控制在 200 行以内，纯格式化改动单独一个 PR。改公共 API、改默认行为、加依赖，先在 issue 里说清楚，不要直接甩 diff。
非代码贡献被低估，但别把文档 PR 当勋章
如果你暂时不会写这个项目的语言，文档、测试、issue triage 都是入口。 但我要唱个反调：非代码贡献不是“低配代码贡献”。一个把安装步骤从 8 步压到 3 步、补了 Windows 路径坑的文档 PR，可能比一个炫技的 300 行重构更有用。 可另一面，别在简历里写“给 XX 项目贡献 12 个 PR”，结果点开全是改 README 错别字。维护者不傻，面试官也不傻。 比较诚实的写法：你解决了哪个用户问题，影响哪些版本，附 issue 和 PR 链接，CI 状态，合并时间。
我的独立观点：开源贡献的复利是“可被信任的上下文”
我不再追求 GitHub 绿格子。那东西只能证明你那天提交过，不能证明你的改动被合并、被使用、被维护者信任。 真正有复利的是上下文：你知道这个 bug 为什么在 2.3.1 出现、在 2.4.0 被另一个改动掩盖；你知道维护者为什么不肯加这个参数；你知道哪个测试一跑就要 18 分钟所以不能放进默认 CI。 这些东西写不进 commit，但会留在 issue、review、聊天记录和别人的记忆里。下次你再提 PR，维护者可能先信你三分。 所以新手 90 天可以这么来：第 1-2 周读 3 个项目的 CONTRIBUTING，复现 10 个 issue，别提交代码；第 3-4 周提 1 个文档或测试 PR；第 5-8 周跟 1 个 bug 从复现到 patch；第 9-12 周做 triage，帮别人复现，或者 review 一个小 PR。
最后说个不好听的：别发“Can I work on this?”然后就消失。 要么直接附上复现结果，要么问一个具体问题，比如“这个在 Windows 11 + Python 3.12 下复现，报错是 X，我准备改 Y，需要先加回归测试吗？” 维护者要的是减少不确定性，不是收一个徒弟。你减少他的决策成本，他才会给你 merge 按钮。