Your first PR doesn’t need to be a feature. It needs to get merged. Pick the wrong first contribution and you’ll spend three weekends on a rejected 400-line PR; pick the right one and you’ll have a merged commit by Saturday afternoon and a maintainer who recognizes your name next time.

Find the right issue, not just any issue

Skip “good first issue” labels on projects with thousands of stars and a backlog of a hundred open PRs already tagged that way — competition is high and maintainer attention is thin. Look instead for:

- Projects with recent commits (active in the last month)
- Open issues with maintainer replies, not silence
- "good first issue" or "help wanted" labels
- Issues open less than 60 days — older ones often have a reason
  nobody's touched them

GitHub’s own search helps here:

is:issue is:open label:"good first issue" language:javascript
  comments:<3 sort:updated-desc

comments:<3 filters out issues that already have someone else circling them — those are the ones you’ll waste time on and then lose to a faster contributor.

Read CONTRIBUTING.md before you write a line of code

This file exists specifically to save you a rejected PR. It tells you the test command, the commit message format, whether they want an issue filed before a PR, and their branching convention. Skipping it is the single most common reason first PRs get bounced with “please see CONTRIBUTING.md” instead of a real review.

cat CONTRIBUTING.md
# look specifically for: test command, lint command,
# commit message convention, PR template

Comment on the issue before you start

Don’t silently open a PR for an issue nobody assigned you. Comment first:

I'd like to take this on — planning to [approach in one sentence].
Any guidance before I start?

This does three things: it prevents two people duplicating the same work, it gives the maintainer a chance to redirect you before you’ve written code on a dead-end approach, and it signals you’re serious enough to ask rather than just drive-by-PR.

Keep the first PR small

Resist the urge to also fix the three other things you noticed while you were in there. A focused PR — one issue, one fix — gets reviewed and merged fast. A PR that fixes the reported bug plus refactors a function plus renames a variable you didn’t like gets a maintainer who now has three separate things to evaluate and no clean way to accept two out of three.

Bad:  "Fix login bug + refactor auth module + update deps"
Good: "Fix null check in login handler (#412)"

Write the PR description like the maintainer has 30 seconds

## What
Fixes #412 — null pointer when `user.email` is undefined during
OAuth callback.

## Why
Users signing in via GitHub without a public email hit this.

## Testing
Added a test case for the undefined-email path. `npm test` passes.

Link the issue number (Fixes #412) so GitHub auto-closes it on merge. Include the test command you ran, even if it’s just “existing tests pass” — it tells the maintainer you checked before asking them to.

After it’s merged

Don’t disappear. Watch the issue and PR for a week in case the maintainer has follow-up questions or the CI catches something in a different environment than yours. Responding fast to review feedback is what actually builds the reputation that gets your next five PRs merged faster — maintainers remember who’s easy to work with far more than they remember what the first PR fixed.

What kills a first contribution

Going quiet after a maintainer requests changes. A PR sitting for three weeks with an unaddressed review comment gets closed as stale, and that’s the actual failure mode — not writing bad code, just not finishing the conversation you started.