One suggestion from Ankit Kumar Verma Sir. One Developer Playbook. One first patch that merged in 3–4 days. And a journey that changed how I see open source, engineering, and myself.
By Gautam Kumar Maurya | B.Tech CSE (Data Science), United Institute of Technology, Prayagraj
The story I never planned
Today, I contribute to Wikimedia projects, have received recognition for my open-source contributions, have been selected for community leadership responsibilities, and serve as a WikiClub Tech Envoy at United Institute of Technology (UIT), Prayagraj.
I have travelled from Prayagraj to Gurugram for the Road to Wiki Cohort 2 graduation, met people whose names I had known through online sessions and code reviews, and received awards that I once could not have imagined earning.
But none of this was where I started.
I did not enter Road to Wiki as an experienced Wikimedia developer. I did not know Gerrit. I did not understand the complete upstream contribution workflow. I had no established record of merged Wikimedia patches.
I was simply a college student who wanted to learn.
And surprisingly, the journey began with a casual suggestion.
Ankit Kumar Verma Sir told me to read the Developer Playbook for Road to Wiki. It was not some grand motivational speech or a carefully planned career strategy. It was a suggestion made in conversation.
But sometimes, one small suggestion is enough to change the direction of your learning.
I took it seriously.
I started reading, watching tutorials, attending sessions, experimenting with tools, and trying to understand how people actually contributed to large open-source projects.
Over the following eight to nine months, that effort took me from my first patch to multiple upstream contributions, recognition from the open-source community, and a responsibility to help other students discover the same path.
This is the story of how that happened.
1. Before the first patch, there was a lot I did not know
When I began this journey, I was studying Computer Science and Engineering with a specialization in Data Science at United Institute of Technology, Prayagraj.
Like many engineering students, I was learning programming, exploring technologies, working on projects, and trying to understand what software engineering looked like beyond college assignments.
I knew that open source existed. I knew that developers collaborated on software. But knowing about open source and actually contributing to a mature project are two very different things.
I had to understand unfamiliar tools and workflows.
What was Gerrit, and why did Wikimedia use it? How did Phabricator tasks work? What did upstream contribution mean? How could I modify a repository without breaking existing functionality? What happened after submitting a patch? How did code reviews work?
I did not have all the answers.
So I began with the resources available to me.
I watched YouTube tutorials. I read documentation. I attended online sessions and asked questions. I repeatedly revisited concepts that did not make sense the first time.
I learned Git, explored repository workflows, worked on SSH configuration, and started understanding how tasks, commits, patches, reviews, and automated checks fitted together.
There were moments when the process felt unfamiliar and complicated. But instead of waiting until I understood everything, I kept learning and tried to apply what I was learning.
That was the first important decision I made.
I stopped waiting to become ready and started learning by doing.
2. The Developer Playbook that changed everything
I still remember the importance of that initial suggestion from Ankit Kumar Verma Sir.
He encouraged me to read the Road to Wiki Developer Playbook. I took the suggestion seriously, spent time understanding the material, and began exploring the workflow it described.
The playbook gave me a direction. Instead of randomly learning technologies, I had a practical goal: understand how to make a contribution to a real project.
I started exploring the tools and documentation, learning the basics, and following the steps required to participate in the Wikimedia development process.
There was a difference between watching someone demonstrate a command and using it yourself when something did not work.
I had to practise.
I had to investigate.
I had to learn why a particular step mattered rather than simply memorizing the command.
Gradually, concepts that initially seemed unfamiliar became understandable. I began moving from tutorials to actual repositories, from reading about patches to preparing one of my own.
Then came the first real milestone.
3. My first patch merged in just 3–4 days
My first successful merge remains one of the most motivating moments of this journey.
After learning the basics and working through the contribution process, I submitted my first patch.
I was still learning. I was not an expert in Gerrit or Wikimedia's development workflow. But I had taken the step from studying the process to participating in it.
Then, within approximately three to four days, the patch was merged.
That moment changed something for me.
Until then, contributing to a large open-source project could feel like an intimidating goal. There were unfamiliar tools, complex repositories, review requirements, and people with much more experience than I had.
But now I had evidence that I could participate.
A contribution I had worked on was accepted into the project.
It was not just about seeing a successful status in a code review. It showed me that the learning process was working.
I began thinking differently.
If I could understand the workflow and get one patch merged, why should I stop there?
What else could I learn? What other projects could I explore? What other problems could I investigate?
That first merge gave me the confidence to keep going.
My first patch did not make me an expert. It made me believe that I could become a better contributor if I continued putting in the work.
That distinction matters.
I did not suddenly know everything after the first merge. I simply had enough motivation to continue learning.
And I did.
4. From one patch to exploring the Wikimedia ecosystem
After that first successful contribution, I started exploring more projects and looking for more opportunities to learn.
I became interested in Pywikibot, MediaWiki, Wikimedia-related tools, and different parts of the wider ecosystem.
Each project introduced me to new code, different conventions, and unfamiliar engineering problems.
I began learning that open source is much larger than a single repository or programming language.
There are frontend components, backend systems, automation frameworks, testing infrastructure, localization tools, developer utilities, and countless small improvements that help keep projects reliable.
My work gradually expanded across projects and tasks associated with:
- MediaWiki Core
- MinervaNeue
- GrowthExperiments
- UploadWizard
- ProofreadPage
- Pywikibot
- Function Orchestrator-related development
The problems varied. Some involved JavaScript behaviour, some involved backend interfaces, and others required understanding data handling, localization, initialization order, or automated testing.
For every new task, I had to learn enough about the surrounding implementation to understand the problem before attempting a solution.
That process helped me become more comfortable navigating unfamiliar codebases.
It also taught me that a contribution does not need to be a huge feature to be useful.
A carefully implemented bug fix can improve the experience of people using a project every day. A small correction can make an interface more robust. A change to an underlying component can prevent unexpected behaviour elsewhere.
What matters is whether the change solves a real problem and meets the project's standards.
What I learned from actual contributions
One task involved handling malformed URI fragments in MinervaNeue, helping prevent an unhandled exception during navigation.
Another involved grammatical gender in GrowthExperiments, highlighting how software must account for linguistic differences.
I also worked on issues involving cookie-expiration parameter consistency in MediaWiki Core and HTML entity encoding in UploadWizard.
These were valuable because they forced me to investigate the implementation rather than simply follow a tutorial.
I had to understand what the code was doing, why the issue occurred, and how a change could fix the problem without introducing new ones.
That is where the difference between learning programming and practising software engineering began to become clearer to me.
I was not merely learning how to write code. I was learning how to work within an existing engineering system.
My technical journey and contribution records
5. The recognition that gave me another reason to work harder
As I continued contributing, another important moment arrived.
My work received recognition from the Open Knowledge Initiatives at IIIT Hyderabad and the WikiClub Tech India community.
For a student who had started without knowing the contribution workflow, this recognition was meaningful.
It told me that the effort I was putting into learning and contributing was becoming visible.
I had spent time watching tutorials, reading documentation, attending meetings, investigating tasks, submitting patches, and learning from feedback. Now, people in the community were acknowledging that effort.
That recognition gave me another reason to continue.
I became more motivated to explore projects, improve my understanding, and contribute more consistently.
It is important to say this honestly: recognition does not mean that the learning process is complete. It does not mean every future contribution will be easy.
But when you are working hard at something unfamiliar, constructive recognition can help you realize that your effort is making a difference.
For me, it was a turning point.
I started taking the journey even more seriously.
The T-shirt moment
Another memory from this period stands out.
Ankit Kumar Verma Sir sent me a T-shirt in recognition of my performance.
It may seem like a small gesture, but it meant a lot to me at that stage.
It was a tangible reminder that someone had noticed the effort I was putting into the program.
I remembered the original suggestion to read the Developer Playbook. I remembered beginning without knowing Gerrit. And now, after learning, contributing, and making progress, I was receiving encouragement from the same person who had helped point me in the right direction.
The T-shirt became more than an item of merchandise. For me, it represented encouragement at a time when I was working hard to improve.
It motivated me to keep going.
Sometimes a small gesture can have a lasting effect because of what it represents.
That was one of those moments.
6. Even during my internship in Bangkok, the journey continued
One of the most interesting parts of my Road to Wiki journey was that it continued even when I was away from my usual routine.
I travelled to Bangkok for a 16-day internship at the Asian Institute of Technology (AIT).
It was an opportunity to learn in a different environment, experience an international academic setting, and engage with people beyond my usual campus surroundings.
But my Road to Wiki journey did not simply pause while I was there.
I continued attending online meetings and participating in the contribution workflow whenever I could.
Even while I was in Bangkok, I worked on and submitted additional patches.
That experience taught me something important about consistency.
A learning journey that depends entirely on perfect circumstances will often stop as soon as your routine changes.
There will be examinations, internships, college activities, travel, deadlines, and personal responsibilities.
You cannot always control those circumstances. But you can decide whether to stay connected to the work and continue making progress where possible.
I was not trying to make every day look the same. I was trying to avoid losing the connection I had built with the community.
Road to Wiki had become more than a short-term activity on my schedule. It had become a learning process I wanted to continue.
And that made it worth returning to, even during a busy period.
7. The gkm563 identity: from learning contributor to a recognizable presence
As the months passed, my contributions and activity became more visible within the community.
My username, gkm563, started appearing across tasks, patches, and discussions.
There is a funny side to this.
During conversations with technical peers and seniors, I heard comments about how frequently they encountered my ID in contribution discussions.
Some joked that whenever they saw gkm563 claiming a task or submitting a patch, they wondered what would happen next. Others teased me about being everywhere in the technical workflow.
I took these comments in the spirit in which they were shared: as friendly banter about how active I had become.
I am not going to present those jokes as an official endorsement or claim that every developer shared the same opinion. But they became memorable moments because they reflected a change in how I was participating.
At the beginning, I was learning how to submit a patch.
Later, I was regularly exploring tasks, contributing to projects, and becoming a familiar participant in the workflow.
That is a satisfying kind of progress.
Not because a username becomes famous, but because consistent work starts creating a recognizable record of participation.
I had gone from asking how the process worked to actively taking part in it.
And there was still so much left to learn.
8. The numbers matter, but the learning matters more
My Road to Wiki journey involved many contributions across different projects and tasks.
My public portfolio has documented more than 30 broader contribution activities and reports 26+ authored Gerrit patches and 13+ merged changes in the corresponding portfolio snapshot. My retrospective also highlights eight selected upstream patches from the January–June 2026 reporting period.
These numbers describe different views of my work, so I do not treat them as interchangeable.
What matters to me is what happened between those submissions.
I learned to read unfamiliar code. I became more comfortable debugging. I learned how to investigate an issue, prepare a patch, respond to feedback, and work through the review process.
I learned that a successful contribution is not just about writing code that runs on your own machine. It must fit into the larger project and remain understandable to the people who will maintain it.
I also learned to appreciate small improvements.
A good engineering contribution may involve only a few lines of code, but finding the right solution can require substantial investigation.
That is why I value the process as much as the final status.
The first merge gave me motivation. The subsequent contributions helped me develop the habits that make sustained participation possible.
9. The road from Best Contributor to campus leadership
As my participation continued, my journey brought me recognition beyond individual patches.
I received the Best Contributor Award and the Most Active Contributor Award during the Road to Wiki graduation experience. I also secured first rank in the WikiClub Tech open-source contribution sprint.
These recognitions were important milestones, but they also gave me a broader perspective.
At the beginning, I was focused on learning the tools and making my first contribution.
Then I became focused on improving my technical work and contributing more consistently.
Over time, I began thinking about the wider community: how students could get started, how they could learn the workflow, and how more people could participate in open source.
That change in perspective mattered.
Technical growth is valuable, but it becomes even more useful when you can share what you have learned and help others begin their own journeys.
Today, I serve as a WikiClub Tech Envoy at United Institute of Technology, Prayagraj.
For me, this is one of the most meaningful outcomes of the entire journey.
I began without knowing how Gerrit worked. Now I have an opportunity to help connect students at my own college with the Wikimedia technical ecosystem and the wider open-source community.
That does not mean I have finished learning. Quite the opposite.
It means that, while I continue improving my own skills, I can also help other students find their starting point.
I want them to know that they do not need to be experts before making their first contribution.
They can start with the documentation, learn the tools, investigate a small task, and build confidence through practice.
That is how my journey began.
And that is the kind of environment I want to help build at UIT.
10. The final chapter of Cohort 2: Gurugram, 2–4 October 2026
After months of online sessions, contribution work, code reviews, and collaboration, the Road to Wiki Cohort 2 graduation brought the community together in person.
I travelled from Prayagraj to Gurugram for the three-day experience.
The trip was fully funded, which made the opportunity especially meaningful. I could participate in the graduation and meet the people who had been part of my learning journey.
The travel itself became part of the memory.
The Vande Bharat journey
The journey toward Gurugram was not just about reaching a destination.
It represented the transition from months of online learning to an in-person gathering of contributors, mentors, and organizers.
The Vande Bharat train experience made the trip even more memorable.
I had spent months attending meetings from my own environment, learning through videos, and working on code. Now I was travelling to meet the people behind those sessions and contributions.
It was a reminder of how far a seemingly ordinary starting point can take you.
A casual suggestion to read a playbook had led to tutorials, patches, reviews, recognition, and now a journey to celebrate the end of the cohort.
Meeting people beyond the screen
One of the best parts of the graduation experience was meeting people I had previously known through online interactions.
I was glad to meet Dev Jadiya, Anushka Patel, Tejinder Kaur, Pushpit Saluja, Shrey, and many other members of the community.
For months, we had been learning and collaborating through virtual sessions and technical workflows. Meeting face to face made those relationships feel more personal.
We could share experiences, talk about what we had learned, discuss challenges, and enjoy the opportunity to spend time together outside the usual contribution environment.
It also reinforced one of the most valuable parts of open source: the community behind the code.
A repository may be where the work happens, but people are what make the collaborative process meaningful.
Day 1: Welcome, connection, and robotics
The first day brought the cohort together through the opening activities, technical discussions, networking, and the Robo Build and Assembly Challenge.
The robotics activity was a welcome change from working on software.
Instead of investigating code and reviewing diffs, we were dealing with practical assembly, wiring, coordination, and preparing a robot for the challenge.
The experience involved teamwork and problem-solving in a different form.
It reminded me that technical skills become stronger when you apply them in different environments and work with people who approach problems differently.
Day 2: Technology, Robo War, and recognition
The second day included technical exposure, community discussions, an office visit, and the Robo War challenge.
The robotics competition was one of the memorable highlights. The effort that went into building and preparing the robot finally had a practical outcome.
Late-night work, including assembly and wiring, became part of the shared experience.
The day also included the formal graduation and recognition ceremony.
After months of learning and contributing, receiving awards in person felt special.
I received:
- Best Contributor Award
- Most Active Contributor Award
- First Rank in the WikiClub Tech open-source contribution sprint
I was grateful for all three recognitions.
But I also understood that they were milestones, not a final destination.
The awards recognized work I had already done. The next step was to keep learning and contribute in ways that would be useful to the community.
Day 3: Goodbyes and the journey back
The final day brought the experience to a close.
There were conversations, goodbyes, photographs, and the realization that an important chapter had reached its end.
I returned to Prayagraj with memories of the gathering, recognition for my work, and a clearer understanding of what I wanted to do next.
The graduation marked the end of the cohort experience, but it did not end the relationships or the learning.
I was returning not simply with a certificate, but with a stronger engineering mindset, a wider community, and a responsibility to continue contributing.
11. What I want to carry forward
When I look back at these eight to nine months, the transformation is clear.
I started with little knowledge of the Wikimedia contribution workflow.
I learned through YouTube videos, documentation, online sessions, experimentation, and practical work.
I submitted my first patch and saw it merged within a few days. That success motivated me to explore more projects and keep contributing.
I worked through unfamiliar codebases, learned from reviews, received recognition, continued participating during my internship in Bangkok, and eventually travelled to Gurugram for graduation.
The journey gave me technical skills, but it also taught me patience, consistency, collaboration, and the importance of community.
Most importantly, it changed how I think about opportunities.
You do not always need a perfect plan before you begin. Sometimes you need to take one suggestion seriously, put in the effort, and see where the learning takes you.
I also want to help other students discover that same possibility.
As a WikiClub Tech Envoy at UIT, I want to encourage students to explore Wikimedia projects, understand open-source workflows, and build confidence through practical contributions.
The goal is not to create a culture where people compete only over patch counts or awards.
The goal is to build a community where students learn, collaborate, contribute, and help each other improve.
Acknowledgements
I am grateful to Ankit Kumar Verma Sir for the suggestion that helped start this journey and for the encouragement that followed.
I also thank the mentors, organizers, reviewers, and fellow contributors from WikiClub Tech India, the Open Knowledge Initiatives at IIIT Hyderabad, and the wider Wikimedia community.
Thank you to everyone who helped me understand unfamiliar tools, answered questions, reviewed contributions, and made the learning process more approachable.
I am grateful to the people who recognized my efforts and encouraged me to keep improving, including the T-shirt gesture that became a memorable reminder of the support I received.
And thank you to my fellow cohort members for the shared learning, discussions, challenges, friendships, and the unforgettable Gurugram graduation experience.
The road continues
I did not start Road to Wiki knowing Gerrit.
I started by reading a playbook because someone encouraged me to do so.
I watched tutorials. I attended sessions. I experimented. I submitted my first patch. It merged in three to four days, and I found the motivation to continue.
One contribution became another learning opportunity. Recognition encouraged me to work harder. The community helped me grow. Even during a 16-day internship in Bangkok, I continued attending meetings and submitting patches.
Eventually, the journey took me to Gurugram, where I met the people behind the online community and celebrated the work we had done.
Today, I carry the lessons of that journey into my work at United Institute of Technology, where I serve as a WikiClub Tech Envoy.
I am proud of the progress, but I know there is much more to learn.
From not knowing Gerrit to contributing upstream. From my first patch to receiving the Best Contributor Award. From learning as a student to helping build the open-source community at my college.
That is what Road to Wiki Cohort 2 means to me.
And the most important part is this: the journey is still going on.
Read the journey through my posts and contribution records
Personal records
- My Road to Wiki Cohort 2 journey
- My personal website
- My LinkedIn profile
- Official Road to Wiki documentation
Technical contributions
- ProofreadPage — Gerrit change 1349040
- MinervaNeue — Phabricator task T424875
- GrowthExperiments — Phabricator task T416226
- MediaWiki Core — Phabricator task T439342
- UploadWizard — Phabricator task T426501
LinkedIn posts documenting the journey
- Road to Wiki learning and contribution reflections
- Graduation Day 1 — Gurugram
- My Road to Wiki learning milestone
- My contribution journey
- My Road to Wiki experience
- Technical learning and contributions
- My progress in the program
- Learning through open-source collaboration
- My technical contribution reflections
- Open-source contribution and learning
- My learning and contribution milestone
- Open-source contribution sprint recognition
- Road to Wiki technical learning
- My contribution journey update
If you are a student who wants to contribute to open source, do not wait until you know everything. Start learning, find a problem, and make your first contribution.
Top comments (0)