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.
Top comments (0)