Web

Open Source Contribution Matcher

A service that finds open issues suited to a specific person, based on the languages they actually write, the size of the change and whether the project is responsive to new contributors. The good first issue label is not enough, and project responsiveness is the signal nobody surfaces.

Difficulty

Intermediate

A small team, or one strong student willing to learn something new.
Effort

1 semester, 2 students

Deliverables

5 to ship

3 optional extras

Suggested stack

Node.jsTypeScriptPostgreSQLReactGitHub API
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • Ingestion of issues and repository metadata from a public API, respecting rate limits
  • Repository health scoring from maintainer response time, recent merge activity and time to first review
  • Profile derived from a user's public repositories rather than a self assessment form
  • Ranked recommendations with an explanation of why each issue was suggested
  • Evaluation against a sample of issues labelled by hand for suitability

If you have time left

  • Estimating change size from the issue text and the files it is likely to touch
  • Tracking whether recommended issues were attempted and merged
  • Alerting when a matching issue appears in a followed project

The problem

New contributors are told to find a good first issue and discover that most are stale, already claimed, or in projects that will not review a pull request for three months. The failure is not finding issues; it is finding issues in projects that will actually respond.

What you build

Ingestion from a public API, a repository health score, a profile inferred from the user's own code, and ranked recommendations with reasons.

The signal nobody surfaces

Maintainer responsiveness. Median time to first review on recent pull requests, and the proportion of outside contributions merged, predicts a good first contribution experience far better than any label. Computing this is the core of the project.

Why inferred profiles beat forms

Asking someone to rate their skills produces unreliable input. Reading the languages and libraries in their public repositories gives a truer picture and removes a form nobody wants to fill in.

The engineering constraint

API rate limits. You cannot query on demand at any scale, so you need a background ingestion pipeline with caching and incremental updates. Designing around that constraint is a genuine part of the work.

How to evaluate it

Hand label a sample of issues as suitable or unsuitable for a beginner in a given language, then measure your ranking against those labels.

Scope warning

Recommendation only. Do not build contribution tooling, mentorship matching or a submission workflow on top.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Get guidance
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.

Follow along

New writing, resources and project ideas land here first.