Skip to content

Contributor roadmap

This page groups the kinds of work freshdata needs by difficulty, so you can find something that matches the time and depth you want to invest. Every tier links to live issues where they exist — always check the issue tracker for the current state, since issues get claimed and closed.

New here? Read the first-PR guide first, then come back to pick a tier. For the code layout behind these tasks, see ARCHITECTURE.md.

Claim before you build

Comment on an issue to claim it before opening a PR, so two people don't do the same work. No issue for what you want to do? Open one (or start a Discussion) so a maintainer can confirm the direction before you invest time.

🟢 Good first issues — small, self-contained, reviewable without touching the engine

Best for your first PR. These change docs, examples, or an isolated helper, so review does not depend on understanding the whole cleaning pipeline.

Skills: Python, pandas basics. You'll touch: examples/, docs/, or one named module + its test.

📖 Documentation tasks

Docs changes are the fastest way to make a real, mergeable contribution.

Skills: clear writing, Markdown, mkdocs serve to preview. You'll touch: docs/, module docstrings.

🧪 Testing tasks

freshdata enforces a 93% coverage gate, so tests are always welcome — especially "does not fire when it shouldn't" cases and fixtures.

Skills: pytest, pandas, an eye for edge cases. You'll touch: tests/, tests/fixtures/.

🐛 Bug fixes

Reproducible bugs with a named symptom — a good step up once you've landed a first PR.

Reproduce first, add a failing test, then fix. See the "Prove-it" habit in the first-PR guide.

Skills: pandas debugging, the affected subpackage. You'll touch: the named module + a regression test.

🚀 Feature development

Mid-sized, maintainer-guided additions. Confirm the API in the issue before building.

Skills: the relevant subpackage, API design sense. You'll touch: api.py, a subpackage, docs, and tests.

🏗️ Advanced architecture work

Deep changes to the engine, execution backends, or CI. Discuss the design first.

Skills: the engine or execution internals, CI, performance. You'll touch: engine/, execution/, .github/workflows/.

Where to ask

Not sure which tier fits, or want a maintainer to confirm an approach before you start? Open a thread in Discussions — that is the right place for "how should I…?" and "is this worth doing?" questions.