EnRoute

So you’ve decided to dip your toes into open source. Great. Now comes the part nobody warns you about: finding an issue that’s actually worth your time. Not too hard, not already taken, and not doomed to rot in “needs design review” purgatory forever.

I recently went through this process with WordPress/gutenberg and a few other WordPress-adjacent repos. Here’s what I learned.

Start with a Repo You Actually Use

The single best filter? Work on something you already have context for. If you use WordPress, you already know what Gutenberg is, how the block editor feels, and what “broken” looks like. That domain knowledge is a huge shortcut.

Repos like WordPress/gutenberg, WordPress/performance, and Automattic/jetpack all have active maintainers who review PRs regularly. Active = faster feedback = higher chance of merge.

Use Labels Like a Cheat Code

Most active repos use labels to signal issue difficulty and status. In Gutenberg, the magic combo is:

label:"Good First Issue" -label:"[Status] In Progress"

The -label part is key. A lot of “Good First Issue” tickets are already claimed. Someone just forgot to add the In Progress label, but there’s a PR open. So after filtering, always do a quick sanity check:

gh pr list --search "28957" --repo WordPress/gutenberg

If that returns a PR, move on. If it’s empty, you might have found your next contribution.

The Sweet Spot: Bugs with a Clear Expected Behavior

Accessibility bugs and small behavioral regressions are gold for new contributors. Why? Because:

• The expected behavior is usually well-defined (a spec, a WCAG guideline, a comment in the code)
• The fix tends to be small and self-contained
• Reviewers can verify it without a lot of back-and-forth

For example, I spotted that pressing Escape on a hover-opened navigation submenu in Gutenberg didn’t close it. It was gated on whether the menu had been opened by a click. That’s a direct violation of WCAG 1.4.13 (Content on Hover or Focus must be dismissible). The fix was about 10 lines of JavaScript.

Read the Whole Issue Before You Touch Anything

Before writing a single line of code, read every comment in the issue thread. Maintainers often drop hints about the right approach or gently indicate that certain approaches are off the table. Ignoring those is how you end up with a “thanks, but we won’t merge this” response after three days of work.

Also check: has anyone else commented saying they’re working on it? Sometimes people claim issues in comments without adding a label. A quick “Hey, is anyone actively working on this?” comment can save you a lot of effort.

Know the Repo’s PR Rules Before You Write Code

Every repo has its quirks. Gutenberg, for example, requires PRs to target the trunk branch (not main, not nightly). It also has a specific PR template with required sections:

• What? — What did you change?
• Why? — Why is this the right fix?
• How? — How does it work?
• Testing Instructions — Step-by-step reproduction and verification
• Testing Instructions for Keyboard — Required for any UI change
• Use of AI Tools — Required per WordPress AI Guidelines when AI assisted the work

Missing any of these will get your PR flagged in review or worse, silently ignored. Read the CONTRIBUTING.md and any AGENTS.md or CLAUDE.md files in the repo before you start.

The Bug That Bites: Watch Out for Hidden Complexity

Some issues look simple on the surface but have a sneaky root cause. I ran into this with a backslash-preservation bug in a Jetpack PHP test. The fix seemed straightforward, but it turned out that wp_insert_post() internally calls wp_unslash(), which uses PHP’s stripslashes(). And stripslashes() strips backslashes before any character, not just the usual suspects (\’, \“, \\). So \t became t. The actual fix was wrapping factory args in wp_slash() so the round-trip worked correctly.

The lesson: if an issue is labeled “Good First Issue” but touches core data handling or serialization, budget extra time for investigation. And if you find yourself going down a rabbit hole, that’s usually a sign you’re learning something genuinely useful, which is the whole point.

Quick Reference: Finding Issues

Here’s a search query you can adapt for any GitHub repo:

is:issue is:open label:"Good First Issue" -label:"[Status] In Progress" no:assignee

And then verify no open PR exists:

gh pr list --search "<issue-number>" --repo <owner>/<repo>

If you want to go a level deeper, look at [Type] Bug issues with recent activity and few comments. Those are often overlooked and ripe for a first-time contributor.

Go Make Something

I wrote about my first batch of open-source contributions: five PRs across five different WordPress repos in one day, in this post. The short version: it’s less intimidating than it looks, and the best way to get started is to just pick something small and ship it.

Good luck out there. Open source is a big place, but most of the doors are unlocked.