How to Contribute to Open Source on GitHub in 2026

GitHub is the product. This page is how to use it in 2026: Issues search, the repo Contribute sidebar, Codespaces, notifications, draft pull requests, and reviewers.

It is not a week-1 plan. That is how to contribute to open source. It is not fork, clone, branch, commit. That is the first pull request guide.

GitHub’s own beginner docs are a decent orientation. GitHub search is still noisy. After you know which buttons to press, hunt on a live hub.

Three GitHub surfaces

Most people mash these together. They do different jobs.

Issues search (github.com/issues, plus global search) is how you find labeled work across GitHub. It is complete. That is the problem.

The Contribute sidebar is how you read the rules on a repo you already opened. If the project has a CONTRIBUTING.md, GitHub surfaces it in the 2025–2026 UI: a Contributing tab in the repository overview (next to README and Code of conduct), a Contributing link in the repository sidebar, and a /contribute page (github.com/OWNER/REPO/contribute).

Codespaces is how you edit without a local clone. On the repo, click Code, then the Codespaces tab, then create a codespace. The dialog tells you who pays.

Use search to find a candidate. Use Contribute to avoid a rejected PR. Use Codespaces (or a local clone) to make the change. Do not skip the middle step.

Issues search: good first issue with a 2026 activity filter

Open github.com/issues. That dashboard is your issues, mentions, and saved views. The search bar there — and GitHub’s global search, set to Issues — accepts the same qualifiers.

A beginner query that is not a museum:

is:open is:issue label:"good first issue" language:python updated:>2026-01-01

What those pieces do:

• is:open is:issue — issues, still open
• label:"good first issue" — GitHub’s recommended beginner label. Hyphenated good-first-issue is a different string; search it separately if a repo uses it
• language:python — repositories GitHub classifies as that language (swap typescript or javascript)
• updated:>2026-01-01 — the issue itself was touched this year (comment, edit, label). Tighten the date to the last few months if the list is still a museum
• pushed:>2026-01-01 — optional extra: the repo had a push this year, so the default branch is not abandoned. Add it when updated: still returns quiet trackers

You can save that query as a saved view on the issues dashboard (sidebar, under Views). GitHub caps you at 25 views.

GitHub will still return:

• Issues that have been open for years on a quiet tracker
• Threads someone claimed in a comment
• Labels applied once and never revisited
• Repos that do not review pull requests

Treat Issues search as a second pass. The good-first-issue playbook is the longer filter. The beginner projects list is hubs, not a frozen gallery.

Repo Contribute sidebar

Before you write a patch, open the repository’s main page.

1. Contributing tab in the overview, next to README.
2. Contributing in the right sidebar.
3. Direct URL: https://github.com/OWNER/REPO/contribute.

If none of those exist, there is no CONTRIBUTING.md in .github/, the repo root, or docs/. That is a signal, not a dare. You can still contribute, but you will guess branch names and test commands.

Also open Insights → Community standards if you want the checklist GitHub uses: README, code of conduct, contributing, license, security policy.

Read the guide. Then comment on one issue. The Contribute UI does not claim the issue for you.

Codespaces (and when not to)

On the repository:

1. Pick the branch in the branch dropdown (usually the default).
2. Click Code.
3. Open the Codespaces tab.
4. Create a codespace with the defaults, or New with options for machine type / devcontainer.json.

The codespace clones the repo into a cloud VM and opens a browser VS Code. Free and Pro accounts include a monthly quota; going over that needs a spending limit. Your codespaces lists what you already created.

Skip Codespaces when:

• The contributing guide tells you to run a specific local toolchain
• You are only editing a docs file (press . to open github.dev, a lighter web editor, no VM)
• You already have the repo cloned

Fork first if you do not have write access. The Fork button is top-right. In the fork dialog, pick an owner, optionally tick Copy the DEFAULT branch only (enough for most first PRs), then Create fork. After that, create the codespace from your fork, or clone it. Git commands live in the first pull request guide. This page will not re-teach git push.

GitHub’s own beginner docs, then leave search

Read these once:

• Finding ways to contribute to open source on GitHub
• Contributing to open source

They cover labels, the Community standards checklist, forking, and opening a PR. They do not filter dead repos. GitHub search plus Explore will happily point you at a labeled issue on a project that stopped merging.

That is why the next click is a live index, not another query:

• All languages: https://helpwanted.dev/
• Python: https://helpwanted.dev/language/python
• TypeScript: https://helpwanted.dev/language/typescript
• JavaScript: https://helpwanted.dev/language/javascript

Those hubs are labeled issues from active GitHub projects. You still read the thread. You should not have to wade through a graveyard first.

Notifications

You need to see review comments. You do not need every event on the repo.

• Inbox: github.com/notifications. Commenting on an issue or opening a PR subscribes you to that thread.
• Watch (repo, top-right): all activity. Do not Watch a busy project as a first contribution unless you want the firehose. Participating and @mentions are enough.
• On the issue or PR itself, subscribe or unsubscribe to stay on your change without taking the whole tracker.

When review lands, it shows up in that inbox. Answering it is the contribution.

Draft pull requests

When you click Create pull request, the dropdown next to it is Create draft pull request. Then Draft Pull Request.

In 2026 GitHub terms:

• A draft cannot be merged
• Code owners are not automatically requested to review
• You mark it ready with Ready for review in the merge box
• You can convert an open PR back to a draft from the right sidebar, under Reviewers → Convert to draft. Existing subscribers stay subscribed

Use a draft when the diff is not reviewable yet (CI red, tests not run, description empty). Do not use a draft as a claim on the issue. Comment on the issue, then open the PR when you have something a maintainer can read. When it is ready, mark it ready — a draft that sits for weeks looks abandoned.

Fill in the template. Link Fixes #123. The Git steps are in the first pull request guide.

Requesting reviewers

On the pull request, the right sidebar has Reviewers. GitHub suggests people from git blame. Click Request next to a name, or search.

You need write access to request a review. First-time contributors on a fork usually do not have that. CODEOWNERS are requested automatically when you mark a draft Ready for review. You cannot ping maintainers through the Reviewers widget without write access.

What actually works: a clear description, the issue link, and staying subscribed. If review is silent on an otherwise active repo, wait. A follow-up comment on the PR is enough. Do not @ the maintainer on every commit.

FAQ

Why not just use GitHub Issues search?

You can. label:"good first issue" is real. It is also unfiltered: stale issues, claimed threads, dead review queues. I built Help Wanted so the first list you see is labeled issues on repos that still look active. Use GitHub search when you want a specific org or a label a hub does not index.

Do I have to use Codespaces?

No. Codespaces is the Code → Codespaces path when local setup is painful. A local clone is fine. github.dev (press .) is enough for a one-file docs change. Follow CONTRIBUTING.md either way.

Can I request a reviewer on my first PR?

Usually not. Requesting reviewers requires write access. Mark the PR ready for review so code owners get the request, keep notifications on, and wait. Do not open a second PR to “nudge.”

Should my first PR be a draft?

Only while it is incomplete. Open a draft if you need CI to run before you want eyes on it. Click Ready for review when the change matches the issue. A draft that never leaves draft does not get merged.

Where did CONTRIBUTING.md go in the UI?

It is not hiding in the file tree. If the repo has one, GitHub puts Contributing in the overview tabs and in the sidebar, and at /contribute. If those are missing, the file is missing.

Start on GitHub, then on a hub

1. Skim GitHub’s finding ways to contribute so the UI is familiar.
2. Open helpwanted.dev, or Python, TypeScript, or JavaScript.
3. On the repo you pick: Contribute sidebar, one issue comment, small PR (draft until it is reviewable). Git mechanics: first pull request guide. Week-1 map: how to contribute to open source.

GitHub’s buttons are not the hard part. Picking a repo that still reviews is.