"Just pick an issue and fix it" sounds simple until you open the issues tab. Some issues labeled for beginners are already claimed. Some are old. Some look small but require project knowledge you do not have yet. That is normal.

Your first issue should be small, current, unclaimed, and within reach. The goal is not to prove that you can solve the hardest problem in the repository. The goal is to complete the full contribution process once: understand the issue, make a focused change, open a pull request, respond to feedback, and get the work merged.

A good first issue has three qualities: it looks approachable, it is genuinely small, and nobody else is actively working on it. When those are true, the contribution is manageable. When they are not, you may spend days on something too large or duplicate work someone else has already started.

Start with the labels maintainers use to mark approachable work: "good first issue," "help wanted," and "documentation." These labels are useful, but they are not promises. An issue can be mislabeled, outdated, or larger than it first looks.

Then check the size. The best first issues are specific and easy to verify: a documentation correction, a broken example, a small bug with clear reproduction steps, or a minor missing option. Documentation issues are especially good first contributions because they take you through the real workflow without requiring you to understand the whole codebase.

Finally, check whether the issue is unclaimed. Look for an assignee, a recent comment from someone saying they are working on it, or an open pull request linked to the issue. If someone is already handling it, choose another issue. Maintainers appreciate contributors who avoid duplicating other people's work.

Run each candidate issue through these filters in order. If it fails one, move on.

An issue should clear all four checks before you claim it. Most issues you scan will not be the right first one, and that is fine.

Filter by the approachable labels

In the issues tab, filter for "good first issue," "help wanted," and "documentation." Most projects let you filter by label directly in the issue search. This narrows a large issue list to work the maintainers have at least considered approachable.

Size the issue honestly

Read the issue and ask what the fix actually involves. A short bug report with reproduction steps is a good size. An issue that says "refactor the plugin system" is not a good first issue, even if it has a beginner-friendly label. When in doubt, choose the smaller task.

Favor documentation for the very first one

A documentation fix, a wrong example, an unclear setup step, or a missing parameter description can be an excellent first pull request. It is real work, it helps users, and it is usually easier to review than a code change. Do not dismiss documentation work as less valuable.

Check that it's unclaimed

Look at the assignee field, the comments, and any linked pull requests. If someone is assigned or recently said they are working on it, move on. You want an issue where your effort is welcome and unlikely to duplicate someone else's work.

Check the hidden requirements

Ask whether the fix depends on knowledge you do not have yet: framework internals, a domain you have never worked in, or a build system you cannot run locally. If the hidden requirement is too large, set the issue aside. The goal is a finished pull request, not an impressive abandoned branch.

Claim the issue before you start

Comment briefly before you start. Say you would like to work on the issue, describe your intended approach in one sentence, and ask to be assigned if that is the project's convention. This helps maintainers and other contributors know what is happening.

Consider fixing something that bugs you instead

You do not always need to start from an existing issue. If you use the tool and notice a real bug, confusing documentation, or a rough edge, you can open an issue describing it and ask whether a fix would be welcome. For a first pull request, it is usually better to confirm interest before you spend time building the change.

The first three rows are usually the best places to start. A small first merge gives you confidence, teaches the project workflow, and makes the second contribution easier.

When you find an unclaimed issue, leave a short comment before you start. Keep it polite, specific, and easy for a maintainer to answer.

For a "good first issue" with no assignee:

When you want to confirm the approach first:

Why these work: Both comments show that you read the issue and have a reasonable first plan. The second is better when there are multiple possible fixes, because it gives the maintainer a chance to steer you before you write code. Avoid commenting only "Can I work on this?" with no approach. It creates extra back-and-forth and does not show that you understand the task yet.

The difference between a good first issue and a frustrating one is usually scope, clarity, and whether someone else is already working on it.

Poor choice:

Good choice:

Why the good choice works: The performance issue is vague and likely larger than the label suggests. The documentation issue is recent, specific, unclaimed, and easy to verify. It still takes you through the full contribution workflow, which is exactly what you need from a first pull request.

Pick the wrong issue here and you can spend a weekend on a fix that was never yours to make or was never as small as the label promised.