How to make your first open source PR

Good First Issue,
contributorsopen-sourcepull-requests

The hard part of your first open source pull request is usually not Git, GitHub, or the mechanics of opening a PR. The hard part is choosing work that is small, current, understandable, and likely to receive maintainer review.

Good First Issue is built around that decision. It helps you move from "I want to contribute" to "this is a realistic issue, in an active repository, with enough context for me to open a useful PR."

Start with the right kind of issue

Begin on the issues page. Search for words from tools you already know, filter by label or language, and sort results so you are not starting from stale work.

Useful entry points include:

Do not treat the label as a guarantee. Treat it as a starting point. A good first issue still needs a clear scope, a responsive repository, and enough information for you to verify your change.

Read the issue like a reviewer

Before you clone anything, open the issue detail page and scan the signals that tell you whether the work is worth your time. Look at the labels, repository, primary language, stars, comments, reactions, assignees, description, and GitHub source link.

Then read the Contributor guide metadata as a second pass. Good First Issue summarizes signals such as tech stack, domain, issue type, difficulty, estimated time, activity status, clarity, prerequisites, newbie friendliness, and research direction.

You are looking for alignment:

  • The issue description tells you what success looks like.
  • The repository has recent enough activity to make review plausible.
  • The required stack is close to something you can run locally.
  • The discussion does not show that someone else is already deep into the same fix.
  • The research direction gives you a next step instead of a vague wish.

GitHub remains the source of truth. Good First Issue indexes and summarizes public data, and that data can be stale. If the issue is closed, already assigned, or contradicted by a newer maintainer comment on GitHub, trust GitHub.

Pick a tiny scope

For your first PR, optimize for reviewability. A maintainer should be able to open your diff and understand the change in a few minutes.

Good first scopes usually look like:

  • Documentation improvements.
  • Tests that reproduce a small known behavior.
  • Small bug fixes with a clear expected result.
  • UI polish where the desired output is obvious.
  • Examples, README fixes, or setup instructions that you can verify.

Avoid work that changes database migrations, authentication, security behavior, release automation, dependency policy, public APIs, broad product features, or unclear product decisions. Those can be valuable contributions later, but they are rarely the best first PR because the review surface is large.

Claim the issue before coding

Once you have a small scope in mind, leave a short comment on the GitHub issue before you start. You are not asking for permission to contribute to open source; you are checking that your proposed scope still matches what maintainers want.

Hi! I would like to work on this as my first contribution to the project.

My plan is to update <small, specific area> by <brief change>. Does that scope still make sense?

If there is already a preferred approach, I am happy to follow it.

If a maintainer responds with guidance, follow it. If nobody responds but the issue is clearly open and unassigned, you can still make a small, well-tested PR. Keep the diff narrow so it is easy for a maintainer to say yes, no, or "please adjust this part."

Fork, branch, test, and open the PR

After you have a scoped plan, use the repository's own contribution docs first. If they do not specify a workflow, this compact version is usually enough:

gh repo fork OWNER/REPO --clone
cd REPO
git checkout -b fix-small-specific-thing

# Install dependencies with the project's documented package manager.
<install command>

# Make the smallest change that solves the issue.

# Run the relevant checks before opening the PR.
<test command>

git status
git add <changed files>
git commit -m "fix: update small specific thing"
git push -u origin fix-small-specific-thing
gh pr create --fill

For a fuller command-by-command playbook, use the Contributor guide.

What makes the PR maintainer-ready

A maintainer-ready PR explains the change, the test path, and anything the reviewer should know before clicking through the diff. You do not need a long essay. You do need enough context that the reviewer is not forced to reconstruct your intent from the code alone.

## What changed

- Updated <area> so <behavior/result>.
- Kept the change limited to <scope>.

## How I tested

- Ran <command>.
- Manually checked <page, flow, or example>.

## Notes

- This addresses <issue link>.
- I am new to this repository, so feedback on the preferred style is welcome.

After you open the PR, keep watching for maintainer comments. Respond with small follow-up commits, avoid force-pushing unless the project asks for it, and keep the conversation focused on getting the specific issue merged.

When you are ready to pick another contribution, go back to issues or browse repositories and repeat the same process: choose active, understandable, reviewable work before you start writing code.