Finding a Project to Contribute To

The best project to contribute to is one you already use: you know where it hurts, and its maintainers care about your use case. When nothing comes to mind, search for issues labeled for newcomers, and check the repository before you start. Aggregators and yearly events narrow the search, but they don’t replace that check.

Looking for software to use rather than a project to contribute to? See Finding Open-Source Software to Use.

Start with what you already use#

You already know the projects that matter to you: they’re in your lockfile, your terminal and your editor. List them:

npm ls --depth=0

pip list --not-required

brew leaves

Then think of the last time one of them got in your way: a confusing error message, a missing example in the docs, a bug you worked around. Search its issue tracker for it. If it’s already reported, the issue is your starting point. If it isn’t, reporting it well is a contribution in itself.

A fix to something you use is a fix you can test yourself, and a maintainer can tell.

Every GitHub repository has a Contribute page#

Add /contribute to a repository’s URL. GitHub lists the open issues labeled good first issue and links the contributing guidelines. It isn’t linked from the repository’s page, so few people know about it.

For MDN’s content repository, github.com/mdn/content/contribute shows the contributing guidelines (1) and three good first issues (2, 3, 4), as of September 2026.

The page is often empty, even on big projects: on September 26, 2026, Astro, Bootstrap, Vite and Starlight had no good first issue. An empty page doesn’t mean the project wants no help. Look for a help wanted label in the issues, and read the contributing guide.

Search issues across GitHub, then narrow it down#

GitHub’s issue search takes the same qualifiers as the issue list. Start broad, sorted by newest:

is:issue is:open label:"good first issue" language:TypeScript no:assignee

That’s 50.1k results (1) on September 27, 2026. The second one (2) is the 1,318th “add an anime quote” issue of the same repository, with six beginner labels. A label says someone wants help, not that the work is worth your afternoon. Narrow the search:

Bookmark the search URL: it’s a list you can come back to every week. The search syntax has the rest of the qualifiers.

Aggregators do the first filter#

These sites list projects that want contributors, so you start from a shortlist instead of 50,000 issues. All were updated in 2026:

• goodfirstissue.dev: projects added by pull request, with criteria: at least 3 open issues with a beginner label, 10 contributors, a README with setup instructions, a contributing guide, recent activity and an open-source license. Filter by language.
• Up For Grabs: each project declares the label it uses for newcomer tasks, so you land on the right list. Filter by language and tag.
• For Good First Issue: social impact and civic tech projects, filterable by language and by the UN Sustainable Development Goal they work on.
• CodeTriage: subscribe to a repository and get one of its open issues by email every day. Good for learning a project before you write code for it.
• awesome-for-beginners: a list of projects with beginner-friendly labels, grouped by language.

Events put a date on it#

A deadline helps, and some events come with a mentor or a stipend. The community chapter covers them in more detail.

Read the contributing guide before you write code#

A good issue in a project nobody maintains is a pull request nobody merges. Give the repository five minutes with Reading a Repository in Five Minutes: how the newest issues were answered and how old the oldest open pull requests are tell you whether yours will get a review.

Then read the contributing guide: CONTRIBUTING.md, or the Contributing link in the repository’s About box. Projects don’t agree on how to start:

• Some ask you to comment on the issue and wait to be assigned before you write code.
• Some don’t assign issues at all and review the first good pull request. Can I Take This Issue? explains why maintainers choose one or the other, and our we don’t assign issues workflow answers the question with a label.
• Some want a discussion or an approved proposal before any new feature.

Do this now#

• List the dependencies, tools and editor extensions you use every day, and open their issue trackers.
• Open /contribute on two of them.
• Bookmark an issue search for your language, with no:assignee and a recent created: date.
• Pick three candidate issues and give each repository the five-minute check.
• Read the contributing guide of the one you pick, and start the way it asks: a comment, an assignment, a proposal or a pull request.

Go further#

• Searching issues and pull requests: every qualifier GitHub’s search understands.
• Reading a Repository in Five Minutes: the check to run before you invest an afternoon.
• Non-Code Contributions Maintainers Actually Want: triage, docs, translation and more, when your first contribution isn’t code.
• Your First Contribution, Step by Step: what to do once you’ve picked the issue.
• Can I Take This Issue?: why some maintainers assign issues and others never do, from the maintainer’s side.
• Getting Involved in the Open Source Community: the events and programs in more detail.