This page is the Python hunting ground: what a small first issue looks like in this language, and where the live list lives. It is not the generic hunt — that is how to find good first issues. It is not a beginner project roundup — that is best open source projects for beginners. Use those when you need the playbook or the multi-language index. Use this URL when the stack is Python and you need to know what “small” means here.

I built Help Wanted so that list is a filter, not a gist of famous libraries.

Start on the Python hub

Browse Python good first issues →

That hub is labeled good-first and help-wanted issues from active GitHub projects whose language is Python. On 2026-08-31 it had about 9,461 labeled issues at 10+ stars. Treat that number as a dated snapshot. The feed moves.

If Python is not what you write, start on the homepage and pick the language that is.

Keep the default 10+ stars filter so you skip empty experiments. Turn difficulty down if you want a smaller first patch. Difficulty is a hint. Then read the issue, not the title.

Skip threads that are stale, already claimed, or sitting on a repo that has not merged pull requests lately. The issue-level checklist is how to pick an issue that will get merged. Do that check after you are on the Python hub, not instead of it.

What “small” means in Python

A good first issue label in Python is not a size. Small here is a change you can run with the project’s own tests and prove in one sitting. These are the shapes that actually merge for a first PR.

pytest: add a case, not a framework

The typical first Python pull request is one test.

The issue describes a bug or a missing check. You add a pytest case that fails on main and passes with the fix. The case lives next to the existing tests, uses the fixtures they already have, and names the behavior — not the ticket number.

That is the job. It is not:

Migrating unittest to pytest
Introducing a plugin, a coverage gate, or a new fixture architecture
Rewriting conftest.py because the style bugged you

If CONTRIBUTING.md says pytest or python -m pytest, that is the loop. Get that green on the default branch before you touch the bug. If you cannot, pick another issue. A first PR that also debugs the test runner is two projects.

Typing: annotate a public function, not the package

A first typing issue is usually: add annotations to one public function (or the small module the ticket names), then run the checker the project already uses — mypy, pyright, or whatever CONTRIBUTING calls out.

Done means that function’s signature matches how callers already use it, and the checker is quiet on the lines you were asked to touch.

Done does not mean:

A PEP 484 conversion of the tree
Replacing working code with more Any so the checker goes green
Reformatting every signature in the file you opened

If the issue says “add types to parse_row”, type parse_row. Leave the private helpers unless the checker you just ran forces a one-line fix in a helper that function calls. Do not volunteer a package-wide typing pass. Reviewers treat that as a rewrite.

Docs in Sphinx or MkDocs: a missing example, not a theme

Python documentation is often a Sphinx or MkDocs site, not a single README. A first docs PR is a missing example the issue named: a snippet that does not run, a parameter nobody documented, a page that never shows the function the README promises.

It is not a theme overhaul, a toctree restructure, or a rewrite of Getting Started because you would have ordered the sections differently.

Build what they actually use. Sphinx is often make html or sphinx-build. MkDocs is mkdocs serve. If CONTRIBUTING names tox -e docs or a nox session, use that. Ship the example. Do not “improve” the theme while you are in docs/.

A docs-only merge is a real first contribution. An unasked theme PR is noise.

Data and CLI vs web: first issues are different shapes

Python is not one kind of codebase. A first issue on a data library and a first issue on a web app are different evenings. Match the shape you can boot.

Data-shaped (pandas-ish cleaning, frames, ETL that grew an API): the small task is usually an edge case. Nulls. A dtype. A one-row frame. A wrong aggregation on a duplicate index. The proof is a test on a tiny fixture, not a new algorithm. If you cannot construct the input in a few lines, the issue is not small.

CLI-shaped: a flag, a parser edge, an error message, an exit code. You run the command the project already ships. You do not stand up a server. Small means one invocation and one assertion.

Web-shaped (Flask/Django-style views): a view, a form check, a template branch, a test-client request. Setup is heavier — settings, maybe migrations, a test database. That can still be a first issue if the ticket names the view and CONTRIBUTING tells you how to run the test client. It is not the same size as a one-function data bug. Do not pick it because it sounds more “real” if you have never run this app locally.

There is no gallery of famous repos here on purpose. Labels on well-known names go stale like everything else. The hunting ground is the Python hub, issue by issue, not a list of logos.

Packaging and `pyproject.toml`

Touch pyproject.toml, build backends, requires-python, or tool configs (ruff, mypy, coverage) only if the issue asked.

Packaging nits feel small and review as policy. A pytest case that also “tidies” the build table is two reviews, and the second one often stalls the first. Same for bumping a linter so your editor is quieter. If the ticket is a test, a type, or an example, leave the project metadata alone.

After you have a candidate

The shared skeleton is short. The Python-specific part is the loop above.

Filter on the Python hub. Skip stale and claimed threads. Confirm recent merged PRs on that repo.
Read CONTRIBUTING.md for the Python setup: venv, uv, or pip install -e ".[dev]"; pytest; sometimes tox or nox. Get tests green on main first.
Comment on one issue. Do not reserve five.
Keep the diff on the ticket. Link Fixes #123. Say how you ran pytest (or the docs build). Stay for review.

Git mechanics after that: first pull request guide. Week-1 map, if you still need one: how to contribute to open source.

FAQ

What does a small Python good first issue actually look like?

Usually one of three things: a pytest case that locks the behavior in the ticket, type annotations on one public function, or a Sphinx/MkDocs example the issue said was missing. It is not a framework change, a package-wide typing pass, or a docs theme.

Someone asked for types. Should I annotate the whole module?

No. Annotate the public function the issue named. If the checker then fails on a helper that function calls, fix that helper only. A volunteer rewrite of the package’s types will not merge as a first PR.

Are Flask or Django issues good first issues?

They can be, when the ticket names a view, form, or template and you can run the project’s test client. They are a different shape than a pandas-ish data-cleaning case or a CLI flag. Pick the shape you can boot. Do not pick a web issue to look more serious.

Can I clean up `pyproject.toml` while I am in the repo?

Only if the issue asked. Packaging and tool-config diffs are policy. They stall a pytest or docs PR that would have been easy to review. Leave the build table alone unless it is the ticket.

Where do I find live Python good first issues?

On the Python hub. Filter, skip stale and claimed threads, then read CONTRIBUTING for pytest and the docs build. Other languages: helpwanted.dev. The generic search playbook lives on how to find good first issues; this page is the Python hunting ground.

Start here

Open Python good first issues. Pick one ticket that is a test, a type, or an example you can finish. Comment once, keep the diff on that job, and stay for review.