難以看懂 Hacktoberfest 得獎項目，我打造 ReadYou 摘要介紹並與項目對話

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

(Please be patient while going through the video demo 🫶)

You know what I find frustrating?

Finding an open-source project that looks genuinely cool, starting to read about it, and then getting completely lost in the technical explanation. 😭

The architecture looks interesting. The developer clearly put a lot of thought into it. But then come the unfamiliar terms, workflows and design decisions—and the feeling that I need to understand five other technologies before I can understand this one project.

I was going through Hacktoberfest winners and spending way too much time trying to figure out what each project actually did.

I kept thinking: There has to be a less exhausting way to do this.

So I started building ReadYou.

What I Built

ReadYou collects Hacktoberfest winner announcements and turns the projects into readable technical briefings, short audio introductions, and conversations about individual projects.

The idea isn’t to replace the original developer’s documentation. I want to understand the big picture first, so when I open the README, I’m not assembling the entire project from scratch in my head.

Automated Email ( as soon as the scheduler discovers new relevant announcement , digest build is created to create summaries and email is sent to notify the user )

Job Scheduling ( scans immediately and at every 3h for any new updates i.e. the winner announcements )

ReadYou is my attempt to make that first step less painful.

Code: utkarsh-g19/ReadYou on GitHub

How I Built It

I’m a student developer, and this project became a fun excuse to experiment with local AI, backend architecture and voice technology. I used ChatGPT to reason through architecture and debugging, and Codex to inspect the repository and implement changes.

The most interesting moments weren’t when something worked immediately. They were when something looked like it worked, and then I found out it was doing the wrong thing.

😭 The bug that made me rethink my research pipeline

A DEV submission can contain several GitHub links. My first approach was to retrieve the READMEs and give them to Gemma along with the submission.

Simple, right?

Except some links pointed to dependencies, examples, frameworks or unrelated repositories. Gemma could read those READMEs and confidently describe features or technologies that the actual submission didn’t have.

That’s a nasty kind of bug: the summary looks convincing, but the information underneath is wrong.

I didn’t want to keep patching individual bad summaries. I wanted to stop feeding the model the wrong information in the first place.

The classifier returns structured JSON with a relevance decision and confidence score. The backend requires a score of at least 0.85. If classification is uncertain or fails, the README is excluded and ReadYou uses the DEV submission on its own.

That threshold doesn’t guarantee Gemma can never be wrong. It makes the pipeline cautious when the evidence isn’t convincing.

There was another trap: the cache could preserve a bad summary even after I fixed the research code. ReadYou stores processed winners by submission URL, so changing the prompt alone wouldn’t repair summaries already saved.

I added targeted summary regeneration and kept previous summary versions in the cache history. I used it to regenerate affected summaries from the Build for a Friend and Touch Grass winner announcements without wiping the rest of the application state.

I learned that a reliable AI application isn’t just about writing a better prompt. Sometimes the real fix is changing what the model is allowed to see.

🧠 Playing with Gemma 4 E2B

I’m running gemma4:e2b locally through Ollama.

I chose the E2B variant as a practical starting point for local inference on student-level hardware. I wanted to experiment with an open-weight model I could run and configure myself, instead of making every AI operation depend on a hosted model API.

I’m not claiming it’s the best model for every task. Smaller models have limitations, and I noticed them quickly once I started building the chatbot.

My first attempts at project chat could be repetitive, irrelevant or overly cautious. A question like “What is this project all about?” could fall through to Hacktoberfest boilerplate instead of explaining the project.

I remember thinking: Come on, you’re looking right at the project. Just tell me what it does! 😂

The issue wasn’t just the model. My source-selection logic sometimes prioritised the wrong material for the question. I improved it so broad overview questions look for project-specific sections such as “What I Built”, rather than challenge boilerplate.

I also found a fallback that could respond with “I couldn’t put that together clearly” and then paste a technical source sentence. I changed that path to give Gemma one short retry, asking it to explain the answer plainly using the same selected sources.

Then I ran into a broader problem: people can ask the same question in very different ways. Punctuation, typos or casual phrasing shouldn’t decide whether a question is about the project. I changed the shared chat flow so Gemma assesses whether the question is about the selected project and drafts its answer from the project sources in the same call. The backend checks the supporting quotes; an unrelated question gets a redirect, and an unsupported project question gets an uncertainty response.

That’s a workflow change for all projects, not a collection of project-specific answers. But the model can still misunderstand a question, so I wanted to be clear about what I’ve actually tested.

What my tests tell me—and what they don’t

The latest backend test run passed 45 tests. These cover behaviors such as accepting a casually formatted project question when Gemma marks it as relevant, distinguishing an unrelated question from a related-but-undocumented one, rejecting an invalid scope assessment, and checking that evidence quotes appear in their cited source sections.

Those tests verify the application’s handling of model output. They are not a benchmark of Gemma’s real-world accuracy. I haven’t yet run a systematic live-model evaluation across a fixed set of projects and paraphrased questions, so I can’t claim a success rate.

That’s still work I need to do: test ordinary questions, typos and punctuation, follow-ups, unrelated questions, and questions the project sources can’t answer—and record where the model gets the scope or answer wrong.

The chat service asks Gemma for claims with supporting quotes. The backend checks that each quote appears in the cited source section. That verifies the quote and citation match; it doesn’t prove the quote logically supports every claim.

I also worked on follow-up questions and language preferences, including Hindi. I want Voice Mentor to feel like an informal conversation with a developer friend, not a report generator that has learned to add question marks.

🎙️ ElevenLabs: I didn’t want another button that just says “Listen”

The basic audio feature takes a short project introduction and uses ElevenLabs text-to-speech to generate an MP3.

I also didn’t want replaying the same introduction to trigger another generation request every time. Generated introductions are cached locally, and duplicate requests can reuse a generation that’s already in progress.

But I wanted to experiment with something more interactive. That’s where Voice Mentor came in.

Instead of making people read a complicated explanation, I wanted them to ask questions like:

• “Okay, but what does this project actually do?”
• “Why did they choose this tech stack?”
• “Can you explain that workflow more simply?”

Here’s how the voice interaction works:

It’s a sequential pipeline, not real-time speech-to-speech. ElevenLabs handles speech recognition and synthesis; Gemma does the reasoning locally.

The interface shows listening, thinking and speaking states based on what the app is doing. Users can interrupt spoken answers with another question, and typing is available if they don’t want to use a microphone. Spoken answers are cleaned up so the app doesn’t read Markdown headings and URLs aloud, while the fuller answer and its sources stay on screen.

There’s still room to improve, especially around latency and answer quality, but this is the kind of interaction I wanted to explore.

🎨 A little funk in the interface

I wanted ReadYou to feel inviting to browse, not like a plain dashboard full of project links. So I used warm cream backgrounds, chunky dark borders, and bright orange, lime and lavender accents. The cards and labels are playful, but I’ve also been adjusting the typography so the project descriptions stay comfortable to read.

🏗️ Why I kept the backend separated

I didn’t want every feature crammed into one enormous server.js file.

The backend separates winner discovery, DEV article retrieval, GitHub research, repository relevance checks, summaries, chat and ElevenLabs integration into services and controllers. The digest service coordinates the pipeline and manages cached state.

Digest data and generated MP3s are stored locally. Chat sessions stay in backend memory and expire rather than being saved in the digest cache. File-based persistence and in-memory sessions have limits, but they kept the project understandable and easy for me to debug without adding infrastructure I didn’t yet need.

The announcement scheduler checks for new DEV Team posts when the backend starts and every three hours by default while it’s running. If email is configured, ReadYou can notify me when a scan finds new winner announcements. That means I don’t have to remember to check manually, though the scheduler only runs while the backend is online.

The frontend production build passed as well.

Why Open Innovation Matters to Me

I could have built ReadYou around a hosted model API and asked it to summarise every project. That might have been the quicker route to a first demo.

Instead, Gemma runs locally through Ollama. I can inspect the prompts, change the retrieval logic and experiment with the model’s behaviour.

That doesn’t make the whole application offline. ReadYou still fetches source material from DEV.to and GitHub, and ElevenLabs handles speech transcription and synthesis. Those voice features need an internet connection and an API key.

For me, open innovation means having the freedom to understand what I’m building, change it when it doesn’t work, and share what I learned with other developers.

Learning from Previous Winners

ReadYou’s summaries helped me quickly explore past ElevenLabs category winners: Padh Ke Batao, Outside and Auditly. I could get a quick sense of what each project did, then look closer at the ideas that caught my attention.

Padh Ke Batao uses voice to make complex documents easier to understand. It got me thinking about keeping ReadYou’s audio introductions clear and concise, and caching them so replaying one wouldn’t generate it again.

Outside makes listening interactive. It inspired me to let Voice Mentor users interrupt a spoken answer and ask a follow-up question.

Auditly showed me that reliable voice interaction depends on more than speech. In ReadYou, I focused on answering from each project’s selected sources and checking that evidence quotes appear in the cited text.

I didn’t recreate these projects or all their features. I adapted ideas I found useful to a different problem: helping developers understand open-source projects.

I started by struggling to understand other people’s projects. Along the way, those same projects taught me how to build mine better. ❤️

The Lazy Payoff 🦥

I haven’t measured exactly how many minutes ReadYou saves, so I’m not going to invent a number.

The intended payoff is straightforward: get a quick understanding of a winning project, listen to its introduction, ask questions when something doesn’t make sense, and decide where to spend your deeper reading time.

The bigger payoff for me has been learning how to put local inference, evidence retrieval, backend services, caching and external speech APIs together—and how to debug the system when the output looks right but the information underneath is wrong.

The small chore I wanted to avoid was repeatedly checking for new Hacktoberfest winners, then opening every submission just to work out which projects were worth a closer look.

ReadYou checks for new DEV Team announcements when the backend starts and every three hours while it’s running. If I configure email, it can notify me when a scan finds new winners. The digest gives me a starting point: a project briefing, a short introduction I can listen to, and Voice Mentor when I want to ask a question.

I haven’t measured how much time that saves, so I won’t make up a number. The useful part is that I can catch up on projects in one place and spend my reading time on the ones that interest me.

What’s Next?

There’s still work to do.

• Better source coverage: Some DEV submissions are vague or don’t have useful READMEs. When the evidence isn’t there, ReadYou needs to say so rather than invent an explanation.
• Faster local inference: Gemma’s response time depends on the hardware, and the sequential voice pipeline adds latency.
• More voice testing: Transcription quality depends on the recording, language and service capabilities. Hindi handling has improved, but I haven’t established universal multilingual reliability.
• More chat evaluation: I need to test live Gemma responses across more projects and question styles. Source checks and focused backend tests catch some failures, but they don’t guarantee a useful conversation.
• More than Hacktoberfest winners: I’d like to adapt the same collect → check sources → summarize workflow to produce weekly briefings from technical reports and other useful publications across different websites.

I’d rather be honest about these limitations than call the project finished just because the demo works.

Prize Categories 🏆

Best Use of Gemma

Gemma 4 E2B is central to ReadYou’s research and explanation workflow. It generates project briefings, assesses whether linked repositories match a submission, and answers questions using selected project sources.

Best Use of ElevenLabs

ElevenLabs generates project introductions, transcribes spoken questions and produces spoken answers for Voice Mentor. It’s part of how users interact with the product, not just a voiceover added to a demo.

I think the interesting part is how the two fit together: Gemma helps make complicated engineering easier to understand, while ElevenLabs gives people another way to explore those explanations.

Using two partner technologies doesn’t automatically make this a winning entry. I hope the work that went into making them useful together stands out: selecting sources carefully, checking evidence quotes, handling uncertainty and making the experience feel conversational.

I started ReadYou because I was tired of struggling through technical explanations just to understand projects I found interesting.

Now I’m having a lot of fun building a tool that helps me do something about it.

Great projects deserve to be understood. ❤️

devchallenge #hf26challenge