From Simple GitHub Contributions to a Production Wikimedia Merge — My Open Source Journey as Gautam Kumar Maurya (GKM)
Open source always looked exciting to me.
I used to see developers contributing to large organizations, getting their patches reviewed by experienced engineers, discussing architecture decisions, and working on production systems used by millions of people worldwide.
At that time, honestly, I never thought that one day my own contribution would get merged into Wikimedia’s production codebase.
But recently, that happened.
My merge request for Wikimedia’s Function Orchestrator repository was successfully reviewed, approved, merged into the main branch, and marked “Ready to Deploy” for production deployment.
For many experienced engineers, this may look like a small contribution.
But for me — Gautam Kumar Maurya (GKM), a 2nd-year BTech Data Science student — this journey taught me more about real software engineering than many tutorial projects ever could.
And this blog is not just about a merged PR.
It is about:
- learning how real engineering workflows work,
- understanding large codebases,
- struggling through CI/CD confusion,
- moving from beginner GitHub contributions to production-level open source contribution,
- and learning how collaborative software engineering actually happens.
How My Open Source Journey Started
Like many students, I initially started with very basic GitHub
Open source always looked exciting to me.
I used to see developers contributing to large organizations, getting their patches reviewed by experienced engineers, discussing architecture decisions, and working on production systems used by millions of people worldwide.
At that time, honestly, I never thought that one day my own contribution would get merged into Wikimedia’s production codebase.
But recently, that happened.
My merge request for Wikimedia’s Function Orchestrator repository was successfully reviewed, approved, merged into the main branch, and marked “Ready to Deploy” for production deployment.
For many experienced engineers, this may look like a small contribution.
But for me — Gautam Kumar Maurya (GKM), a 2nd-year BTech Data Science student — this journey taught me more about real software engineering than many tutorial projects ever could.
And this blog is not just about a merged PR.
It is about:
learning how real engineering workflows work,
understanding large codebases,
struggling through CI/CD confusion,
moving from beginner GitHub contributions to production-level open source contribution,
and learning how collaborative software engineering actually happens.
How My Open Source Journey Started
Like many students, I initially started with very basic GitHub contributions.
At that stage, I mostly understood:
- repositories,
- commits,
- pull requests,
- and simple fixes.
But when I entered the Wikimedia ecosystem, I realized things were very different from normal GitHub projects.
There were multiple systems involved:
- Phabricator
- Gerrit
- GitLab
- CI/CD pipelines
- Production deployment workflows
- Code review standards
- Task boards
- Merge workflows
Initially, all of this felt very confusing.
Sometimes even understanding where to submit changes was difficult.
But slowly, I started exploring things on my own.
Understanding Phabricator, Gerrit, and GitLab
One thing I genuinely liked about Wikimedia was that contributors are expected to understand the workflow properly.
Nobody spoon-feeds everything.
I started reading tasks on Phabricator and understanding how discussions happen between maintainers and contributors.
Then I explored Gerrit workflows.
Then later, I learned that some repositories had moved from Gerrit to GitLab-based merge requests.
This particular contribution itself involved understanding:
- repository migration,
- GitLab merge requests,
- branch-based contribution workflow,
- and CI/CD-based merge pipelines.
At first, it was overwhelming.
But this process slowly improved my confidence.
Road To Wiki Sessions Helped Me a Lot
One important thing that genuinely helped me was the “Road To Wiki” sessions.
I actually could not properly fill the form and participate directly at that time.
So instead, I started watching the session recordings available on YouTube.
One session that helped me significantly was the CI/CD session.
Until then, CI/CD felt like a very abstract topic to me.
But after watching those sessions carefully, I started understanding:
- pipelines,
- automated checks,
- why builds fail,
- why reviews matter,
- and how production-level repositories maintain quality.
While working on my Wikimedia contribution, many concepts from those sessions actually became useful in real situations.
That was one of the first times I realized:
learning becomes much more meaningful when you apply it in real engineering workflows.
Mentors Played a Huge Role
I genuinely believe that guidance matters a lot in open source.
Several mentors and seniors played an important role in helping me stay consistent and improve my contribution quality.
Ankit Sir especially played a major role.
During one event, he said something that stayed in my mind:
“Focus more on quality codebase contributions rather than documentation-based contributions.”
That advice genuinely changed my approach.
Instead of only trying easy contributions, I started spending more time:
- reading codebases,
- understanding architecture,
- exploring workflows,
- and trying deeper engineering-level tasks.
Hridyesh Sir and Sanskar Sir also played an important role through guidance, motivation, and support during the learning process.
Sometimes in open source, even understanding the workflow itself takes a lot of effort.
Having guidance during that phase matters a lot.
The Contribution That Changed My Confidence
The task I worked on was:
“Add accessors for WFFunctionCall internals”
At first glance, the task looked small.
But when I started exploring the repository properly, I realized the real challenge was not writing code.
The real challenge was:
- understanding the existing architecture,
- maintaining conventions,
- safely modifying existing systems,
- and ensuring maintainability.
The contribution involved:
- adding proper accessor methods,
- improving encapsulation,
- replacing direct internal property access,
- and improving maintainability in the codebase.
This taught me something important:
Real software engineering is not only about writing complex algorithms.
A lot of engineering is about:
- maintainability,
- architecture,
- clean abstractions,
- conventions,
- and collaboration.
That realization changed my thinking significantly.
The Review Process Taught Me a Lot
One of the most valuable parts of this journey was the review process.
The maintainers reviewed the contribution carefully.
There were:
- discussions,
- follow-up improvements,
- CI/CD issues,
- and architecture-related refinements.
At one point, the maintainer even clarified that the CI failure was not caused by my patch.
That itself was a learning moment because I got exposure to real-world CI pipeline behavior.
The most satisfying moment was when the maintainer responded positively and eventually merged the contribution into the main branch.
Later, the task was moved to:
“Ready to Deploy”
and the maintainer commented:
“Thank you! This will be deployed to production in the next service deploy.”
Reading that message felt surreal.
Because for the first time, I realized:
I had contributed to a real production-level software system.
Why This Contribution Matters to Me
For many people, this may look like a small merged patch.
But for me, this contribution represents:
- consistency,
- learning,
- persistence,
- and engineering growth.
This journey taught me:
- how to work with large codebases,
- how reviews improve code quality,
- how production workflows work,
- how CI/CD pipelines behave,
- and how collaborative engineering actually happens.
Most importantly, it taught me that:
even students can contribute meaningfully to real-world systems if they stay patient and keep learning.
My Wikimedia Contribution Progress So Far
So far:
- multiple Wikimedia/Gerrit-related patches of mine have already been merged,
- several more are currently under review,
- and I continue learning through every contribution.
Every review comment teaches something new.
Every failed pipeline teaches something new.
Every merged patch builds more confidence.
What I Learned From This Journey
If I summarize my biggest learning in one sentence:
Open source is not just about coding — it is about learning how real software engineering works.
And that includes:
- communication,
- reviews,
- maintainability,
- workflows,
- debugging,
- collaboration,
- and patience.
Final Thoughts
I am still learning.
There is still a lot I do not know.
But this journey has shown me that growth happens when you move beyond tutorials and start working with real systems.
To anyone trying to start open source contributions:
don’t be afraid of large codebases.
Initially everything feels confusing.
Phabricator feels confusing.
Gerrit feels confusing.
GitLab workflows feel confusing.
CI/CD feels confusing.
But slowly, things start making sense.
And one day, you may also see your own contribution merged into a production codebase.
— Gautam Kumar Maurya (GKM)
Top comments (0)