This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
Worth My Time is a tool that tells a beginner whether a "good first issue" is actually worth picking up before they spend an evening on it.
I built it for my friend Akash, who works a full-time job and wants to make his first open source contributions this Hacktoberfest. He kept running into the same wall. Every time he sat down to start, he'd pick a "good first issue," open it, and find it was already claimed in the comments. Or the repo hadn't had a commit in months, so any PR he sent would just sit there. By the time he found an issue that was actually open, the evening was gone. Last week he told me he'd checked eight issues in a row and every one was taken.
With a job, he doesn't have hours to click through dozens of issues, read old comment threads and check when a repo last shipped anything. That vetting is the real work of finding a first issue, and it eats the little time he has. I wanted to do it for him.
The "good first issue" label tells you an issue is small. It doesn't tell you the things that decide whether your time gets wasted:
- Did someone already say "can I work on this?" in the comments?
- Is there already an open PR for it?
- Is the repo alive, or has nobody touched it in months?
- Do maintainers actually merge PRs from newcomers?
So the app checks all of that. You give it a GitHub username or a few languages, it finds open good-first-issues, and gives each one a verdict: Go, Risky or Skip, with the reasons in plain words. For the good ones, a local AI model writes a short beginner brief: what the issue is, which files are probably involved, and a first-contribution checklist.
Demo
🎥 Video walkthrough:
There's no live link. The AI part runs locally on my laptop, so I demoed the whole thing as it really runs instead of rushing a hosted version that only does half the job.
Code
worth-my-time
A beginner-focused Hacktoberfest issue triage app. It checks a handful of deterministic signals to decide whether a "good first issue" is worth a newcomer's time, then optionally uses a local Ollama model to write a short beginner brief.
What this project does
The app is designed to help new contributors avoid low-value or hard-to-enter issues. It searches for open GitHub issues labeled "good first issue" and filters them using rules such as:
- whether the issue already looks claimed
- whether there is an open competing PR
- whether the repository is stale or inactive
- whether the repo has a healthy newcomer merge rate
- whether the project includes a CONTRIBUTING guide
It then presents up to 15 candidates with a verdict of Go / Risky / Skip and a reason summary. If the local Ollama model is available, the app can generate a short beginner brief for the selected issue.
The problem
…How I Built It
The most important decision: the verdicts are plain, deterministic Python, and the AI only writes the explanation.
If a language model decided whether an issue was "worth it," I couldn't explain why, and it could confidently make things up. So the checks are simple rules you can read and test:
- Claimed? The code scans issue comments for phrases like "can I take this" or "assign me."
- Competing PR? It searches for open PRs that mention the issue number.
- Repo health: days since the last push, merge rate of recent PRs, merge rate for first-time contributors, and median time to merge.
- Issue quality: is the description long enough to act on, and does the repo have a CONTRIBUTING file?
Each signal adds or subtracts points. The final score becomes Go, Risky or Skip, and every reason is printed next to it. Tests cover the scoring and the claim-phrase detection.
The AI part is Gemma, running locally through Ollama. For each issue you pick, the app ranks the repo's real file paths by how well they match the issue text and gives Gemma only the top 10. It's told to choose from that list and say "not sure" otherwise, so it can't invent files. It also summarizes the issue for a beginner and builds a checklist from the repo's own CONTRIBUTING file.
Stack: Python, Gradio, the GitHub REST API, Ollama + Gemma, pytest.
How well does it work? I checked all the listed issues that my tool gave in output, all of them had the correct verdict of weather to go with them or skip them. These are heuristics, not predictions. They catch the common ways time gets wasted, but they can't read a maintainer's mind.
Why Does Open Innovation Matter?
- It costs nothing to run. My friend can search and read briefs all month without a bill or an API key to manage. For someone learning, that matters.
- I can see and change how it thinks. The scoring rules are code in a file. When my friend said a rule felt too harsh, I changed it and reran it. A closed black-box service wouldn't let me do that.
- I can swap the model. Gemma works for this, and if a better small model appears it's a one-line change.
- The brief is grounded in real files. Because I control the prompt and inputs, I constrained the model to the repo's actual file list. That made it far less likely to hallucinate than asking a chatbot "what should I edit?"
One honest note: this uses public GitHub data, so privacy wasn't the main benefit. Cost, control and the ability to change things were.
Prize Categories
- Best Use of Gemma: runs locally via Ollama and writes the beginner briefs, constrained to real file paths.
- Best Use of GitHub Copilot: Used to build and debug the app, while keeping issue scoring deterministic and explainable.
Top comments (0)