Sefism is free for learners. We are here to help you grow, one step at a time.Join for free
Sefism.
Web

Open Source Contribution Matcher

A web service that recommends open source issues to a specific student or junior developer, based on the languages they actually write, the likely size of the change and whether the project responds to new contributors. An intermediate final year project in recommendation systems, APIs and open source data.

Topics
Difficulty

Intermediate

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

1 semester · 2 students

Deliverables

7 to ship

3 optional extras

Suggested stack

Node.jsTypeScriptPostgreSQLReactGitHub REST and GraphQL APIsBackground job queue (BullMQ or pg-boss)
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • Background ingestion of issues, pull requests and repository metadata from the GitHub API, incremental and within rate limits
  • Repository responsiveness score from median time to first response on outside pull requests, recent merges and share of outside contributions merged
  • Contributor profile inferred from the user public repositories (languages, frameworks, project size) instead of a self rating form
  • Issue suitability signals: labels, age, whether someone has already claimed it, linked pull requests and estimated change size
  • Ranked recommendations with a plain explanation of why each issue was suggested and a link to the contributing guide
  • Hand labelled evaluation set of at least 200 issues rated suitable or unsuitable for a beginner in a given language
  • Follow up tracking of which recommended issues users attempted and whether the pull request was merged

If you have time left

  • Estimating change size from the issue text and the files it is likely to touch
  • Alerts when a matching issue opens in a project the user follows
  • A public project health page maintainers can use to see how welcoming their repository looks

The problem new contributors face

Students are told to contribute to open source and to "find a good first issue". They find issues that are two years old, already claimed in a comment, or in projects where nobody reviews an outside pull request for three months. After two or three silent pull requests most people give up and conclude open source is not for them.

The failure is not finding issues; there are plenty. It is finding issues in projects that will actually respond, in a language the person really writes, sized so they can finish it in a week.

What already exists and the gap

  • Good First Issue (goodfirstissue.dev) lists curated beginner issues from popular projects, filtered by language.
  • Up For Grabs lists projects that have labelled tasks for new contributors.
  • CodeTriage emails you issues from repositories you subscribe to, to help with triage.
  • GitHub label search for good first issue and help wanted works across all repositories but ranks nothing.

The CHAOSS project (Linux Foundation) defines time to first response as a core responsiveness metric for project health, and contributor surveys consistently say responsive maintainers matter. Yet none of the finders above rank issues by how responsive the project is, and none infer a profile from your own code. That combination is the gap.

What you build

A web app with two sides:

  • Contributor: signs in with GitHub, sees an inferred skills profile they can correct, and gets a ranked list of issues with reasons ("TypeScript, small change, maintainers answered outside pull requests in a median of two days last quarter").
  • Ingestion pipeline: a set of workers that track a few thousand repositories and keep issue and responsiveness data fresh.

The technically interesting part

Two problems make this FYP-worthy.

Responsiveness as a signal. Compute, per repository, the median time to first human response on pull requests from outside contributors over the last 90 days, the share of those merged, and recent merge activity. Exclude bots and the author's own comments, as CHAOSS guidance suggests. Show your supervisor how the score is defined and validate it: do repositories with better scores actually merge more first-time contributions later?

Working within API limits. You cannot query on demand at any scale, so design an incremental pipeline: conditional requests, GraphQL for batched reads, cursors per repository, and a priority queue that refreshes active repositories more often. Report API calls per day against coverage.

How to evaluate it

  • Ranking quality: on the 200 hand labelled issues, report precision at 10 for your ranker against a baseline that sorts good first issue results by recency.
  • Signal validity: check whether the responsiveness score predicts first-time pull request merges in the following month.
  • Real use: ten students each attempt one recommended issue over four weeks; report attempts, pull requests opened, merged, and time to first review.
  • Freshness: percentage of recommended issues still open and unclaimed at click time.

Suggested plan

  1. Weeks 1 to 2: study CHAOSS metrics, pick a seed list of repositories, draft the labelling guide.
  2. Weeks 3 to 5: ingestion workers, storage and rate limit handling.
  3. Weeks 6 to 7: responsiveness score and profile inference.
  4. Weeks 8 to 10: ranker, explanations and the web app.
  5. Weeks 11 to 14: labelling, offline evaluation, student trial, write up.

Path to a product

The realistic first customer is a university society, bootcamp or programme running an open source month, who wants to point cohorts at projects that will respond. Maintainers are a second audience: a free public health page is a reason for them to share the tool. It is more likely to live as a free open source tool with sponsorship than as a paid SaaS, and that is fine; a working recommender with real merges to show is a strong portfolio project.

Scope warning

Recommendation only. Do not build a code editor, mentorship matching, a chat system or a submission workflow. Do not scrape GitHub pages; use the official API. Start with a few thousand repositories, not all of GitHub.

Learn what you need on Sefism

Get help with this idea

The signal definitions and evaluation make or break this project. Tauseef can help you define the responsiveness score, choose a seed set of repositories, and plan a labelled evaluation examiners will trust. If you are new here, create a free account first.

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.

Discuss this idea
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. Sessions are free for approved Sefism members, and a few slots open each week.

Book a free sessionSee all services

Follow along

New writing, resources and project ideas land here first.