Good First Issue Finder for University Open Source Clubs

Problem

University open source clubs run the same cycle every semester: a session on Git, a list of links to good first issue searches, and a few weeks later most members have not opened a pull request. The issues they found were months old, already assigned, or in repositories whose maintainers had not replied to anyone in a year. Two members often start on the same issue, and coordinators cannot see who is stuck.

What you build

A web app for a club, run by its coordinators:

• A watchlist of repositories the club has chosen, including projects from local organisations and alumni, with a way for members to suggest additions.
• Ingestion of open issues and recent pull request activity for the watchlist from the GitHub API, refreshed on a schedule.
• Ranking of beginner-suitable issues by three signals, each visible to the member:
  • freshness: issue age and last activity;
  • maintainer responsiveness: median time to a first maintainer response on recent outside contributions, and the share of those that were merged;
  • stack: the repository's languages compared with the stack tags a member picks.
• Claims: a member claims an issue on the club board, the claim expires after a set time without activity, and the tool warns when someone outside the club has already said they are working on it.
• Tracking: linked pull requests move through opened, reviewed, changes requested, merged or closed, with a coordinator view of who needs help.

The Open Source Contribution Matcher idea in this library recommends issues to one person from an inferred profile. This project is a coordination tool for a group working from a curated set of projects, and its measure of success is merged pull requests.

Suggested architecture

• Node.js with TypeScript, PostgreSQL and a Next.js front end.
• A background worker that ingests through the GitHub GraphQL API, with conditional requests and incremental updates to stay inside rate limits.
• Explainable scoring in plain code with documented weights. No machine learning is needed.
• GitHub sign-in, so pull requests can be linked to members automatically.

Milestones by month

1. Month 1: conversations with two club coordinators, data model, GitHub sign-in, watchlist, ingestion worker.
2. Month 2: responsiveness metrics, ranking with explanations, issue board.
3. Month 3: claims with expiry, pull request tracking, coordinator dashboard.
4. Month 4: at least four weeks of use by a real club, evaluation, report and demo.

How it will be assessed

• A trial with a real club: members who opened and merged a first pull request, and median time from claim to merge, compared with the club's previous semester or with a group using plain label searches.
• A check of the responsiveness signal: did repositories ranked as responsive actually review members' pull requests sooner?
• Correct behaviour under GitHub rate limits, shown with logs from a full refresh.
• A clear explanation on every ranked issue.

Pitfalls

• Ranking on the good first issue label alone. Many labelled issues are stale, and many good starter issues are unlabelled.
• Rewarding low-value pull requests to inflate numbers. Maintainers notice, and it damages the club's reputation. Exclude typo-only changes from the success measure.
• Querying GitHub on every page load.
• Letting the scope grow into mentoring, chat or a course platform.