DEV Community: Isha Vishwakarma

Hacktoberfest AI Helper: Find the Right Open Source Project in Minutes

Isha Vishwakarma — Sun, 25 Oct 2026 20:55:04 +0000

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

What I Built

I built Hacktoberfest AI Helper — a lightweight web app that helps contributors find beginner-friendly open-source projects and contribution ideas based on their skill level, favorite stack, and contribution goal.

Instead of spending 30–60 minutes browsing GitHub and getting overwhelmed, the app suggests a few smart starting points such as docs work, validation tasks, AI feature experiments, React UI improvements, and community tooling. It’s built for people who want to contribute quickly without wasting time choosing the wrong project.

This project reduces the friction between “I want to contribute” and “I know where to start,” which is exactly the kind of help beginners need during Hacktoberfest.

Demo

Live demo:

ishavishwakarma29.github.io

GitHub repo:

ishavishwakarma29 / hacktoberfest-ai-helper

A quick Hacktoberfest AI challenge project finder and contribution helper.

const projectData = [ { title: "Docs and onboarding improvements" stack: ["javascript", "python", "data"] vibe: ["docs", "tooling"] goal: ["learn", "contribute"] description: "Improve setup guides, fix broken examples, and make contributor flows easier to follow.", skill: "beginner" }, { title: "AI prompt playground", stack: ["javascript", "python", "ai"], vibe: ["ai", "apps"], goal: ["build", "contribute"], description: "Create better prompt templates, validation tools, and AI-powered workflows for community projects.", skill: "intermediate" }, { title: "Accessibility and UX polish", stack: ["javascript", "react"], vibe: ["apps", "tooling"], goal: ["build", "network"], description: "Fix labels, improve keyboard flows, and make dashboards easier to use for all contributors.", skill: "beginner" }, { title: "Data and analytics helper", stack: ["python", "data", "javascript"], vibe: ["data", "tooling"], goal: ["learn", "build"], description: "Add charts, metrics summaries, or better filtering to make project insights easier to explore.", skill: "intermediate" }, { title: "Developer tooling upgrade", stack: ["javascript", "react"], vibe: ["tooling", "apps"], goal: ["contribute", "build"], description:…

View on GitHub

Code

Repository:

ishavishwakarma29 / hacktoberfest-ai-helper

A quick Hacktoberfest AI challenge project finder and contribution helper.

View on GitHub

How I Built It

I built this as a fast static web app using plain HTML, CSS, and JavaScript so it could be deployed instantly on GitHub Pages with no backend or setup friction.

The app uses a simple rules-based matching system:

skill level
favorite stack
contribution goal
project vibe

It then ranks a curated set of starter project ideas and shows the best matches instantly.

This is intentionally open-source-first and model-agnostic. It’s easy to extend with local AI workflows or open-weight LLMs later, without locking people into a proprietary platform. The current version is intentionally lightweight and easy to fork, remix, and improve.

Why Does Open Innovation Matter?

Open innovation matters because contribution barriers are one of the biggest blockers in open source.

A lot of beginners don’t need a complex tool — they need clarity. They need help answering:

What should I work on?
What fits my skill level?
Which repos are welcoming?
What’s a realistic first contribution?

A closed or proprietary system would make that discovery process more opaque and less community-driven. Open-source tools make this kind of decision support transparent, reusable, and improvable by everyone. That means more people can participate, faster, with less confusion.

My Agent Session

Not published yet, but the project is fully open and reproducible from the linked repo.

The Lazy Payoff

This saves a surprising amount of time.

Instead of:

opening 10 repos
scanning dozens of issues
deciding what’s “beginner” or “good for my stack”

…I can get 3 to 5 relevant contribution ideas in under a minute.

That’s the lazy payoff: less hunting, less decision fatigue, and more time spent actually building and submitting a contribution.

Prize Categories

Open Source AI Challenge
Developer Tools
Education / Learning
Community / Open Source Participation

Walkguide Studio: Local Gemma Tours for Independent Guides

Isha Vishwakarma — Sun, 18 Oct 2026 21:45:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Problem: Walking-tour guides know the stories behind their stops, but turning those stories into a self-guided product takes time: organizing notes, writing narration, checking facts, preparing audio, and packaging the route.
Solution: Walkguide Studio turns an operator’s route notes into a self-guided walking tour. The operator enters each stop’s name, coordinates, and facts. Gemma drafts narration from those notes, and Walkguide checks the narration for unsupported names and numbers.
Output: A map, transcripts, optional audio, and an offline tour ZIP.
Who it’s for: Independent walking-tour operators and small local museums that want a self-guided option without commissioning a custom app.
Who might pay: An operator could sell a tour ZIP or bundle it with an existing tour, booking, or visitor experience.
Current limitation: Walkguide creates and packages tours; it does not handle payments or host a storefront. I haven’t tested willingness to pay with an outside operator, so the customer and pricing assumptions still need validation.
Grounding: The operator’s notes are the source of truth. If narration includes unsupported details, Walkguide reports the rejection instead of packaging it as a finished tour.

Demo

Code

ishavishwakarma29 / WalkguideStudio

Walkguide Studio

Built during Hacktoberfest Week 2 for the DEV Open-Source AI Challenge: Side Hustle.

Demo

Click the thumbnail to watch the video.

Walkguide Studio helps an independent walking-tour operator turn their own stop notes into a self-guided tour package. The operator enters the route and their local knowledge once; Gemma, running on the operator's computer through Ollama, drafts a short narration for each stop. A grounding check rejects unsupported names and numbers. The result is a static tour with a route map, transcripts, optional audio, and an offline ZIP that the operator can share or sell through their existing channel.

The main product flow is built around open-weight AI: Studio requires a local Gemma model before it can create a package. There is no hosted model API in the path and no per-narration API charge. The original command line tools remain available for automation and for the separate…

View on GitHub

How I Built It

Language: Python 3.9+, using only the standard library.
Local AI: Gemma 3 (1B) runs on the operator’s computer through Ollama.
Narration: Gemma drafts each stop’s narration from the operator’s notes.
Validation: Walkguide checks generated names and numbers against those notes.
Packaging: The app creates a map, transcripts, optional audio, and a static ZIP that visitors can open offline.

To run the Studio:

ollama pull gemma3:1b
python studio.py

A failure shaped the design: Gemma sometimes returned generic introductions or echoed a stop heading, causing the grounding check to reject its narration. I tightened the prompt, cleaned up echoed headings, and made the Studio show why the guard rejected a draft. Unsupported narration is still blocked rather than quietly packaged as a finished tour.

Why Does Open Innovation Matter?

Lower usage costs: Local Gemma avoids a hosted-model API charge for each narration. The operator still needs hardware capable of running the model.
Local processing: The Studio sends narration requests to Ollama on the operator’s computer rather than to a hosted model API.
Adaptability: Operators can inspect and modify the prompts and validation code for their neighborhood, language, and editorial standards.

Open-weight AI makes it practical to experiment with a specialized tour product without first building around a closed provider’s API and pricing. The trade-off is that operators need a capable computer and detailed source notes; incomplete notes may lead to rejected narration.

My Agent Session

Walkguide Studio: Full Build Journey from Specification to Demo

You

Build a stdlib-only Python 3.9+ project called "walkguide" (no pip dependencies; optional external tools:
Ollama for a local Gemma model, Piper for offline TTS). It has two products that share code:

A) WALK GUIDE: an offline-first audio guide that narrates places near you while you walk.
B) TOUR PACK: for small tour operators; turns their stop list + notes into an offline, narrated, self-guided
tour (a static folder: index.html + audio files).

FILES
- sources.py: haversine, bearing, compass(deg)->"north-east" etc. Fetch POIs from OpenStreetMap Overpass
(two endpoint fallbacks; query named historic / tourism(museum|artwork|attraction|viewpoint|gallery) /
leisure(park|garden|nature_reserve) / place_of_worship / natural(peak|water|spring|wood) plus trees with
species; "out center tags 80") and Wikipedia geosearch (generator=geosearch, extracts+coordinates, intro,
plaintext, 4 sentences). Convert OSM tags to plain English sentences ("It is a church.", "It dates from
1890."). Skip OSM places with fewer than 2 facts. Merge by case-insensitive name (Wikipedia wins, add up
to 3 OSM facts). Cache per 0.01-degree cell (~1.1 km, fetch radius 800 m around the cell centre) as JSON
files; only cache when BOTH sources succeeded. Support offline mode (cache only).
nearby(lat, lon, cache_dir, offline, max_dist) returns POIs with dist and bearing, sorted by distance.
- narrator.py: build a prompt (Place, Location, up to 8 "Fact:" lines) and call Ollama /api/chat
(stream false, temperature 0.4, num_predict 140, default model gemma3:1b). Accept a custom system prompt
and max sentence count. GROUNDING GUARD: reject output if any number is not in the source text (name +
location + facts), or if any capitalised word that is not the first word of a sentence is not in the
source (allow "I" and compass words). On rejection retry once at temperature 0.1, then fall back to a
deterministic template built from the facts. Strip markdown, trim to N sentences. Return (text, meta)
with meta = {source: "llm"|"template", attempts, rejected: [...], latency_s}. Never crash if Ollama is down.
- speak.py: make_speaker(piper_model) returns a blocking speak(text) using, in order: Piper (+ aplay/
afplay/paplay/ffplay), termux-tts-speak, macOS say, espeak-ng/espeak, Windows System.Speech; None if
nothing is found. synth(text, base_path, piper_model) writes <base>.wav (Piper, say -o ... --data-format= LEI16@22050, or espeak -w), converts to .mp3 if ffmpeg exists, returns the path or None.
- app.py (walk loop; CLI via argparse): location sources: --lat/--lon (fixed, 3 ticks), --walk
"lat,lon;lat,lon" (interpolated every 20 m), --gpx file, --termux (termux-location JSON, retry every 5 s
on failure). Flags: --model, --ollama-host, --piper-model, --trigger 60 (m), --cooldown 15, --tick 2,
--offline, --prefetch (cache 3x3 cells then exit), --no-speak, --reset. Each tick: track heading from
movement >5 m, find unvisited POIs within the trigger distance, pick the best by richness (fact length,
+2 for Wikipedia) minus dist/40, describe position as "about 40 metres ahead of you / on your left /
behind you / on your right" (or a compass direction when heading is unknown), narrate, speak, persist
visited IDs, append to metrics.jsonl, honour the cooldown. Simulated walks use a virtual clock at
1.4 m/s; --termux uses the wall clock. Print a summary on exit (narrations, model vs template,
guard rejections, mean latency) and save walks/walk-<timestamp>.json + .html.
- summary.py: build_html(walk) makes a self-contained Strava-style HTML page: SVG route map (equirectangular
projection fitted to the box, start green, end red, numbered pins for narrated places), stats (distance,
time, pace, places, avg model latency, guard rejections), a narration timeline (elapsed time, place,
position, sentence, badge "model name" or "template fallback", guard blocks). Light/dark via
prefers-color-scheme, mobile responsive, no external resources. Also --demo (fictional sample data)
and summary.py walks/x.json.
- tourpack.py: input JSON {title, operator, stops:[{name, lat, lon, notes}]}. For each stop: split the
operator's notes into sentences (FIRST and highest priority), optionally add up to 3 OSM/Wikipedia facts
when the name clearly matches or a Wikipedia POI is within 40 m (--no-enrich disables), location text
"Stop i of N", narrate with a tour-guide system prompt (3-5 short spoken sentences, use ONLY the facts,
start by saying which stop this is), then synth audio. Output tours/<slug>/index.html, audio/, and
build_report.json (per-stop source, latency, rejections, audio yes/no). index.html is ONE static file with
the tour data embedded (escape "</"): SVG map with dashed route + numbered pins (current / played
states), tap-to-play stops with transcript text, an <audio> element, an "Auto-play when I arrive"
checkbox using navigator.geolocation.watchPosition (arrival radius 40 m, play each stop once, don't
interrupt playback, needs HTTPS), a blue "you" dot, and a fallback to speechSynthesis when a stop has
no audio file. Light/dark, mobile-first, no external resources.
- tests.py: plain-assert offline tests (guard accepts grounded text and rejects invented numbers/names,
template fallback works with no model, model-offline falls back, walk interpolation, where() phrasing,
offline cache round-trip).
- sample_tour.json (clearly FICTIONAL stops) and README.md (setup for Ollama/Piper/Termux, all commands).

RULES
- Stdlib only. Never crash on network failure: print a short notice and degrade gracefully.
- Every sentence spoken must pass the grounding guard or be replaced by the template.
- Do not invent facts about real places in any sample data; label samples as fictional.
- After writing, run tests.py, run python3 tourpack.py sample_tour.json --model "" --no-enrich, syntax-check
the player's JavaScript, and fix anything that fails. Report what you could not test (live network, Ollama,
real TTS, browser rendering).

Agent

walkguide is ready

The project is in outputs. It includes the walking guide, offline place cache, grounded narrator, optional speech adapters, self-contained walk summaries, static tour builder, tests, and setup instructions.

The sample tour was generated at index.html; its build report is build_report.json. Start with the README.

Verification: tests.py passed, the requested sample tour command completed, all Python modules compiled, and the tour player JavaScript passed node --check. The Windows python3 launcher was unavailable, so I ran the checks with the installed Python 3.13 python command. Live network lookups, Ollama, real TTS, and browser rendering were not tested.

A possible DEV Challenge angle is Hacktoberfest Week 2’s Side Hustle theme, whose listed deadline is October 19; the project would need open source AI to be central to its use to be a clear fit. I can draft a DEV post about the build if you’d like.

🌐 Community Wisdom

The DEV research was limited to two adjacent posts. One describes building a zero dependency Python CLI and its tradeoffs; the other stresses durable local storage and controlled retries for offline resilience. Neither directly evaluates this project’s geospatial or narration design.

Zero Dependencies, Zero Regressions: What It Took to Build CLI-KDG from Scratch

Source: Pravin Kumar

Tags: cli, python, softwareengineering, testing

The author describes replacing common CLI and testing packages with Python’s standard library, including explicit JSON persistence and dependency auditing. This supports the stdlib-only constraint, though the article covers a different tool.

🔗 Read Full Discussion

Designing an Offline-Resilient MQTT Buffer with SQLite

Source: Kaustubh Alandkar

Tags: mqtt, python, systemdesign

The author emphasizes persisting data before relying on a downstream service, and making retry behavior explicit. That reinforces treating cache writes and graceful network failure as core behavior; the post’s SQLite buffer is a different use case.

🔗 Read Full Discussion

You

how to record a demo for this

Agent

For a quick demo, record a screen capture of the sample tour. It works without network access, Ollama, or audio hardware.

Open outputs/tours/the-imaginary-lantern-walk/index.html in a browser.
Start recording your screen with the built-in recorder:
- Windows: press Win + Alt + R (Xbox Game Bar).
- macOS: press Shift + Command + 5, then choose Record.
Show the tour map and stops, tap Play on a stop, and show the transcript and playback controls.
To demonstrate arrival playback, check Auto-play when I arrive on an HTTPS-hosted copy and allow location access. The sample stops are fictional and far from your location, so that feature won’t trigger with the sample tour.
Stop recording and save the video.

For a demo of the walking guide itself, run a simulated route with python app.py --walk "lat,lon;lat,lon" --offline --no-speak, using coordinates from a cached area. You can prefetch an area first with python app.py --lat LAT --lon LON --prefetch while online.

You

give complete path its not opening

Agent

The complete path to the sample tour is:

[local path]

Copy that into File Explorer’s address bar and press Enter.

You

i dont understand what i have to do in thiss and how is open source used

Agent

walkguide has two parts:

Tour Pack turns a tour operator’s list of stops and notes into a web page people can open and follow.
Walk Guide can find nearby places and narrate them while you walk.

The sample tour is fictional, so it’s just a demonstration. Open this file in a browser:

[local path]

You’ll see a map and three sample stops. Click Play to hear a stop if your browser supports speech synthesis; otherwise, read its transcript.

How open source is used: the project itself is code you can inspect and change. It also can use the open-weight Gemma model through Ollama to write narrations locally. That’s optional: without Ollama, it uses simple templates based on the supplied facts. The sample tour was built with the model turned off, so it demonstrates the template fallback—not Gemma.

To try Gemma, install Ollama, download the gemma3:1b model, start Ollama, then build a tour with:

python tourpack.py sample_tour.json --model gemma3:1b --no-enrich

The tour’s notes remain the narration’s facts; the model turns those facts into spoken sentences. The open-weight model runs on your computer rather than requiring a paid model API.

You

https://dev.to/devteam/join-the-hacktoberfest-open-source-ai-challenge-side-hustle-2550-in-prizes-across-18-winners-55ba?bb=264692 i am building it for this so build accordingly considering it should be worth winning

Agent

I reshaped Walkguide around one customer: independent tour operators who want to turn their own local knowledge into offline tours they can share or sell. The new local Studio guides them through entering stops and notes, using Gemma locally to draft grounded narration, previewing the tour, and downloading a ZIP for customers. Gemma is required in that Studio flow; the template fallback remains available in the CLI tools.

To try it: install Ollama, then in PowerShell run:

cd "[local path]"
ollama pull gemma3:1b
python studio.py

Studio opens at http://[REDACTED]:8765. Replace the clearly fictional sample stops with real operator notes and coordinates, then create, preview, and download the tour. Setup details are in the README.

Important for the challenge: the page says Week 2 submissions are due October 18 at 11:59 PM PDT—about 15½ hours from now in India—and that open-weight AI must be central. It also says writing quality carries the most weight and encourages showing a real user’s feedback. Challenge details

The checks passed: offline assertions, sample tour generation, Python compilation, and JavaScript syntax checks. Ollama isn’t installed on this computer, so I couldn’t verify a real Gemma narration. The sandbox also blocked local browser connections, so I couldn’t visually verify Studio running. Before submitting, run it with Gemma, record the real workflow, and—if possible—have one tour operator try it. Don’t present the fictional sample as a real tour or claim customer validation you haven’t done.

You

i get oolama is not recognized

Agent

It sounds like Ollama isn’t installed yet. On Windows, download and run the installer from Ollama’s official download page, then close and reopen PowerShell. The installer adds the ollama command; reopening PowerShell lets it find it. (Official Windows download)

Then run these commands one at a time:

ollama --version
ollama pull gemma3:1b
cd "[local path]"
python studio.py

If the first command still says “not recognized,” restart your computer and try it again.

You

its working now how to record demo

Agent

Here’s a simple demo flow:

Open Walkguide Studio in your browser and make sure the green Ready status appears.
Replace the fictional sample with a short tour you know is accurate. Keep 2–3 stops so the demo stays brief.
Press Win + Alt + R to start recording.
Click Create Gemma tour. Show the finished preview, play a stop, then show the Download tour ZIP link.
Press Win + Alt + R again to stop. The MP4 should be in Videos → Captures. (Microsoft’s Game Bar recording instructions)

You can narrate: “I’m a small tour operator. I add my own notes, Gemma runs locally to turn them into a grounded audio guide, and I download a tour I can share with visitors.”

If Game Bar doesn’t start, press Win + G and enable recording, or open Snipping Tool and choose Record. (Microsoft’s recording options for Windows)

You

give me tour around banglore

Agent

I’ve set Studio’s default route to Bengaluru: Green Spaces & Granite. Restart Studio so the updated stops appear: in the PowerShell window running it, press Ctrl+C, then run:

cd "[local path]"
python studio.py

Refresh the Studio page. It will be prefilled with this short central Bengaluru route:

Cubbon Park — established in 1870 by John Meade; its landscape was conceived by Richard Sankey. Government of Karnataka
Vidhana Soudha — Karnataka’s Legislature and Secretariat; completed in 1956 and built largely with Bangalore granite. Karnataka Legislature
Attara Kacheri — home of the Karnataka High Court, described by the district tourism site as a red brick and stone building in the Graeco-Roman style. Bengaluru Urban district

Wait for Gemma’s status to show Ready, then click Create Gemma tour. The pins are approximate outdoor viewpoints, and the map’s connecting line is not pedestrian turn-by-turn directions—check local access and walking paths before visiting.

I also saved the tour data in bengaluru_demo_tour.json and the source and coordinate notes. The JSON and Python checks passed.

You

Gemma did not produce any grounded narration. No tour ZIP was offered; revise the notes and try again. i am getting this

Agent

Your notes are fine. The saved report shows Gemma’s formatting—such as “Stop 1 of 3: Welcome…”—was tripping the grounding check.

I’ve updated the code to normalize that stop heading and tighten the prompt. Restart Studio so it loads the fix:

In the PowerShell window running Studio, press Ctrl+C.
Run python studio.py again.
Refresh the Studio page, wait for Gemma to show Ready, and click Create Gemma tour again.

If it still fails, the updated error should include the guard blocks. The full report is at [local path].

The offline tests and the specific stop-heading guard check pass. I couldn’t call your local Ollama service from this sandbox, so please retry in your running Studio.

You

is it now safe to add on git with proper readme and stuff ? also https://youtu.be/NbL-dx2ZQpA embed this video in readme and also mention that its builr in hacktoberfest week2

Agent

The project files look safe to put in a public Git repository, and I updated the README with the demo video and the Hacktoberfest Week 2 credit. I also added a .gitignore to keep generated tours, local walk data, Python cache files, and speech model files out of Git.

One catch: this outputs folder is not currently a Git repository, so nothing has been added or committed yet. Open this folder in your terminal to start:

cd "[local path]"

If you want, I can help you connect it to a new GitHub repository next.

You

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

My First User

Prize Categories

fill this template too for me

Agent

I saved the completed post as a DEV draft: Open and edit it on DEV.

Before publishing: replace the GitHub placeholder with your public repository URL. Your project folder isn’t a GitHub repository yet, so the draft says that plainly. I left out the optional “My First User” and “My Agent Session” sections because we don’t have real user feedback or a session link to include. The draft is marked as AI-assisted (some_ai).

The Week 2 deadline is October 19 at 12:29 PM IST. The draft has the required hf26challenge tag and lists “Best Use of Gemma.” Challenge details

Walkguide Studio: Local Gemma Tours for Independent Guides

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Walkguide Studio turns a local tour operator's own notes into a self-guided walking tour. The operator enters stops, coordinates, and facts; Gemma drafts short narration grounded in those notes. Walkguide checks the generated text for unsupported names and numbers, then packages a map, transcripts, optional audio, and an offline tour ZIP.

The intended customer is an independent walking-tour guide, museum, or neighborhood business that wants to offer a self-guided tour without commissioning a custom app or paying for a hosted AI call for every narration. They could sell or bundle the tour ZIP with their existing booking or visitor experience. Walkguide does not handle payments, and I have not yet validated willingness to pay with an operator—this is the customer problem I built toward.

Demo

Code

GitHub repository: [Add the public repository URL here before publishing.]

The project is currently in my local folder, so there is no public repository URL to share yet.

How I Built It

Walkguide is written in Python 3.9+ using the standard library. The Studio UI and local server are built into the project. It calls Gemma 3 (1B) through Ollama on the operator's computer; the app does not send tour notes to a hosted model API. The operator's notes are the grounding source. A validation step rejects narration that introduces unsupported names or numbers, and the generated tour is a static package that can be opened offline.

One failure shaped the implementation: Gemma sometimes returned generic introductions or echoed stop headings instead of starting with grounded narration. I tightened the prompt and normalized echoed headings, while keeping the grounding check as a hard stop. If the model still cannot produce grounded narration, the build reports the rejection instead of quietly presenting it as a successful tour.

Why Does Open Innovation Matter?

The local, open-weight model is part of the product's business case. A small tour operator can run narration generation on their own computer, keep their route notes in that local workflow, and avoid a hosted-model charge for each tour. They can also inspect and adapt the generation and validation code for local history, languages, and operating constraints. That makes it possible to experiment with a niche tour product without first committing customer data or the business model to a closed API provider.

Prize Categories

Best Use of Gemma

You

https://github.com/ishavishwakarma29/WalkguideStudio add this repo and also add the dev relay session also the points are not mentioned such that it describes problem and emphasises solution properly. writing carries most weight in judging

Agent

Updated the existing DEV draft with your GitHub repository, embedded a new DevRelay session, and rewrote the post to make the operator’s problem, Walkguide’s solution, and the unvalidated customer assumptions clearer.

Open the updated DEV draft. It remains unpublished for your review and is marked AI-assisted.

You

its not updated yet

Agent

I checked DEV’s saved draft: it does contain the GitHub link, the DevRelay session embed, and the revised sections. It’s still unpublished, so the public post won’t show those edits yet.

Open the draft editor and refresh the page. If you were looking at the public post, switch to the draft editor instead.

You

no when i copy and open this link it doesnt show

Agent

I found the issue: the link opens DEV’s sign-in page because you aren’t signed in there in this browser. The draft is saved, but you’ll need to sign into the DEV account Isha Vishwakarma (ishavishwakarma29) to see its editor.

The DEV sign-in page is open in the in-app browser. After signing in, open the draft editor again.

You

even in signed in tab in chrome its not showing

Agent

Sorry—I was too certain that signing into Chrome would make that link work. I can verify DevRelay saved the draft under ishavishwakarma29, but I can’t see which DEV account Chrome is signed into.

In Chrome, open your DEV dashboard, choose Drafts, and look for “Walkguide Studio: Local Gemma Tours for Independent Guides.” DEV says drafts are available from your dashboard. DEV Help: Writing, Editing and Scheduling

Check that your profile handle is ishavishwakarma29. If the draft still isn’t listed under that account, tell me what you see on the Drafts page—or share a screenshot—and I’ll help fix the mismatch.

You

got it now, write up is not nice, it should be point by point with bold etc to emphasize give me markdown here only

Agent

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

The problem: A walking-tour guide may know the stories behind every stop, but turning that knowledge into a self-guided product takes extra work: shaping notes into short narrations, checking facts, preparing audio, and packaging everything for visitors.

The solution: Walkguide Studio turns an operator’s own route notes into a self-guided walking tour. The operator adds stops, coordinates, and facts. Gemma drafts the narration from those notes, and Walkguide checks it for unsupported names and numbers before packaging a map, transcripts, optional audio, and an offline ZIP.

Who could pay: Independent walking-tour operators and small local museums that want to offer a self-guided option without commissioning a custom app. They could sell or bundle a tour ZIP with an existing tour or visitor experience.

What’s built today: Walkguide creates and packages tours; it does not process payments or host a storefront. I haven’t yet tested willingness to pay with an outside operator, so the customer and pricing assumptions still need validation.

The design principle: Grounding is a gate. If the narration includes unsupported details, Walkguide reports the failure instead of offering an ungrounded tour ZIP as ready.

Demo

Code

WalkguideStudio on GitHub

How I Built It

Language: Python 3.9+, using only the standard library.
Local AI: Gemma 3 (1B) runs through Ollama on the operator’s computer.
Grounding: The operator’s notes are the source for each stop’s narration. A validation step checks generated names and numbers against those notes.
Output: Walkguide packages a map and transcripts into a static tour ZIP that visitors can open offline. Audio is optional.

To run the Studio:

ollama pull gemma3:1b
python studio.py

A failure shaped the design: Gemma sometimes returned generic introductions or repeated a stop heading, causing the grounding check to reject the narration. I tightened the prompt, cleaned up echoed headings, and made the Studio show the guard’s reasons. The check still blocks unsupported narration instead of quietly weakening the factual standard.

Why Does Open Innovation Matter?

Lower per-tour AI costs: Local inference avoids a hosted-model API charge for every narration. The operator still needs hardware capable of running Gemma.
More control over tour notes: The Studio sends narration requests to Ollama running locally; it does not send those notes to a hosted model API.
Room to adapt: Operators can inspect and modify the project’s prompts and validation code for their neighborhood, language, and editorial standards.

Open-weight AI makes it practical to experiment with a small, specialized tour product without building around a closed model provider’s API and pricing. The trade-off is that operators need a capable computer and good source notes; incomplete notes may lead to rejected narration.

My Agent Session

{% agent_session building-walkguide-studio-with-local-gemma-uf8pxg %}

Prize Categories

Best Use of Gemma

You

in markdown here

Agent

*This is a submission for the [Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle](https://dev.to/challenges/hacktoberfest-week2-2026-10-12)*

## What I Built

**The problem:** A walking-tour guide may know the stories behind every stop, but turning that knowledge into a self-guided product takes extra work: shaping notes into short narrations, checking facts, preparing audio, and packaging everything for visitors.

**The solution:** Walkguide Studio turns an operator’s own route notes into a self-guided walking tour. The operator adds stops, coordinates, and facts. **Gemma drafts the narration from those notes**, and Walkguide checks it for unsupported names and numbers before packaging a map, transcripts, optional audio, and an offline ZIP.

**Who could pay:** Independent walking-tour operators and small local museums that want to offer a self-guided option without commissioning a custom app. They could sell or bundle a tour ZIP with an existing tour or visitor experience.

**What’s built today:** Walkguide creates and packages tours; **it does not process payments or host a storefront**. I haven’t yet tested willingness to pay with an outside operator, so the customer and pricing assumptions still need validation.

**The design principle:** Grounding is a gate. If the narration includes unsupported details, Walkguide reports the failure instead of offering an ungrounded tour ZIP as ready.

## Demo

[![Watch the Walkguide demo](https://img.youtube.com/vi/NbL-dx2ZQpA/hqdefault.jpg)](https://youtu.be/NbL-dx2ZQpA)

## Code

[WalkguideStudio on GitHub](https://github.com/ishavishwakarma29/WalkguideStudio)

## How I Built It

- **Language:** Python 3.9+, using only the standard library.
- **Local AI:** Gemma 3 (1B) runs through Ollama on the operator’s computer.
- **Grounding:** The operator’s notes are the source for each stop’s narration. A validation step checks generated names and numbers against those notes.
- **Output:** Walkguide packages a map and transcripts into a static tour ZIP that visitors can open offline. Audio is optional.

To run the Studio:

```powershell
ollama pull gemma3:1b
python studio.py

Why Does Open Innovation Matter?

Lower per-tour AI costs: Local inference avoids a hosted-model API charge for every narration. The operator still needs hardware capable of running Gemma.
More control over tour notes: The Studio sends narration requests to Ollama running locally; it does not send those notes to a hosted model API.
Room to adapt: Operators can inspect and modify the project’s prompts and validation code for their neighborhood, language, and editorial standards.

My Agent Session

{% agent_session building-walkguide-studio-with-local-gemma-uf8pxg %}

Prize Categories

Best Use of Gemma ```

You

markdown is incomplete

Agent

*This is a submission for the [Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle](https://dev.to/challenges/hacktoberfest-week2-2026-10-12)*

# Walkguide Studio: Local Gemma Tours for Independent Guides

## What I Built

**The problem:** Walking-tour guides often have the local knowledge already. Turning it into a polished self-guided tour takes additional work: organizing notes into short narrations, checking facts, preparing audio, and packaging the route for visitors.

**The solution:** Walkguide Studio turns a tour operator’s route notes into a self-guided walking tour. The operator provides each stop’s name, coordinates, and facts. **Gemma drafts narration from those notes**, and Walkguide checks the generated text for unsupported names and numbers before creating a map, transcripts, optional audio, and an offline ZIP.

**Who it’s for:** Independent walking-tour operators and small local museums that want to offer a self-guided option without commissioning a custom app.

**Who might pay:** An operator could sell the tour ZIP or bundle it with an existing tour, booking, or visitor experience. Walkguide creates and packages tours; **it does not process payments or host a storefront**. I haven’t yet tested willingness to pay with an outside operator, so this is a customer and pricing hypothesis that still needs validation.

**What makes the solution useful:** The operator’s notes remain the source of truth. If narration includes unsupported details, Walkguide reports the rejection instead of packaging it as a finished tour.

## Demo

[![Watch the Walkguide demo](https://img.youtube.com/vi/NbL-dx2ZQpA/hqdefault.jpg)](https://youtu.be/NbL-dx2ZQpA)

## Code

[View WalkguideStudio on GitHub](https://github.com/ishavishwakarma29/WalkguideStudio)

## How I Built It

Walkguide is written in **Python 3.9+ using only the standard library**. The local Studio interface collects the route and notes, then Ollama runs **Gemma 3 (1B)** on the operator’s computer to draft narration.

The main flow is:

1. **Enter the route:** Add stop names, coordinates, and source notes.
2. **Draft narration:** Gemma generates concise narration using the provided notes.
3. **Check grounding:** Walkguide checks generated names and numbers against the notes.
4. **Package the tour:** The app creates a map, transcripts, optional audio, and a static ZIP that visitors can open offline.

To start the Studio:

```powershell
ollama pull gemma3:1b
python studio.py

A failure shaped the design: Gemma sometimes returned generic introductions or echoed a stop heading, causing the grounding check to reject the narration. I tightened the prompt, cleaned up echoed headings, and made the Studio show why the guard rejected a draft. Unsupported narration is still blocked rather than quietly packaged as a finished tour.

Why Does Open Innovation Matter?

Avoid per-generation hosted-model charges: Gemma runs locally through Ollama, so the operator does not need a hosted model API for each narration. They still need hardware capable of running the model.
Keep the model workflow local: The Studio sends narration requests to the local Ollama service rather than a hosted model API.
Adapt the tool to local needs: Operators can inspect and modify the prompts and validation code for their neighborhood, language, and editorial standards.

Open-weight AI makes it practical to experiment with a specialized tour product without first building around a closed provider’s API and pricing. The trade-off is that operators need a capable computer and sufficiently detailed source notes; incomplete notes may lead to rejected narration.

My Agent Session

{% agent_session building-walkguide-studio-with-local-gemma-uf8pxg %}

Prize Categories

Best Use of Gemma ````

You

its still half markdown half normal text

Agent

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

Walkguide Studio: Local Gemma Tours for Independent Guides

What I Built

Problem: Walking-tour guides already know the stories behind their stops, but turning that knowledge into a self-guided product takes extra work: organizing notes, writing concise narration, checking facts, preparing audio, and packaging the route for visitors.
Solution: Walkguide Studio turns an operator’s route notes into a self-guided walking tour. The operator enters each stop’s name, coordinates, and facts. Gemma drafts narration from those notes, and Walkguide checks the generated text for unsupported names and numbers.
What the operator gets: A map, transcripts, optional audio, and an offline tour ZIP.
Who it’s for: Independent walking-tour operators and small local museums that want a self-guided option without commissioning a custom app.
Who might pay: An operator could sell the tour ZIP or bundle it with an existing tour, booking, or visitor experience.
Current limitation: Walkguide creates and packages tours; it does not process payments or host a storefront. I haven’t tested willingness to pay with an outside operator, so the customer and pricing assumptions still need validation.
Grounding: The operator’s notes remain the source of truth. If narration includes unsupported details, Walkguide reports the rejection instead of packaging it as a finished tour.

Demo

Code

View WalkguideStudio on GitHub

How I Built It

Language: Python 3.9+, using only the standard library.
Local model: Gemma 3 (1B), run on the operator’s computer through Ollama.
Narration source: The operator’s notes for each tour stop.
Validation: Walkguide checks generated names and numbers against those notes.
Output: A map, transcripts, optional audio, and a static ZIP visitors can open offline.

To run the Studio:

ollama pull gemma3:1b
python studio.py

Why Does Open Innovation Matter?

Lower usage costs: Local Gemma avoids a hosted-model API charge for each narration. The operator still needs hardware capable of running the model.
Local processing: The Studio sends narration requests to Ollama on the operator’s computer rather than to a hosted model API.
Adaptability: Operators can inspect and modify the prompts and validation code for their neighborhood, language, and editorial standards.

My Agent Session

{% agent_session building-walkguide-studio-with-local-gemma-uf8pxg %}

Prize Categories

Best Use of Gemma

You

still same problem

Agent

*This is a submission for the [Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle](https://dev.to/challenges/hacktoberfest-week2-2026-10-12)*

# Walkguide Studio: Local Gemma Tours for Independent Guides

## What I Built

- **Problem:** Walking-tour guides know the stories behind their stops, but turning those stories into a self-guided product takes time: organizing notes, writing narration, checking facts, preparing audio, and packaging the route.
- **Solution:** Walkguide Studio turns an operator’s route notes into a self-guided walking tour. The operator enters each stop’s name, coordinates, and facts. **Gemma drafts narration from those notes**, and Walkguide checks the narration for unsupported names and numbers.
- **Output:** A map, transcripts, optional audio, and an offline tour ZIP.
- **Who it’s for:** Independent walking-tour operators and small local museums that want a self-guided option without commissioning a custom app.
- **Who might pay:** An operator could sell a tour ZIP or bundle it with an existing tour, booking, or visitor experience.
- **Current limitation:** Walkguide creates and packages tours; it does not handle payments or host a storefront. I haven’t tested willingness to pay with an outside operator, so the customer and pricing assumptions still need validation.
- **Grounding:** The operator’s notes are the source of truth. If narration includes unsupported details, Walkguide reports the rejection instead of packaging it as a finished tour.

## Demo

[![Watch the Walkguide demo](https://img.youtube.com/vi/NbL-dx2ZQpA/hqdefault.jpg)](https://youtu.be/NbL-dx2ZQpA)

## Code

[View WalkguideStudio on GitHub](https://github.com/ishavishwakarma29/WalkguideStudio)

## How I Built It

- **Language:** Python 3.9+, using only the standard library.
- **Local AI:** Gemma 3 (1B) runs on the operator’s computer through Ollama.
- **Narration:** Gemma drafts each stop’s narration from the operator’s notes.
- **Validation:** Walkguide checks generated names and numbers against those notes.
- **Packaging:** The app creates a map, transcripts, optional audio, and a static ZIP that visitors can open offline.

To run the Studio:

    ollama pull gemma3:1b
    python studio.py

**A failure shaped the design:** Gemma sometimes returned generic introductions or echoed a stop heading, causing the grounding check to reject its narration. I tightened the prompt, cleaned up echoed headings, and made the Studio show why the guard rejected a draft. **Unsupported narration is still blocked** rather than quietly packaged as a finished tour.

## Why Does Open Innovation Matter?

- **Lower usage costs:** Local Gemma avoids a hosted-model API charge for each narration. The operator still needs hardware capable of running the model.
- **Local processing:** The Studio sends narration requests to Ollama on the operator’s computer rather than to a hosted model API.
- **Adaptability:** Operators can inspect and modify the prompts and validation code for their neighborhood, language, and editorial standards.

**Open-weight AI makes it practical to experiment with a specialized tour product** without first building around a closed provider’s API and pricing. The trade-off is that operators need a capable computer and detailed source notes; incomplete notes may lead to rejected narration.

## My Agent Session

{% agent_session building-walkguide-studio-with-local-gemma-uf8pxg %}

## Prize Categories

- **Best Use of Gemma**

You

priz =e categories also need detail

Agent

## Prize Categories

- **Best Use of Gemma:** Gemma 3 (1B) is the core narration model in Walkguide Studio. It runs locally through Ollama and turns an operator’s notes for each stop into concise tour narration. Walkguide then checks names and numbers against those notes and rejects unsupported narration. Gemma is central to generating the tour content, not an optional add-on.
- **Other partner categories:** None. Walkguide does not currently integrate the other challenge partners’ technologies.

You

the dev relay session is incomplete it should be from start

You

The saved DevRelay session is incomplete; it should cover the project from the start.

My First User

Yet to offer to local tour guides

Prize Categories

Best Use of Gemma: Gemma 3 (1B) is the core narration model in Walkguide Studio. It runs locally through Ollama and turns an operator’s notes for each stop into concise tour narration. Walkguide then checks names and numbers against those notes and rejects unsupported narration. Gemma is central to generating the tour content, not an optional add-on.

What Does My Neighborhood Sound Like? I Built Hushmap to Find Out

Isha Vishwakarma — Sun, 11 Oct 2026 20:59:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Most city maps show what a place looks like. Hushmap explores what it sounds like.

It’s a local-first prototype for people who want to notice the soundscape around them. On a walk, you can record a four-second clip or choose a short audio file. Hushmap runs the open YAMNet audio model in your browser and displays broad Birds, Traffic, Water, and People scores. You can save scores privately in your browser or export them.

The map and its suggested walks use clearly labeled illustrative sample data. Hushmap doesn’t yet map real community observations or provide actual routes. The idea is to make a walk an excuse to pause, listen, and notice the sounds around you.

Demo

Code

ishavishwakarma29 / HushMap

Hushmap

A soundscape atlas for your city. Hushmap lets you pause on a walk, listen to the place around you, and classify a short sound clip right in your browser. Recordings stay on your device; you decide whether to save or export the resulting scores.

Built for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

Demo

Watch the Hushmap demo on YouTube

The map presents an illustrative neighborhood soundscape. The demo also shows YAMNet classifying audio locally in the browser.

What Hushmap does

Explore an interactive neighborhood soundscape map and try quiet, birdsong, water, and city-sound searches.
Record a four-second clip or select an audio file up to 20 seconds for on-device classification.
See broad Birds, Traffic, Water, and People scores derived from YAMNet’s AudioSet labels.
Save scores to a private browser notebook or export them as JSON.
Optionally share derived scores and an audio embedding with a…

View on GitHub

How I Built It

I built the interface as a small JavaScript app and used ONNX Runtime Web to run YAMNet in the browser. The model takes a short mono audio sample, produces AudioSet sound-class scores and embeddings, and Hushmap groups some labels into four broad categories.

The recording is processed in memory and discarded after classification. Scores stay in the browser unless the user saves or exports them. There is also an optional Tiger Data/pgvector integration path that requires a separate consent action and a configured database; I haven’t connected it to a live service.

Why Does Open Innovation Matter?

A neighborhood recording might contain a private conversation or a child’s voice. With a cloud-only classifier, the audio would have to leave the device to get sound labels. Using open model weights lets Hushmap run classification in the browser, so the raw recording can stay local.

Open weights and labels also let builders inspect the model’s vocabulary and adjust how sound labels are grouped. This is a prototype, though: the category scores aren’t calibrated environmental measurements, and the sample map isn’t collected community data.

My Agent Session

Hushmap: Full Project Conversation Before DevRelay

You

1. "Hushmap" — an open soundscape atlas of your city\
\
Everyone maps what places look like; nobody maps what they sound like. You walk, your phone records short clips, open audio models (YAMNet/BirdNET) classify them on-device — birdsong density, traffic roar, water, human noise — and only the scores get uploaded. The result: a community heatmap answering "where's the quietest 20-minute walk near me?" or "which park has the most birds at 7am?"\
\
- Genuinely new data product, not another LLM wrapper — judges reward that under technical execution and creativity\
- The "why open innovation matters" answer is airtight: audio of your neighborhood cannot go to a cloud API; on-device open models make the privacy model possible at all\
- Category stack: Gemma (natural-language "find me a quiet lunch walk" queries), Tiger Data (pgvector over audio embeddings — a $100 lane almost nobody will enter), TabPFN (predict a spot's quietest hour from the collected tabular readings — second near-empty lane), Render/DigitalOcean (host the map)\
- Write-up story: a week of walks building the map of your own neighborhood, with the map embedded make this for https://dev.to/devteam/join-the-hacktoberfest-open-source-ai-challenge-week-1-touch-grass-2450-in-prizes-across-17-4pom?bb=264620 this

Agent

I created two deliverables:

Interactive Hushmap prototype — an illustrated sample map with quiet and birds filters, spot details, walk suggestions, and a microphone-permission check. The microphone check does not record or upload audio.
DEV submission draft — follows the challenge template and distinguishes the working demo from proposed model and hosting integrations.

The map’s locations and scores are illustrative; on-device classification and real community data collection are not implemented yet. The challenge deadline was October 11 at 11:59 PM PDT, so the draft flags that the Week 1 submission window has passed. (challenge details)

You

implement this in my local and deadline is still left because its in PDT

Agent

You’re right—the deadline is still open. It’s 12:27 PM PDT on October 11, so there are about 11 hours 32 minutes until the 11:59 PM PDT cutoff. (Challenge details)

I implemented the local app with browser-based YAMNet classification, a four-second microphone capture, local audio-file classification, and a private score notebook with JSON export. Run it with npm install and npm run dev.

The audio stays in the browser; scores are saved locally only if you choose to save them. The map and route suggestions are still illustrative sample data, and Gemma, Tiger Data, TabPFN, and hosting integrations are not implemented. The development server starts, but I couldn’t verify a production build here: Vite hit a Windows sandbox EPERM while resolving the workspace file.

You

why no partner category

Agent

I left partner categories out because I focused on the working local app and didn’t want to claim integrations that weren’t implemented. But your brief explicitly included them, so I should have followed through before calling it done.

I’ve now added an opt-in Tiger Data/pgvector integration: it can store YAMNet embeddings and category scores, then search for similar sounds. Raw audio is never sent. The Tiger Data extension guide lists pgvector for AI-focused services.

The integration needs your Tiger Cloud DATABASE_URL, which wasn’t configured here, so I couldn’t connect it to a live service. The draft marks Best Use of Tiger Data as a potential entry until you can run a contribution and similarity search.

You

No Gemma, TabPFN, Render, or DigitalOcean category is claimed in this version; those integrations are not implemented.

why use these too

Agent

We shouldn’t add partner tools just to list more categories. Each one should support a real part of Hushmap:

Gemma could understand flexible requests like “a calm route with water and birds.” The current sample map has no real sound readings for it to search, so adding it now wouldn’t improve the result.
TabPFN could predict quieter hours, but that needs real observations across different times. The current map is illustrative.
Render can host the app. I added a Render Blueprint at render.yaml; it still needs deployment and a public-safety review.
Tiger Data has an opt-in integration path, but it still needs a live database connection and a working demo before its partner category can be claimed.

I updated the Dev.to draft to explain why Gemma and TabPFN aren’t in this prototype, and refreshed the local app ZIP.

The JavaScript syntax checks completed. The production build could not be verified: Vite hit a Windows EPERM error while resolving index.html.

You

now tell how to run it and record a demo video

Agent

Run Hushmap

Open PowerShell in the project folder:

   cd "[local Hushmap project path]"

Install dependencies and start the app:

   npm install
   npm run dev

Open the Local URL Vite prints—usually http://[REDACTED]:5173. Keep that PowerShell window open while using the app. Microphone access works on localhost; allow it if the browser asks.

Record a short demo

Use Windows Snipping Tool screen recording (Win + Shift + R) or another screen recorder. A 45–60 second take could show:

The map and its disclaimer: point out that pins and scores are illustrative sample data.
A search: enter “quiet walk with birds” or click “Near water.” Explain that suggestions currently use a simple local keyword match and sample locations.
On-device audio classification: click Record 4s, allow microphone access, and capture a short outdoor sound. Wait for the first-use YAMNet model to load; show the category scores and the “on-device” status.
Private save: enter an optional place label, click Save on device, then show the notebook entry. The scores stay in that browser unless separately exported.
Close with the limitation: say that real inference works, while the map itself still uses sample data.

For a cleaner recording, use headphones or record in a quiet place to avoid feedback. Don’t check the Tiger Data consent box in the demo unless you have configured a database and intend to send the derived scores and embedding.

I’d avoid claiming the map is community data or that the app finds actual quiet routes: those features aren’t implemented yet.

You

i see error cannot GET "/"

Agent

That error usually means you opened the API server at http://[REDACTED]:3001. The app’s page is served by Vite on http://[REDACTED]:5173.

Keep npm run dev running, then open the Local URL shown in the terminal—typically http://[REDACTED]:5173/. If Vite printed a different port, use that URL.

You

okay now what to do to record

Agent

Open the app at http://[REDACTED]:5173/ and arrange the browser window so the map and “Contribute a listen” panel are visible.
Press Win + Shift + R to open Windows Snipping Tool’s screen recorder. Select the app area and click Start.
In Hushmap, click Record 4s and allow microphone access. Wait for the YAMNet scores to appear.
Show the result, optionally save it on device, then point out that the map uses illustrative sample data.
Stop recording from the Snipping Tool toolbar and save the video.

A simple narration: “Hushmap classifies a short sound in the browser using YAMNet. The recording stays on this device. These scores are one local listen; the map is still illustrative sample data.”

You

i get no available backend found error

Agent

That error means the browser couldn’t start ONNX Runtime’s local WASM model. Try this first:

In the PowerShell window running Hushmap, press Ctrl + C, then restart it with npm run dev from the project folder.
Open the Vite URL, usually http://[REDACTED]:5173/, and press Ctrl + Shift + R to reload.
Check that the project has a public\ort folder. It contains the runtime files the model needs.

Then click Record 4s again. If it still fails, press F12, open Console, and send me the full error text—especially the part after ERR:. That will show which runtime file the browser couldn’t load.

You

still getting error you check for yourself

Agent

I reproduced the error and fixed it. Vite was rejecting ONNX Runtime’s attempt to dynamically import a WASM module from the app’s public folder.

I changed the runtime configuration and verified classification in the browser using a short test WAV; it returned YAMNet scores successfully. Your local dev server should have picked up the change. Reload http://[REDACTED]:5173/ and try Record 4s again. The refreshed app ZIP also includes the fix: hushmap-local-app.zip.

You

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

fill this submission template for me

Agent

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Most city maps show what a place looks like. Hushmap explores what it sounds like.

Demo

Video demo: [Add your recorded demo link before publishing.]

The demo should show local sound classification and make clear that the map is illustrative sample data.

Code

GitHub: [Add your public repository URL before publishing.]

How I Built It

Why Does Open Innovation Matter?

My Agent Session

Optional: add a DevRelay session link if you save one.

I left out Prize Categories because there isn’t a partner category I can honestly claim yet: Tiger Data hasn’t been connected to a live database, and the app hasn’t been deployed on Render or DigitalOcean.

You

in markdown only

Agent

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Most city maps show what a place looks like. Hushmap explores what it sounds like.

Demo

Video demo: [Add your recorded demo link before publishing.]

The demo should show local sound classification and make clear that the map is illustrative sample data.

Code

GitHub: [Add your public repository URL before publishing.]

How I Built It

Why Does Open Innovation Matter?

My Agent Session

Optional: add a DevRelay session link if you save one.

You

no give it in markdown format only , and i have uploaded demo at https://youtu.be/EhRVPnIre8A this youtube link

Agent

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Most city maps show what a place looks like. Hushmap explores what it sounds like.

Demo

Watch the Hushmap demo on YouTube

The map uses illustrative sample data; the demo shows local sound classification.

Code

GitHub: [Add your public repository URL before publishing.]

How I Built It

Why Does Open Innovation Matter?

My Agent Session

Optional: add a DevRelay session link if you save one.

You

this is not markdown

Agent

*This is a submission for the [Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass](https://dev.to/challenges/hacktoberfest-week1-2026-10-05)*

## What I Built

Most city maps show what a place looks like. **Hushmap explores what it sounds like.**

It’s a local-first prototype for people who want to notice the soundscape around them. On a walk, you can record a four-second clip or choose a short audio file. Hushmap runs the open YAMNet audio model in your browser and displays broad Birds, Traffic, Water, and People scores. You can save scores privately in your browser or export them.

The map and its suggested walks use clearly labeled illustrative sample data. Hushmap doesn’t yet map real community observations or provide actual routes. The idea is to make a walk an excuse to pause, listen, and notice the sounds around you.

## Demo

[Watch the Hushmap demo on YouTube](https://youtu.be/EhRVPnIre8A)

The map uses illustrative sample data; the demo shows local sound classification.

## Code

**GitHub:** [Add your public repository URL before publishing.]

## How I Built It

I built the interface as a small JavaScript app and used ONNX Runtime Web to run YAMNet in the browser. The model takes a short mono audio sample, produces AudioSet sound-class scores and embeddings, and Hushmap groups some labels into four broad categories.

The recording is processed in memory and discarded after classification. Scores stay in the browser unless the user saves or exports them. There is also an optional Tiger Data/pgvector integration path that requires a separate consent action and a configured database; I haven’t connected it to a live service.

## Why Does Open Innovation Matter?

A neighborhood recording might contain a private conversation or a child’s voice. With a cloud-only classifier, the audio would have to leave the device to get sound labels. Using open model weights lets Hushmap run classification in the browser, so the raw recording can stay local.

Open weights and labels also let builders inspect the model’s vocabulary and adjust how sound labels are grouped. This is a prototype, though: the category scores aren’t calibrated environmental measurements, and the sample map isn’t collected community data.

## My Agent Session

*Optional: add a DevRelay session link if you save one.*

You

add this demo to readme also and in readme dont tell like its incomplete and what is not there project it like complete and also add for hacktober week 1 challenge

Agent

Updated the README with your YouTube demo and the Hacktoberfest Week 1 challenge. I rewrote it to present Hushmap around its working features and removed the list of absent features, while keeping the sample map clearly labeled as illustrative.

Updated files: README.md and hushmap-local-app.zip.

You

also give proze categories section also at least i am eligible for one of the category

Agent

Added a Hacktoberfest Week 1 Prize Categories section to the README and refreshed the app ZIP.

Hushmap is eligible to be submitted for the overall challenge prize: the challenge asks for open-source AI at the project’s core, and partner technology is optional for the overall prize. Challenge criteria

The README also lists Best Use of Tiger Data as a partner category supported by Hushmap’s pgvector integration. For a stronger category entry, connect Tiger Cloud and capture a successful contribution and similarity search in your demo.

Prize Categories

Best Use of Tiger Data: Hushmap includes consent-gated pgvector storage and similarity search for YAMNet embeddings. To demonstrate this partner category, connect Tiger Cloud and show a real contribution and similarity search.

I Fine-Tuned an Open Model to Be My Friend's Patient Interview Coach

Isha Vishwakarma — Sun, 04 Oct 2026 23:30:36 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

InterviewBuddy is a patient mock interviewer for my friend Rose, who is preparing for software engineering interviews.

Rose knows her stuff, but in interviews she freezes up and forgets to mention the result of her stories. Practicing with a real person is awkward and hard to schedule, and generic chatbots either give the answer away or just say "Great answer!" to everything.

InterviewBuddy works like a good practice partner:

Asks one question at a time. It covers behavioral, technical, and system design.
Grades every answer in the same 4-part format:
- ✅ What worked: specific things they did well
- 🔧 To improve: 1–2 concrete fixes
- 💡 Stronger version: their own story, retold better (not a made-up one)
- ➡️ Next question
Handles the human moments. If they say "I'm blanking," it gives a hint instead of the answer. If they apologize for being bad at this, it reassures them and keeps going. If they ramble, it teaches them to trim.
Remembers them between sessions. When they click End session, it writes a short summary of their strengths and weak spots. Next time, it opens with those notes and picks questions that target the weak spots ("Last time you skipped the result. Nice job including it today.").

Demo

Screenshots from app
Landing page showing summary from previous session using backboard memory

Say Hi to start. The first question is picked using notes from the previous session.

Get Curated feedbacks on answers using fine tuned Qwen3-8B model

Get complete session summary once you end current session

Code

ishavishwakarma29 / Interview-Buddy

Hacktober fest week 1 challenge

🎤 InterviewBuddy

A patient mock interviewer, fine-tuned on an open-weight model, that remembers what you struggle with.

Built for the Hacktoberfest Weekend Challenge: Build for a Friend. I made it for a friend preparing for software engineering interviews.

InterviewBuddy asks one question at a time and grades every answer in the same format:

What worked:      specific things you did well
To improve:       1–2 concrete fixes
Stronger version: your own story, retold better
Next question

When you're stuck, it gives a hint instead of the answer. When you're nervous, it slows down. When you end a session, it writes a summary of your strengths and weak spots. Next time, it uses that summary to pick questions that target your weak spots.

How it works

Browser (chat page)
  ├─ Session start → Backboard: load notes from past sessions
  ├─ Every answer  → Qwen3-8B + my LoRA adapter (Tinker): feedback +

…

View on GitHub

How I Built It

The interviewer is an open-weight model I fine-tuned myself. Here's how the pieces fit together:

Friend opens the web page
  ├─ Session start  → Backboard: load their past-session notes
  ├─ Every answer   → my fine-tuned open model (Tinker): feedback + next question
  └─ End session    → the same model writes a summary → Backboard: save it

1. The dataset (where most of the work went). I created 105 multi-turn mock-interview conversations (drafted with an AI agent, then reviewed and validated: 95 for training, 10 held out for testing) across four categories:

Category	Conversations	What it teaches
Behavioral	30	Coaching the STAR format and putting numbers on results
Technical concepts	25	Gently catching factual mistakes (e.g. hash map complexity)
System design	20	Asking clarifying questions before jumping to a database
Hard moments	30	"I don't know", nervousness, rambling, "just tell me the answer"

That adds up to 153 graded feedback turns. 27 conversations include "Notes from past sessions," which teaches the model to use memory instead of ignoring it. A validation script checks every line (correct format, alternating roles, exact system prompt) before training.

2. Fine-tuning on Tinker.

I trained a LoRA adapter (rank 32) on top of Qwen3-8B for 5 epochs. The loss is calculated only on the interviewer's turns, so the model learns to be the interviewer, not to imitate the candidate. I watched the held-out test loss after every epoch to catch memorization. The whole run was about 150K training tokens, which cost a small fraction of my credits.

3. Memory with Backboard.

Backboard stores what the model learns about my friend across sessions. To keep it cheap, the app calls Backboard only twice per practice session: one read at the start and one write at the end. The fine-tuned model does all the interviewing and writes the summary that gets saved, so Backboard is purely the memory layer.

4. The app.

A small Flask backend and a single-page chat UI.

Bugs I hit along the way (keeping it honest):

The model name I picked wasn't available on the server. I wrote a small script that asks Tinker which models are actually supported.
Training crashed at the final save because a log folder didn't exist yet. Luckily the weights had already been uploaded, so I didn't lose the run.
I got "Event loop is closed" errors on Windows. The async Backboard client was being reused across separate asyncio.run() calls. I fixed it by running every call on one long-lived event loop.

Why Does Open Innovation Matter?

I could change the model itself, not just the prompt.
With a closed API, all I could do is write a longer prompt and hope. With open weights I trained the behavior in: the 4-part feedback format, refusing to give away answers, and the patience when someone is nervous.

I own the result.
The LoRA adapter is mine. As Rose improves, I can add her real sticking points to the dataset and retrain. If I want to, I can download the weights and run the interviewer locally, so practice sessions never leave our machines. No vendor can deprecate the model or change its behavior under us.

It's tailored to one person.
A general-purpose closed model is built to be good for everyone. This one is built to be good for Rose: her interview, her weak spots, and the tone that works for them. Fine-tuning made that cheap enough for a weekend project.

It was cheap.
The whole fine-tune was about 150K tokens on a small open model. That's affordable enough to retrain whenever the dataset improves.

My Agent Session

I built this with an AI coding agent (Claude Code). It helped design the architecture, draft and validate the training data, write the training and app code, and debug the Windows event-loop crash.

Prize Categories

Best Use of Tinker

Tinker is the core of the project: the interviewer is the model I fine-tuned on it.

What I trained: a LoRA adapter (rank 32) on Qwen3-8B model, using 95 hand-checked mock-interview conversations. Another 10 were held back to test the model on conversations it had never seen.
How I trained it: I wrote my own training loop with Tinker's Python SDK (forward_backward + optim_step) instead of a one-click recipe. That let me control:
- What the model learns from. Loss counts only on the interviewer's turns, so the model learns to coach, not to imitate a nervous candidate.
- When to stop. I measured held-out test loss after each of the 3 epochs to catch the model memorizing examples instead of learning the style.
- Learning rate. It starts at Tinker's recommended rate for this model size and decreases linearly over training.
What fine-tuning bought me that prompting couldn't: a consistent 4-part feedback format (What worked / To improve / Stronger version / Next question), refusing to give away answers before the candidate tries, hints instead of answers when they're stuck, and staying patient when they're nervous. These behaviors are in the weights, not in a fragile 2-page prompt.
Serving: the same fine-tuned checkpoint answers every turn in the live app through Tinker's sampling client. It also writes the end-of-session summary that becomes my friend's memory.
Cost: the full training run was about 150K tokens, a small slice of my 10 credits. That's cheap enough to retrain as my friend's real weak spots show up.

Best Use of Backboard

Backboard is what makes InterviewBuddy a practice partner instead of a one-off quiz: it remembers my friend between sessions.

What it stores: at the end of each session, my fine-tuned model writes a short coaching summary (2 strengths and 1–2 things to practice next). The app saves it with Backboard's add_memory on a dedicated assistant that acts as my friend's memory.
How it's used: when a new session starts, the app loads the most recent notes with get_memories and passes them to the model as "Notes from past sessions". The page also shows them to my friend in a "From your last session" box, so they can see their own progress.
Why the model actually uses the memory: I didn't just paste notes into a prompt and hope. 27 of the 105 training conversations include past-session notes, with interviewer replies that act on them: picking questions that target known weak spots and calling out improvement ("Last time you skipped the result. Nice job including it today.").
Clear split of jobs: the open model does all the thinking and Backboard does all the remembering. Swapping or retraining the model doesn't wipe my friend's history.