DEV Community: gulnur

GitHub Issues Explained: When Should You Open One in Open Source?

gulnur — Tue, 13 Oct 2026 07:40:14 +0000

When you first start exploring open-source projects on GitHub, you might notice something: almost every active repository has an Issues tab.

But what is it actually for? Should you open an issue whenever you find a bug? What if you have an idea for a new feature? And if you already know how to fix something, should you open an issue first or go straight to a pull request?

I used to think that GitHub Issues were solely for project owners to track their own tasks 🫣, but I learned that anyone can open an issue to report a bug, suggest a feature etc..

Let's break it down.

What is a GitHub Issue?

A GitHub Issue is a place to report problems, suggest improvements, ask questions about a project, or discuss work that needs to be done.

Think of it as a shared record of something that needs attention. Instead of keeping ideas in your head or discussing problems in scattered messages, you create a place where contributors and maintainers can understand the context and discuss possible solutions.

I think issues are useful for more than bug reports. They can also help maintainers organize work, collect feedback, prioritize features, and coordinate contributions.

When should you open an issue?

There are a few common situations where opening an issue makes sense.

1. You found a bug 🐛

Suppose you are using an open-source application and notice that a button stops working after a particular action.

Before reporting it, try to reproduce the problem and check whether it has already been reported.

A useful bug report should explain:

What you were trying to do.
The steps needed to reproduce the problem.
What you expected to happen.
What actually happened.
Any relevant error messages or screenshots.

For example, instead of writing:

"This button is broken."

You could write:

Title: Analyze button remains disabled after recording stops

Description:

Steps to reproduce:

Start recording audio.
Stop the recording.
Observe the Analyze button.

Expected behavior: The Analyze button becomes available once recording has finished.

Actual behavior: The button remains disabled, preventing the user from analyzing the recorded audio.

This gives maintainers something concrete to investigate.

2. You have an idea for a new feature

You don't need to find a bug to open an issue. Maybe you are using a library and think it would be useful if it supported a new configuration option. Or perhaps you are contributing to a project and see an opportunity to improve the user experience.

An issue lets you explain the idea before anyone spends time implementing it.

For example:

Title: Add a sound discovery card to display classification results

Description:

It would be useful to display each sound classification result in a dedicated discovery card.

The card could show the predicted sound label, confidence score, and a short explanation of the result.

This could make the classification output easier to understand and give users a more engaging way to explore their recordings.

Would this feature fit the project's current direction?

Notice that this is a proposal, not a demand. The maintainers may suggest a different approach, ask for more details, or decide that the feature doesn't fit the project's goals. That's part of open-source collaboration.

3. The documentation needs improvement

Sometimes the code works perfectly, but the documentation doesn't.

You might find an outdated installation command, a broken link, a missing explanation, or an example that no longer works.

These are valid things to report, too.

For small, obvious documentation fixes, you may be able to submit a pull request directly. For larger changes or unclear expectations, opening an issue first can help you understand what the maintainers want.

4. You want to discuss an approach before writing code

Imagine that you want to add a feature, but there are several possible implementations.

Should you introduce a new dependency? Should the feature be handled by an existing module? Would the change make the project harder to maintain?

This is a good time to discuss the idea before implementing it, especially if the change is substantial.

A short conversation with maintainers can prevent you from spending hours building something that doesn't fit the project's architecture or priorities.

Issue vs. Pull Request vs. Discussion

These three GitHub features are related, but they serve different purposes.

Issue: Describes a problem, task, or proposal that needs attention.

Pull Request (PR): Proposes code or other repository changes for review and merging.

Discussion: Provides a space for open-ended questions, ideas, and community conversations when the project has GitHub Discussions enabled.

A simple way to remember the difference:

I found a problem → consider opening an issue.
I have an idea that needs feedback → consider an issue or discussion, depending on the project's conventions.
I have a proposed change ready for review → open a pull request.

These aren't strict rules for every project. Some projects prefer discussions for feature proposals, while others use issues for almost everything. Always check the repository's guidelines.

Should you always open an issue before making a change?

No.

If you find a typo or a broken link and the fix is obvious, you may be able to submit a small pull request directly. However, for a significant feature, architectural change, or improvement that could affect the project's direction, discussing it first is often a better approach.

Before opening an issue or starting work, take a few minutes to:

Read the README and look for a CONTRIBUTING.md file.
Search existing issues, including closed ones.
Check whether the project uses issue templates or specific labels.
Look at the project's contribution guidelines.
Explain your idea clearly and ask for feedback when needed.

sample c. guideline

This helps prevent duplicate reports and unnecessary work.

What makes a good issue?

A good issue makes it easy for someone else to understand what needs attention.

Here are a few principles I try to keep in mind:

Be specific. Describe one problem or proposal clearly rather than combining several unrelated topics.

Provide context. Explain why the issue matters and what you were trying to achieve.

Show what you tried. For bugs, include reproduction steps and relevant errors. For feature requests, explain the use case.

Keep it concise. Include the information needed to understand the issue without adding unrelated details.

Be open to feedback. An issue starts a conversation. It doesn't guarantee that a feature will be implemented exactly as proposed.

Also, avoid opening duplicate issues. If someone has already reported the same problem, adding useful information to the existing conversation is usually more helpful.

What happens after you open an issue?

Opening an issue is the beginning, not the end.

A maintainer might ask for more information, label it, assign it to a milestone, invite contributors to work on it, or close it if it is a duplicate or falls outside the project's scope.

Sometimes an issue leads to a pull request. Sometimes the discussion reveals that the proposed feature isn't needed. And sometimes the issue simply documents a problem for future reference.

If you solve the problem yourself after opening the issue, share the solution and update or close the issue when appropriate.Not every issue needs to become code to be useful.

One thing that confused me at first was why some issues remain visible even after the problem has been fixed. I learned that fixing a problem doesn't automatically remove its issue from GitHub. The issue usually needs to be closed by someone with the appropriate permissions, often after the related pull request is merged or the fix is verified. Closed issues remain in the repository's history, so people can still refer to them later.

A small but important part of open source

A well-written issue can save maintainers time, help another contributor find their first task, and turn a vague idea into a concrete improvement.

So the next time you notice something that could be better in an open-source project, don't immediately jump into the code.

Take a moment to understand the problem, check whether it has already been discussed, and decide whether an issue is the right next step.

Resources

EchoQuest: Touch Grass, Listen Closer, Discover More 🌱

gulnur — Sun, 11 Oct 2026 19:26:00 +0000

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

What I Built

EchoQuest is an AI-powered nature sound discovery app designed to encourage people to step outside, listen more carefully, and reconnect with the natural world.

We spend so much time looking at screens that we sometimes forget to pay attention to what's happening around us.I wanted to explore how AI could make outdoor exploration more engaging instead of giving people another reason to stay online.

The idea is simple: go outside, listen to the world, and turn what you hear into a discovery.

With EchoQuest, users can record sounds around them and analyze them using an AI audio classification model. The app displays the model's predictions alongside nature-focused insights, turning an ordinary walk into a small exploration mission.

To make the experience more engaging, I added a few lightweight gamification features:

🌱 Sound Discovery: Record an outdoor sound and explore the model's predictions.

✨ XP Points: Earn points for supported nature discoveries.

📖 Nature Journal: Review previous discoveries and track your progress.

🏅 Achievement Badges: Unlock milestones as you continue exploring.

EchoQuest is built for curious people, students, nature lovers, and anyone who could use a little motivation to take a break from their screen.

The goal is simple: step outside, listen closer, and explore. 🌿

See EchoQuest in Action

1.Sound Prediction

Start by recording a sound from your surroundings. EchoQuest processes the recording and displays the model's predictions.

Once the analysis is complete, users can explore the results and see whether the sound offers an interesting nature discovery.

2. Nature Journal and Badges

Discoveries can become part of an ongoing journey. The journal keeps track of previous results, while XP points and achievement badges add a sense of progress.

Visit the Demo & Try It Yourself

Demo

🔗 Live demo:

echoquest-qk1i.onrender.com

🎥 Video demo:

canva.com

Code

💻 GitHub repository:

Gulnur-Altan / echoquest

🌿 An AI-powered nature sound discovery app that turns outdoor walks into quests with audio classification

🌿 EchoQuest — Touch Grass, One Sound at a Time

Turn your next walk into an AI-powered nature discovery quest.

🎙️ Audio Classification · 🌱 Nature Discovery · ✨ Gamification

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

🌎 About

EchoQuest is an AI-powered web application that encourages people to step away from their screens and reconnect with nature through sound.

Record the sounds around you, explore AI-generated audio predictions, collect discovery points, unlock achievement badges, and build your own nature journal.

The idea is simple: use AI to inspire people to experience the real world, not spend more time staring at a screen.

✨ Features

🎙️ Record Nature Sounds — Capture environmental audio directly in your browser.
🤖 AI Audio Classification — Analyze recordings with a pretrained audio classification model.
🍃 Nature Insights — Explore nature-focused information based on recognized sound categories.
⭐ Experience Points (XP)…

View on GitHub

The project source code is available on GitHub. Contributions, suggestions, and bug reports are welcome!

How I Built It

EchoQuest is built with Next.js, React, TypeScript, and Transformers.js.

For audio classification, I use the pretrained Xenova/ast-finetuned-audioset-10-10-0.4593 model. The application records audio through the browser, preprocesses the recording for inference, and displays the model's top predictions. Rather than sending recordings to a paid, hosted inference API, EchoQuest runs the classification pipeline in the user's browser.

The main technical components include:

Audio recording: The browser's MediaRecorder API captures audio.
Audio preprocessing: The recording is decoded and resampled to the model's expected 16 kHz sample rate.
AI inference: Transformers.js runs the pretrained audio classification model.
Nature-focused interpretation: The app uses model predictions to provide relevant exploratory insights.
Progress tracking: Browser local storage persists the nature journal.
Gamification: XP points and achievement badges encourage continued exploration.

One important design decision was to keep the core inference process in the browser rather than depend on a paid, hosted AI inference API. This reduces reliance on external inference services and keeps the audio processing on the client side.

Note: The model is a general audio-event classifier, not a dedicated wildlife species identification system. Its predictions are exploratory hints, not definitive scientific identifications.

Why Does Open Innovation Matter?

Open innovation was important to this project because it made experimentation with AI more accessible.

By using a pretrained model and the JavaScript machine learning ecosystem, I could focus on integrating audio classification into a web application and designing an experience around it, without having to train a model from scratch or depend on a proprietary inference API.

I also wanted to explore how open tools can help developers turn an idea into something people can actually use.

EchoQuest could grow through contributions from other developers. Possible areas for improvement include sound classification evaluation, accessibility, testing, nature-focused insights, and the overall discovery experience.

For me, the interesting part is not just getting an AI model to produce a prediction. It's exploring how that prediction can become part of a useful, engaging experience.

For a project about reconnecting people with nature, I like the idea that the technology behind it can also be explored, inspected, and improved by a community.

What I Learned and What's Next

For me, the most challenging part of EchoQuest wasn't integrating the AI model or writing the code. It was turning the model's predictions into a meaningful game experience. Designing the XP system, badges, and Nature Journal meant finding ways to reward real nature discoveries without treating every AI prediction as a valid discovery.

Ironically, the biggest challenge was actually getting outside and listening to different sounds! 😃

I learned that building an AI-powered app isn't just about making a model work; it's also about creating an engaging experience that encourages people to spend more time outdoors and notice the world around them.

Next, I'd like to make discoveries more meaningful and improve the reward system.. 🌿

DocTrace: Investigating Angular Migrations with Sanity Context MCP

gulnur — Sun, 04 Oct 2026 20:23:42 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

I have worked with production systems where version upgrades need to be planned carefully. In a live environment, an update is not just about running a command. As developers, we need to understand breaking changes, compatibility concerns, configuration updates, and potential impact before making the change.

I have often found myself going back to documentation or looking for additional guidance before making these decisions. Relevant information can be spread across multiple documentation pages, making the investigation process time-consuming.

That experience inspired me to build DocTrace.

I wanted to explore whether an AI agent could make this process more focused: instead of asking a general-purpose chatbot about a migration, give it a structured, curated documentation source and let it investigate the relevant information before answering.

DocTrace is an AI documentation investigation agent focused on Angular 20 → Angular 21 migration.

For this challenge, I intentionally kept the initial Knowledge Base focused on Angular 20 → 21. The same architecture can be extended to future Angular versions by adding the relevant documentation to Sanity and updating the Knowledge Base.

Migration questions often require checking several pieces of documentation: breaking changes, configuration changes, testing updates, and version-specific behavior. DocTrace turns this into a focused investigation workflow.

The documentation is stored as structured content in Sanity, organized into a Knowledge Base, and exposed to the agent through Sanity Context MCP.

A user can ask a question such as:

What are the main breaking changes I should consider when migrating from Angular 20 to Angular 21?

DocTrace retrieves relevant documentation from the connected Sanity Knowledge Base ..

..and uses that context to generate the investigation result

The agent is intentionally scoped to Angular 20 → 21 migration rather than being a general-purpose chatbot. This makes it possible to curate a small but meaningful documentation set and evaluate how an agent works with structured content.

Demo

doctrace-nine.vercel.app

The deployed application provides a simple interface where users can ask Angular migration questions and receive an investigation based on the connected Sanity documentation.

Code

Gulnur-Altan / doctrace

DocTrace

AI documentation investigation agent for Angular 20 → Angular 21 migration.

DocTrace helps developers investigate Angular migration questions by querying structured technical documentation stored in Sanity.

Instead of relying only on the language model's general knowledge, DocTrace retrieves relevant documentation from a Sanity Knowledge Base through Sanity Context MCP and uses that context to formulate its answer.

Demo

Live Demo: https://doctrace-nine.vercel.app/

What I Built

DocTrace is a focused documentation investigation agent for one specific technical problem:

What should I know when migrating an Angular 20 application to Angular 21?

The agent can investigate topics such as:

Breaking changes
Migration steps
Zoneless change detection
Testing configuration
Compatibility considerations
Angular 20 → 21 migration checklists

The project intentionally keeps the scope narrow so that the agent can provide grounded answers from a curated documentation set.

Architecture

                    ┌─────────────────────┐
                    │      DocTrace UI     │
                    │      Next.js         │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │   Next.js API

…

View on GitHub

How I Used Sanity

Sanity is the documentation source and structured content layer behind the agent.

I created a custom documentation schema with fields including:

title
technology
version
type
summary
content
sourceUrl
publishedAt
relatedVersions
breakingChanges

I then created structured documentation entries focused on Angular 20 → Angular 21:

Angular 21 Migration Guide
Angular 20 to 21 Migration Guide
Angular 21 Zoneless Change Detection
Angular 21 Testing with Vitest
Angular 20 vs Angular 21 Migration Checklist

These documents were added to a Sanity Knowledge Base.

Then i created a Sanity Context MCP endpoint connected to that Knowledge Base.

The agent connects to the MCP endpoint from the server side and uses the available Context tools to investigate the documentation before generating its response.

The agent is instructed to:

Use the Sanity Knowledge Base for Angular migration questions.
Prefer retrieved Sanity content over unsupported general knowledge.
Use multiple investigation steps when necessary.
Avoid inventing information that is not supported by the available documentation.
State when the available documentation is insufficient.

The resulting architecture is:

---
config:
  theme: base
  themeVariables:
    fontFamily: '"Public Sans", system-ui, sans-serif'
    fontSize: 20px

    cScale0: "#f3d6d8"
    cScaleLabel0: "#69444a"
    cScaleInv0: "#c98f97"

    cScale1: "#f3dfc1"
    cScaleLabel1: "#715b38"
    cScaleInv1: "#d0a866"

    cScale2: "#d8e5d2"
    cScaleLabel2: "#4c6047"
    cScaleInv2: "#9bb78f"
---

flowchart LR

    A["💬 User Question"]
        --> B["🖥️ DocTrace UI<br/>Next.js"]

    B --> C["⚙️ API Route<br/>AI SDK"]

    C --> D["🤖 Gemini<br/>AI Agent"]

    D --> E["🔌 Sanity Context<br/>MCP"]

    E --> F["📚 Sanity<br/>Knowledge Base"]

    F --> G["📄 Structured<br/>Angular Documentation"]

    D --> H["✅ Investigation<br/>Result"]

    classDef user fill:#f3d6d8,stroke:#c98f97,color:#69444a,stroke-width:2px
    classDef app fill:#f3dfc1,stroke:#d0a866,color:#715b38,stroke-width:2px
    classDef sanity fill:#d8e5d2,stroke:#9bb78f,color:#4c6047,stroke-width:2px

    class A,H user
    class B,C,D app
    class E,F,G sanity

This allowed me to use Sanity as an actual knowledge source for the agent rather than simply using Sanity as a database for the frontend.

Sanity Project Details

Sanity -> https://www.sanity.io/
Sanity Project ID: 3fv91nvs

The project contains the structured Angular documentation used by the DocTrace Knowledge Base.

Should You Add Projects to Your CV?

gulnur — Fri, 25 Sep 2026 07:28:09 +0000

cover image is from->Image by tirachardz on Magnific

1. The Problem

I was reviewing for software engineering roles, and at some point I noticed something uncomfortable: my CV had almost no personal projects.

I had professional experience, but there wasn't much I could point to and say, "I built this."

That made me think about whether adding personal projects to a CV is actually important.I also think projects can help fill some gaps in your resume, especially because recruiters often spend only a short amount of time reviewing a resume.

2. Why Work Experience Isn't Always Enough

Professional experience shows that you can work in a team, contribute to a real product, and work with production systems.

But a personal project can show something different: how you approach a problem and build something independently.

There is also another problem. Most developers work with private repos at their jobs. Their contributions, architecture decisions, and day-to-day work aren't publicly visible.

So even if you have several years of professional experience, a recruiter looking at your GitHub might not see much.

A personal project gives them something concrete to look at:

GitHub repository → How do you write and organize code?
README → Can you explain what you built?
Live demo → Can you take an idea and turn it into something usable?
Tests / Git history → How did you develop and maintain it?

Of course, a project doesn't replace professional experience. But it can give recruiters and hiring managers another way to understand your technical skills.

3. What Makes a Project Worth Adding to a CV?

I don't think every project belongs on a CV.

For example:

Tutorial clone ❌
Calculator/weather app with no additional value ❌
Abandoned repository ❌
A project copied entirely from an AI tool ❌

Instead, I'd look for a few things:

Solves a real problem ✅
Has a clear README ✅
Has a live demo, if possible ✅
Demonstrates relevant technologies ✅
Has meaningful Git history, issues, or tests ✅

I think the main purpose is to have something worth showing.

And that's where I found myself asking another question:

What should I actually build?

To be continued...

What If Every Act of Kindness Could Create Another One?

gulnur — Mon, 07 Sep 2026 09:24:43 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

In celebration of the UN International Day of Charity (September 5), I built OpenImpact — a transparent grassroots giving platform and generosity ledger designed to eliminate donor skepticism and celebrate the contagious nature of community kindness.

Traditional charity platforms often suffer from the "black-box" dilemma: donors contribute to nebulous general funds without ever knowing what their money bought, while small community initiatives lack the marketing muscle to tell their stories transparently.

OpenImpact solves this through four core pillars:

Concrete Unit Economics & Visual Impact Calculator: Instead of throwing money into an abstract pool, donors use an interactive slider with dynamic Recharts bar charts to see exactly how their contribution translates into tangible units (e.g., $18 = 1 Solar Desk Lantern replacing toxic kerosene smoke, $12 = 24 lbs of rescued fresh produce, or 2 hours = 1 youth coding mentorship kit).
AI-Powered Field Storyteller (Google Gemini): Small nonprofits often don't have PR teams. Changemakers simply upload raw field notes or receipt summaries, and Gemini transforms them into audit-ready, authentic field dispatches and ready-to-publish Dev.to Markdown posts.
The Generosity Ripple Engine: Generosity is contagious. OpenImpact maps out connected chains of giving, proving that every act of kindness inspires subsequent pledges (tracking real-time ripple multipliers).
Radical Transparency & Busters of the "Overhead Myth": The platform publishes itemized accounting, open receipts, and downloadable CSV audits, proving that ethical compensation for local workers creates sustainable impact.

Demo

🌐 Live Web Application: OpenImpact Live Demo
📊 Interactive Features to Try:
- Open any cause and click "Simulate & Pledge" to see the real-time Recharts bar chart calculator and trigger the confetti celebration.
- Navigate to "Field Storyteller" and click "Generate Dispatch with Gemini" to test raw field note conversion into transparent community dispatches.
- Visit the "Generosity Ripple" tab to see how acts of giving propagate across donors.
- Check the "Open Audit" tab to inspect itemized budget allocations and download the open CSV ledger.

Code

Gulnur-Altan / OpenImpact

A transparent grassroots giving and storytelling platform crafted specifically for the DEV.to International Day of Charity Challenge.

🌱 OpenImpact

What if every act of kindness could create another one?

OpenImpact is an open-source generosity platform focused on transparency, measurable impact, and the ripple effect of giving.

✨ Features

💰 Impact Calculator — See what a contribution can achieve through interactive charts.
🤖 AI Field Storyteller — Turn raw field notes into authentic impact stories with Google Gemini.
🌊 Generosity Ripple — Visualize how one act of generosity inspires another.
🔎 Open Audit — Explore itemized budgets and download the public CSV ledger.

🛠️ Tech Stack

React
Recharts
Google Gemini
JavaScript
CSS

🚀 Demo

OpenImpact Live Demo

Try Simulate & Pledge, Field Storyteller, Generosity Ripple, and Open Audit.

🤝 Contributing

Contributions are welcome! Fork the repository, create a feature branch, make your changes, and open a Pull Request.

📄 License

This project is licensed under the MIT License.

🏆 DEV Community Challenge

…

View on GitHub

How I Built It

Tech Stack:

Frontend: React 19, TypeScript, Tailwind CSS, Recharts (for dynamic unit yield charts), Lucide Icons, Canvas Confetti.
Backend: Node.js, Express, tsx, esbuild.
AI & Intelligence: Google Gemini 3.8 Flash via the @google/genai TypeScript SDK.

Technical Architecture & Decisions:

Server-Side API Proxy for Gemini Security: All interactions with Google Gemini run via secured Express routes (/api/generate-dispatch and /api/simulate-impact), ensuring API credentials are never exposed client-side.
Auditing Prompt Engineering: The Gemini prompt explicitly enforces ethical storytelling rules: rejecting corporate marketing buzzwords ("supercharge", "synergy"), emphasizing dignity and concrete metrics, and formatting verified receipts into structured JSON and clean Markdown.
Resilient AI Fallback Engine: Built an intelligent local synthesizer fallback so that if external rate limits or transient spikes occur, the user experience never breaks or crashes.
Accessible Visualization: Designed horizontal Recharts bars with custom tooltips displaying division formulas (e.g., $90 ÷ $18/unit = 5.0 lanterns) so every calculation is auditable.

Prize Categories

🏆 Best Use of Google AI

OpenImpact leverages Google Gemini 3.8 Flash via the official @google/genai SDK to solve real pain points in charitable giving:

Democratizing Non-Profit Communication: Grassroots leaders often have field evidence but lack copywriters. Gemini ingests unpolished bullet points and receipts, extracting verified outcomes, human quotes, and itemized ledger tables without corporate fluff.
Contextual Impact Simulation: When donors pledge volunteer hours or micro-funds, Gemini projects contextual community ripple effects on the fly.

Tomato soup for the Soul

gulnur — Sat, 15 Aug 2026 17:54:09 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

Inspired by the warmth of a classic bowl of tomato soup, I wanted to create a small piece of comfort using nothing but CSS.

Demo

Journey

I created the bowl, soup, cream swirl, basil leaves, steam, shadows, and table texture entirely with CSS. I experimented with gradients, border-radius, pseudo-elements, shadows, and simple animations to make the soup feel warm and alive.

I especially enjoyed creating the steam and soup ripple effects without using images or SVGs. Next, I'd like to add more small details and interactions to make the scene feel even more like a cozy kitchen moment.

I Want to Become an Open Source Contributor, But I Don't Know Where to Start

gulnur — Wed, 15 Jul 2026 10:18:42 +0000

Cover image is from-> Image by magnific

I've always admired people who contribute to open source.

Every time I use a library, read its documentation, or find a solution on GitHub, I've realized that someone took the time to build it, improve it, and share it with the community.

The truth is, I honestly don't know where to begin. 🧐

It's not that I'm afraid of writing code. I've spent years building web applications, fixing bugs, and learning new technologies as a software engineer. But open source feels like a different world.

Questions keep coming to mind:

How do people choose their first project?
Is improving documentation enough for a first contribution?
How do you avoid breaking someone else's project?
What's the proper etiquette when opening an issue or a pull request?
How do I figure out what a project actually needs?

The more I think about it, the easier it becomes to postpone taking that first step. So instead of waiting until I have everything figured out, I've decided to make this one of my goals.

My Open Source 101 plan 📅

Find a project I actually use.
Read its documentation, issues, and commit history.
Look for beginner-friendly issues.
Submit my first pull request, even if it's just a documentation improvement.
Learn from the review process instead of trying to be perfect.

I know my first contribution won't be groundbreaking 😃, and that's okay. Every experienced open source contributor started with a first pull request, right?

If you've been contributing to open source for a while, I'd love to hear your advice.

What was the first project you contributed to, and what helped you get started?

And if you're in the same position as me, maybe this is the sign that we should both stop waiting and start contributing..

Note: My goal is to submit my first open source pull request before the end of this month. I'll come back and share what I learned whether it succeeds or fails.

Why My Angular 21 Upgrade Failed 👀

gulnur — Thu, 09 Jul 2026 09:48:39 +0000

I believe Angular upgrades have become much smoother these days. Most of the time, a simple ng updateis enough to move to the latest version.

Instead, I spent hours chasing errors that looked completely unrelated to the real problem 😭

After upgrading the project to Angular 21, I started seeing errors like these:

Cannot find module '@angular/material/chips'
Cannot find module '@angular/material/dialog'

Then another one appeared:

Error: The current version of "@angular/build" supports Angular ^19...
but detected Angular version 21.x instead.

At first, it looked like Angular Material wasn't installed correctly but i think the actual issue was a version mismatch inside the project.

Some packages had already been upgraded to Angular 21:

@angular/core
@angular/common
@angular/material

But the build system was still using:

@angular-devkit/build-angular@19

Since Angular's build tools are tightly coupled with the framework version, the compiler started producing misleading errors.

The build pipeline was the problem.

The Commands That Helped

I used these commands:

npm ls @angular-devkit/build-angular

npm explain @angular-devkit/build-angular

They showed that my project was still resolving Angular 19's build package. That was the clue I needed and than I verified that every Angular package was using the same major version.

Then I cleaned the project completely:

rm -rf node_modules
rm package-lock.json
npm cache clean --force
npm install

It takes time usually.(and I did it several times cause Im failed 😃)

Finally, I confirmed that all Angular packages were aligned before building again.

the Last Sunset

gulnur — Sun, 21 Jun 2026 09:03:11 +0000

This is a submission for the June Solstice Game Jam

What I Built

The Last Sunset is a browser-based narrative survival game inspired by the June Solstice theme.

The concept explores a world where time itself is collapsing. Each day becomes shorter than the last, and the sun is gradually fading from existence. The player controls an autonomous AI archival unit tasked with preserving fragments of human civilization before the final sunset.

Instead of traditional combat or scoring systems, the game focuses on knowledge preservation. Players collect “data capsules” containing remnants of human history such as scientific discoveries, space exploration missions, and digital archives.

As the game progresses, the environment becomes increasingly unstable, reflecting the collapse of both time and memory.

Video Demo

canva.com

Codepen:

Code

The project is built using:

Vanilla JavaScript (no frameworks)
HTML5 Canvas API for rendering
Custom game loop with time scaling
Procedural particle system for feedback effects
Dynamic day/night cycle with a shrinking sun mechanic

🔗 GitHub Repository:

Gulnur-Altan / theLastSunset

A narrative survival game built for the June Solstice Game Jam

🌅 The Last Sunset

A small narrative browser game inspired by the June Solstice.

In a world where the sun is slowly fading away, you play as an AI archive unit collecting fragments of human knowledge before the final sunset.

🎮 Features

Dynamic day cycle
Shrinking sun mechanic
Knowledge capsule collection
Collapse Mode after Day 7
Multiple endings based on progress
Built with HTML5 Canvas and Vanilla JavaScript

🕹 Controls

Action	Key
Move Left	A
Move Right	D
Jump	Space

🚀 Run Locally

git clone https://github.com/yourusername/the-last-sunset.git
cd the-last-sunset

Start a local server:

python -m http.server

Then open:

http://localhost:8000

🛠 Tech Stack

HTML5
CSS3
JavaScript
Canvas API

🏆 Challenge

Created for the June Solstice Game Jam.

Preserve humanity's knowledge before the last sunset.

View on GitHub

Key systems include:

Collision detection (AABB)
Particle burst system for interactions
Screen shake and slow-motion effects
Narrative memory synthesis system
Collapse mode visual degradation system

How I Built It

I started with a simple canvas-based platformer and gradually evolved it into a narrative-driven experience.

The core design decision was to avoid traditional “win/lose” mechanics and instead focus on emergent storytelling through systems.

Key implementation steps:

Built a physics-based movement system (A/D + jump)
Added procedural spawning of “knowledge capsules”
Designed a dynamic time system where each day becomes shorter
Implemented a shrinking sun to visually represent entropy
Introduced a “collapse mode” after Day 7 where visual glitches and terminal corruption begin
Created a memory synthesis system that generates a final narrative based on collected data

To improve game feel, I added several “juice” effects:

Particle bursts on pickup
Camera shake on interaction
Slow-motion moment during collection
Terminal-style archival feedback

These small additions significantly improved immersion and emotional feedback.

Prize Category

🧠 Best Ode to Alan Turing

The game’s narrative structure is inspired by computational memory and symbolic reconstruction of information — concepts closely aligned with Alan Turing’s legacy.

The “memory synthesis system” at the end of the game reconstructs a final narrative from fragmented data, similar to how an intelligent system interprets incomplete information.

🤖 Best Google AI Usage

The concept of emergent storytelling and memory reconstruction was designed with AI-inspired thinking in mind.

The final system behaves like a simplified symbolic model that reconstructs meaning from partial inputs, similar to how modern AI systems generate coherent narratives from fragmented context.

What Happens When Companies Stop Hiring Juniors?

gulnur — Thu, 18 Jun 2026 07:35:04 +0000

cover image is from->https://wingassistant.com/blog/junior-developer-101/

Over the last few months, I've noticed a common trend in job postings: everyone seems to be looking for mid-level and senior engineers. On the surface, this makes sense. Experienced developers require less onboarding, can contribute faster, and often need less supervision.

But what happens when an industry collectively reduces junior hiring?

The first consequence may be that new graduates and career changers struggle to enter the field. Companies ask for experience, but gaining experience is difficult without a first opportunity. Also, I have many friends who have been searching for jobs for months despite actively improving their skills.

Today's seniors were once juniors. If fewer junior developers enter the industry now, the future talent pipeline becomes smaller. Eventually, companies may find themselves competing for the same limited pool of experienced engineers.

There is also a knowledge transfer problem. Strong engineering cultures are built when experienced developers mentor less experienced ones. If junior hiring continues to decline, opportunities for mentorship and long-term team development may decrease as well.

AI tools may change how entry-level work is performed, but they do not eliminate the need for new engineers. Every senior engineer started somewhere.

Perhaps companies should be asking, "How can we help junior developers become productive faster?"

Because an industry that stops investing in beginners may eventually run short of experts.

Related writings:

Why AI is Replacing Junior Developers and How Mid-Level...

AI tools like Claude Code are displacing junior developers by handling boilerplate and basic tasks, while simultaneously flooding codebases with unoptimized,...

daily.dev

Why You Should Hire a Junior Developer

Wondering whether a junior developer is the best fit for your software needs? What are a junior dev's responsibilities Read our article to help you decide!

wingassistant.com

Anthropic released new FREE AI courses

gulnur — Tue, 09 Jun 2026 13:57:01 +0000

Anthropic has released FREE courses on its Skills platform. You can now earn free certificates in Skills, MCP, Subagents, Claude Code, and other AI-related topics directly from Anthropic.

I've already enrolled and will be reviewing the courses over the next few days.

If you'd like to check them out:
https://anthropic.skilljar.com/

You can read:
https://app.daily.dev/posts/anthropic-just-released-new-free-ai-courses-vhinyl3gs

Image source:
https://media.daily.dev/image/upload/s--jdHyrLn2--/f_auto/v1780938861/posts/vHinyL3Gs?_a=BAMAMiWQ0

Giving a Forgotten Side Project a Second Chance

gulnur — Sun, 07 Jun 2026 10:30:21 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Deploy Friday ☄️

Deploy Friday is a small browser game inspired by the chaos of software development and Scrum teams. Players must survive a sprint by completing tasks, handling production incidents, and managing their stress level.

Built with:

HTML
CSS
Vanilla JavaScript

No frameworks or external dependencies. The game is powered by a few simple state variables:

let stress = 0;
let score = 0;
let sprintTime = 60;
let gameEnded = false;

Tasks are generated dynamically and random incidents keep the sprint unpredictable. If stress reaches 100%, the sprint fails.

Demo

gulnur-altan.github.io

The Comeback Story

This project started as a Scrum Quiz application with multiple-choice questions and score tracking. Although it worked, I lost interest and never finished it🥲

When I found this challenge, I revisited the project and realized it didn't need more quiz questions maybe it needed a new idea.

Instead of finishing the quiz, I transformed it into Deploy Friday, a sprint survival game inspired by real developer experiences such as production incidents, urgent meetings, and Friday deployments.

My Experience with GitHub Copilot

GitHub Copilot helped me generate repetitive UI code, prototype gameplay ideas, and refactor JavaScript more quickly.

The biggest benefit was shortening the gap between having an idea and testing it in the browser, allowing me to focus on the game itself rather than boilerplate code.

This challenge reminded me that sometimes unfinished projects don't need more features,they may need a fresh direction 🧐