Finding Good First Issues in Open-Source Scraping Projects

The hardest part of contributing isn't writing code, it's finding a task that's small enough to finish, important enough to be merged, and ownable enough that no maintainer is already on it. This lesson is the search recipe.

GitHub's built-in search

Start broad. GitHub's advanced search:

label:"good first issue" language:python topic:scraping is:issue is:open

Some useful variants:

• label:"help wanted", broader; not necessarily beginner.
• label:"good first issue" updated:>2026-01-01, recent activity.
• org:scrapy is:issue is:open label:"good first issue"

Bookmark these searches. Refresh weekly. The pool turns over.

Project-specific labels

Each project has its own labelling. Common patterns:

Label	Project examples	Meaning
good first issue	Many	GitHub-standard beginner label
help wanted	Scrapy, BeautifulSoup	Maintainers want community help
documentation	Almost all	Docs-only, great first contribution
low-hanging fruit	Older Python projects	Quick wins
Type: Bug + priority: low	Symfony	Stable bugs nobody's rushing

Skim a project's full label set on its issues page. You'll often find an unmentioned label like parsing-edge-case that's full of doable issues.

The hidden category: unlabeled but tractable

Most issues aren't labeled good first issue but ARE good first issues, maintainers just haven't curated. Look for:

• Reproducibility comments like "I've tried this and can confirm." If you can reproduce, you can probably fix or at least document.
• Issues with a maintainer comment outlining the fix. They're saying "this is solvable" without writing the code.
• Stale issues (no activity 6+ months) with clear scope. Often the original reporter moved on but the bug remains.
• TODO and FIXME comments in the source. Grep the repo. Many are real backlog items maintainers would accept.

git clone https://github.com/scrapy/scrapy.git
cd scrapy
grep -rn "TODO\|FIXME\|XXX" --include="*.py" | head -20

Each line is potentially a contribution starter.

Evaluating an issue

Before committing time, check:

1. Is anyone already working on it? Look at:

• Comments saying "I'll take this", check date; if >2 months ago with no PR, often abandoned.
• Linked PRs (GitHub shows them inline).
• The assigned to field.

2. Has a maintainer acknowledged the bug? If only the reporter is talking, the issue may not actually be wanted as a fix.

3. Is the scope clear? Vague issues like "make Scrapy faster" are not first contributions. Specific issues like "RetryMiddleware should respect Retry-After header" are.

4. Can you reproduce it locally? If you can't reproduce in 30 minutes, it's not first-issue material.

5. What's the test coverage strategy? If the project has tests and you can write one that fails before your fix and passes after, the PR practically writes itself.

A worked example

Suppose you find:

Issue #5432: scrapy genspider fails with "TypeError: ..." when domain contains a hyphen.

Labels: bug, good first issue Comments: A maintainer wrote "PR welcome; probably needs to update the validator in commands/genspider.py."

Score it:

• Maintainer ack: yes.
• Scope: tightly bounded.
• Reproducible: probably (you can scrapy genspider foo my-site.com locally).
• Test path: clear (write a unit test for that scenario).

This is a green light. Open the file, write a failing test, fix the validator, submit.

Bigger projects vs smaller projects

Project size	Pro	Con
Big (Scrapy, Playwright, Symfony)	Reputable name on PR; many issues; clear processes	Slower review; harder to stand out
Medium (Roach, scrapy-playwright)	Faster review; maintainers know you	Less broad reach
Small (niche scraper SDK)	Often desperate for any help; you become a core contributor fast	Lower CV value per PR

Mix both. A name-recognition PR on Scrapy plus consistent contributions on a small library is a great combo.

Filter by project health

Some projects are nominally open-source but effectively dead. Signs:

• No commits in 12+ months on main.
• Issues pile up, PRs sit unreviewed for 6+ months.
• Maintainers haven't replied in a long time.

Contributing to a dead project is sunk effort. Use isitmaintained.com or just git log --since='1 year ago' | head to gauge.

Documentation as a first contribution

Doc fixes are underrated. A well-written documentation PR shows:

• You read the project carefully enough to find a gap.
• You can write clearly.
• You're not dependent on engineering skill alone.

Most maintainers approve doc PRs faster than code PRs. Pattern: read a tutorial in their docs; find one example or sentence that confused you the first time you read it; PR a clarification.

Concrete starter list (scraping-specific)

• Scrapy: bug tracker → label good first issue. Often has 10–20 open.
• scrapy-playwright: smaller; issues triage faster.
• httpx: very active; many docs/example opportunities.
• Roach PHP: small community; high impact per PR.
• Symfony HttpClient: under the symfony/symfony monorepo. Specific component label searches help.
• playwright/playwright: huge project but has dedicated good-first-issue labels.

What to try

This week:

1. Open three of the libraries you use most in scraping.
2. Filter their issues by good first issue and help wanted.
3. Pick one issue. Comment on it: "I'm interested in working on this. Is anyone already on it? My plan is X." Wait for a maintainer reply.

You're not committed yet. You're testing whether the project is responsive and whether the issue is actually open. If yes, proceed with the PR. If no, find another.