From GitHub Student Pack to My First Pull Request

Alexandre Bayanza — Fri, 21 Aug 2026 21:24:19 +0000

1. Before open source: discovering a bigger world

I am a computer science student, and like most students, I learned a lot in class, but I always felt there was more to learn outside of it. One day, a friend told me about the GitHub Student Developer Pack. I had heard about GitHub before, and I even had an account, but I never really understood how it worked.

The pack turned out to matter more than I expected. It gave me free access to tools I could not have afforded on my own, and among everything included, one thing changed the direction of my journey: an "Intro to Open Source" course. That course was the first time someone actually explained, step by step, how a person becomes a contributor — not just a user with a GitHub account, but someone who actually joins a project and adds something to it.

Before that, I knew that repositories existed. I knew that people somehow worked together on the same project. But things like forking, cloning, pull requests, issues, and especially working with two branches at the same time — all of that felt confusing to me. I had heard people talk about how developers all over the world contribute to the same project together, but I could not imagine how that actually worked in practice. It felt like a world that existed somewhere far away, run by people much more experienced than me. The course was what finally made that world feel reachable.

2. Learning how open source works

I did not learn this from a course or a tutorial video that explained everything at once. I learned it by doing. I created some of my own repositories and just worked on them, pushing changes, trying things out, breaking things, and fixing them again. Slowly, that is how I learned to read a repository — not by memorizing definitions, but by actually being inside one.

One thing that really changed how I thought about contributing was learning that a pull request is not just "submit code and wait." When I opened my own pull request later, I had to write a description explaining what the change does and how I tested it. Writing that description taught me that open source is also about communication — you are not just handing over code, you are explaining your thinking to other people so they can understand and trust it.

I also noticed something about myself during this process: sometimes we limit ourselves simply because we don't ask questions. In open source, I learned that when you are stuck, you are expected to ask. Nobody expects you to already know everything.

3. Finding my first contribution opportunity

I wanted my first contribution to actually solve a real problem, not just be a project I built for myself with no real use. The intro to open source course had shown me where beginners usually start looking, so I went to forgoodfirstissue.github.com. I filtered by HTML, since that was a language I was comfortable with, and that is how I found the CodeYourFuture curriculum project.

The repository had 129 open issues. Among all of them, one caught my attention: "Add internal anchor link checker."

To explain the problem simply: documentation websites often have links that point to a specific section inside another page, using something called an anchor. For example, a link might look like this:

/sdc/legacy/sprints/1/day-plan#coming-soon

The part after the # points to a specific section on that page. But over time, as pages get edited, headings can change or get removed — and then the link is technically still there, but it points to nothing. It becomes broken, and nobody notices right away. The goal of this issue was to build a tool that could actually check these internal anchor links and report the ones that no longer point to a real section.

4. Building the internal anchor link checker

This was my first time working with Go. I did not know the language before, but I did not let that stop me — I just tried, and learned as I went. I had a small amount of prior knowledge of Markdown, which helped, but I still needed to understand exactly how the curriculum's pages, headings, and anchors were structured before I could check anything properly.

The real challenge was not just writing code that scans files. It was figuring out how to correctly detect when a link had become broken — for example, understanding what should happen when a section that a link pointed to had been removed. That took time to think through carefully.

I worked on this mostly alone, following tutorials when I got stuck, and running everything through Git Bash on the command line. In total, it took me about two days of work — not full, intensive days, but steady progress bit by bit.

By the end, the checker could scan the Markdown files in the repository, collect all the available anchors, check the internal links against them, and report any broken ones.

5. Creating my first pull request

When it was time to open the pull request, I felt genuinely nervous — and honestly, part of that nervousness came from something simple: the repository's PR editor did not have an example template to follow. So beyond writing the code, I also had to learn how to write a good pull request description from scratch. Here is what I ended up writing:

This PR adds an internal anchor link checker to ensure that links pointing to sections within the curriculum resolve correctly. The checker scans Markdown files, collects available anchors from pages, and reports broken internal anchor references that do not match existing sections.

For testing, I explained that I ran the checker locally, and verified that it correctly detected broken anchors while still passing when all anchors were valid.

Opening that pull request was a strange feeling. My code was no longer just sitting on my own computer — it was now part of a real, shared project, waiting to be looked at by other people. It made me realize that a pull request is not only about submitting code. It's a way of stepping into a community and saying, "I want to help build this with you."

Then came a part nobody really tells you about when you're new to this: the waiting. I submitted the PR and then... nothing happened for a while. No comment, no review, nothing. I kept checking back every so often, half-expecting a reply that wasn't there yet, and I had to remind myself that this is completely normal — maintainers are often reviewing contributions in their free time, on top of everything else in their lives. My part was done for now; the rest wasn't mine to control.

Three weeks later, a maintainer, illicitonion, finally reviewed it. The comment was simple: "Thank you so much, this is really useful! 🎉" — and the PR was approved and merged. Reading that felt better than I expected. It wasn't just relief that the code worked. It was the realization that something I built, as a complete beginner in Go, was now actually part of a project other people use.

6. Lessons from this experience

A few things really stayed with me after this:

You don't need to be an expert before you start. I didn't know Go, and I didn't fear it — I just tried, and learned along the way.
Asking questions when you're stuck is not a weakness. It's part of how open source actually works.
Reading and understanding other people's code is its own skill, and it gets better the more you practice it.
A small fix, like catching one broken link, can still genuinely help the people who use that project.
More than anything, I learned patience — learning to stay calm with something instead of getting nervous, and instead calmly checking, step by step, where things were not working.
Patience does not end when you hit "submit." Waiting three weeks for a review taught me that contributing is not just about writing code and being done — it's also about trusting the process after your part is finished, and not mistaking silence for rejection.

7. Looking ahead

This contribution was small in size, but it taught me a lot about how I want to grow as a computer science student. It pushed me to be curious about a language I didn't know, to keep going when something didn't work on the first try, and to reach out and become part of a real community working on a shared project, instead of only building things alone in my own corner.

A message to other students

If you are a student who feels like you are not "ready" for open source yet — I understand that feeling, because I had it too. But you don't need to wait until you know everything. You can start with something small, like I did. Look for an issue that feels real to you. Try, get stuck, ask for help, and keep going.

And honestly, this is not only true for open source. It is true for almost anything in life that feels too big to start. We often wait for the moment we feel fully ready — ready enough to apply, to speak up, to try the new language, to take the harder path. That moment rarely comes on its own. It comes because you started before you felt ready, and you became ready along the way.

So whatever your "first pull request" is — in code, in your studies, in your career, in your life — don't wait for permission to begin. Start small, stay curious, ask when you're stuck, and let the process itself turn you into the person who is ready.

Taste of Home: The Story Behind Sombe

Alexandre Bayanza — Fri, 31 Jul 2026 08:48:56 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

Taste of Home — a landing page telling the story of Sombe, one of the most beloved comfort foods of the Democratic Republic of the Congo. Sombe is made from cassava leaves, pounded fine and simmered for hours with palm oil, peanut paste, and aromatics until they turn soft and deeply savoury.

Rather than building a restaurant-style promo page, I wanted the site to work like a piece of editorial storytelling — closer to a food culture feature than an ad. It walks through:

The Story — what the dish means beyond the ingredients
Why It Feels Like Home — family, tradition, and community
Ingredients — flip cards (torn-leaf shaped, not generic rectangles, as a nod to how cassava leaves are hand-torn and pounded)
Preparation — a five-step scroll-animated timeline from harvest to serving
Gallery — a masonry layout with a keyboard-accessible lightbox
Cultural Importance & Regional Variations — how the dish shifts across the country
A closing prompt: "Every culture has a comfort food. What's yours?"

Built entirely with HTML5, CSS3, and vanilla JavaScript — no frameworks, no UI libraries. Bonus features include a dark mode toggle, scroll progress indicator, a print-recipe button, and a back-to-top button.

Demo

🔗 Live site: https://alexandrebayanza-maker.github.io/tastehome/
💻 Source code: https://github.com/alexandrebayanza-maker/tastehome

alexandrebayanza-maker.github.io

Journey

I wanted to move away from the "restaurant menu" instinct that comfort-food landing pages usually default to, and instead treat the page like a short documentary — the food as a way into a family and a culture, not a product to sell.

A few things I'm proud of:

The torn-leaf clip-path used on the ingredient cards instead of standard rounded rectangles — a small detail, but it ties the visual language back to the actual dish (cassava leaves are torn and pounded by hand, not neatly cut).
The preparation timeline fills in sync with scroll position, echoing the slow, unhurried nature of the cooking process itself.
Keeping everything accessible by default: semantic landmarks, visible focus states, full keyboard support in the gallery lightbox, and complete prefers-reduced-motion support — built in from the start rather than bolted on.

What I'd do next: swap in a short audio clip or field recording to give the "Culture" section more texture.

Thanks for running this challenge — it was a genuinely nice excuse to write about food that means something rather than just design another landing page!

DEV Community: Alexandre Bayanza