DEV Community: Gautam Kumar Maurya

From Knowing Nothing About Gerrit to Becoming a WikiClub Tech Envoy: My 9-Month Road to Wiki Journey

Gautam Kumar Maurya — Fri, 23 Oct 2026 00:09:26 +0000

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

Technical contributions

LinkedIn posts documenting the journey

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.

RoadToWiki #WikiClubTechIndia #Wikimedia #OpenSource #MediaWiki #DeveloperCommunity #GautamKumarMaurya #GKM563

From Zero to Wikimedia: An Engineering Blueprint for Open-Source Contributions and MediaWiki Development

Gautam Kumar Maurya — Tue, 07 Jul 2026 21:09:05 +0000

From Zero to Wikimedia: An Engineering Blueprint for Open-Source Contributions and MediaWiki Development

Author: Gautam Kumar Maurya (GKM)

Series: Enterprise Software Engineering & Open-Source Architecture

Executive Summary: Redefining Open-Source Integration

Within software development, open-source contribution is frequently misconstrued as an exclusive domain reserved solely for industry veterans at multinational technology firms. My technical progression over the past quarters directly refutes this preconception.

Today, I actively contribute core code to the global Wikimedia Foundation ecosystem. My structural patches and feature implementations have been successfully reviewed and merged into production repositories across Gerrit, GitHub, and GitLab. Furthermore, this technical performance has been formally documented in the WikiClub Tech India Technical Impact Report (January–June 2026) and the centralized Road to Wiki Contribution Ledger.

This blueprint presents a detailed analysis of how an engineering student specializing in Data Science at the United Institute of Technology (UIT), Prayagraj—and operating within professional developer networks like GDG Prayagraj—navigated large-scale enterprise architectures to establish a verifiable portfolio of production-grade contributions.

Architectural Framework: Road to Wiki Cohort 2

Road to Wiki is a high-impact open-source mentorship initiative directed by WikiClub Tech India under the auspices of The Open Knowledge Initiatives (OKI), IIIT Hyderabad. Unlike traditional introductory programs restricted to low-impact documentation adjustments, Road to Wiki Cohort 2 integrates participants directly into the production codebases powering applications utilized by millions of global users.

Program Parameters & Technical Scope:

Scale and Scope: An elite cohort comprising 90+ selected engineers across 12 partner academic institutions.
Infrastructure Layout: Cross-platform development across Gerrit Code Review, Phabricator Task Management, GitLab Merge Requests, and GitHub Pull Requests.
Core Engineering Focus: Advanced MediaWiki architecture, automated Continuous Integration (CI) pipelines, regression testing, and rigorous code review compliance.

Technical Onboarding: Infrastructure and System Training

Entering the Road to Wiki Cohort 2 program required operating without pre-existing familiarity with legacy Wikimedia systems. The immediate objective was to master enterprise-grade tools, version control protocols, and continuous integration workflows.

1. Environment Configuration and Authentication

Initial milestones involved establishing a stable, localized development environment. This necessitated configuring:

Secure Shell (SSH) cryptographic keys linked across Phabricator and Gerrit servers.
Local Git configurations tailored to multi-platform deployment.
Localized container and runtime testing environments to validate patches prior to upstream deployment.

2. Systematic Technical Analysis: Video Track Audits

To supplement the Wikimedia Developer Playbook, I executed a comprehensive technical audit of the program’s media archive to extract explicit architectural insights. Rather than skim summaries, I methodically parsed over 30 hours of core instructional modules:

Cohort Track Execution: Completed exhaustive reviews of the foundational sequence (Sessions 2, 3, 4, 5, 6, 7, 8, and 10).
Core Systems Modules: Analyzed deep-dives regarding the Basics of Phabricator, SSH, and Technical Contributions alongside Basics of Git and CI/CD Operations.
Language & Stack Masterclasses: Audited technical masterclasses covering the SQL Masterclass, PHP Masterclass, MediaWiki API Framework, Python & Flask API Architecture, and the JavaScript Production Masterclass.
Localization & Identity Systems: Studied explicit workflows for Language Tech Volunteering, Wiki Tools Navigation, and Wikimedia Commons Account Architecture.

This structured training eliminated theoretical gaps and established a highly accurate implementation strategy.

3. Upstream Deployment Pipeline

All code modifications adhered to a strict, non-negotiable delivery pipeline:

[Phabricator Task Identification] ──> [Architectural Code Analysis] ──> [Local Branch Isolation]
                                                                                   │
                                                                                   ▼
[Upstream Merge (+2 Verification)] <── [CI Validation & Human Review] <── [Gerrit/GitLab/GitHub Push]

Portfolio of Technical Contributions

My development efforts spanned across distinct platform environments, requiring adaptability in version control mechanics and code review methodologies.

1. Gerrit Code Review (MediaWiki Core & Extensions)

Gerrit functions as the primary code collaboration engine for MediaWiki. I successfully achieved 10 verified merges into production extensions via Gerrit.

MediaWiki Core Engine: Implemented core system configuration modifications, including the deployment of system aliases like Special:MediaStats and Special:MuteUser, supplemented by intentional Internationalization (i18n) translation refactoring for Ukrainian locales.
GrowthExperiments Extension: Programmed gender-aware exception handling blocks and optimized user interface layouts for the localized HelpPanel component to lower friction for new users.

MinervaNeue Mobile Skin: Diagnosed and neutralized a critical frontend bug related to malformed URI fragment handling that caused execution-blocking JavaScript runtime exceptions. Defended the patch by writing rigorous frontend regression tests.

2. GitLab Pipeline (Function Orchestrator / Abstract Wikipedia)

The Function Orchestrator environment demanded high compliance with complex continuous integration parameters.

Implementation Strategy: Refactored object interaction models by engineering clean public accessor patterns (getFunction(), getArgument(), getArguments()).
Architectural Outcome: Enforced strong object encapsulation principles and eliminated brittle, direct internal property access. This resulted in 3 major production merges via GitLab Merge Requests.

3. GitHub Automation (Tooling Ecosystem)

Leveraging GitHub workflows allowed for collaborative tool development and automation scripting.

Pywikibot Framework: Devoted code contributions to building comprehensive regression test suites. This experience reinforced an industry reality: production-grade test coverage is directly equal in value to feature development, ensuring long-term code stability. I executed 5 validated pull requests within this sector.

Code Review Optimization and Engineering Resilience

A core metric of engineering maturity is the handling of peer review feedback. Large-scale production environments naturally generate friction through rigorous review cycles.

Managing Revisions: Upstream contributions frequently require multiple code iterations (Patch Sets) to address automated testing failures or maintainer optimization requests.
De-personalizing Feedback: Receiving a -1 code quality block from a maintainer is an essential mechanism for architectural alignment, not a personal failure. Shifting focus toward dissecting optimization requests regarding algorithm execution efficiency, naming conventions, and modular design transformed code reviews into high-value asynchronous mentorship sessions.

Mentorship Ecosystem and Technical Leadership

Organizational Gratitude

I express my sincere gratitude to WikiClub Tech India, WikiClub UIT, The Open Knowledge Initiatives (OKI), IIIT Hyderabad, and Ankit Sir for establishing this micro-ecosystem. Road to Wiki successfully bridges the division between academic theory and high-availability software architecture, expanding large-scale open-source opportunities to multi-city developer cohorts.

Mentor & Senior Reviewer Acknowledgment

Operating in enterprise ecosystems is accelerated by the guidance of experienced contributors who convert strict code audits into definitive masterclasses:

Sanskar Dubey: Provided foundational orientation to open-source workflows and extended consistent troubleshooting support through core environment barriers.
Mohd Shadab: Optimized resource, codebase, and documentation discovery, reducing research overhead throughout repository onboarding.
Shivaansh Singh: Established an exceptional benchmark for engineering excellence; observing his contribution patterns catalyzed my day-to-day progression.
Reeti Singh: An essential mentor from UIT whose strategic encouragement streamlined upstream patch delivery and workflow orientation.
Adarsh Kesharwani: Deconstructed deep conceptual blocks, offering structural insights to improve code maintainability and execution logic.
Sarthak Singh: Modeled professional development practices across diverse Wikimedia domains, proving that methodical consistency yields lasting engineering legacy.
Ebenezer Rao: His technical contributions to the Wikimedia Commons Android infrastructure provided a tangible case study on how open-source deployments directly affect millions of end-users.

Community Acknowledgement

I also credit the wider operational network: the WikiClub Tech Mentors, Trusted Testers, Reviewers, upstream Wikimedia Maintainers, Core Foundation Contributors, and fellow Cohort 2 participants. Every technical discussion, pull request review, build failure analysis, and bug report served as a direct driver for engineering growth.

Documented Outcomes and Milestones

Maintaining an analytical, disciplined approach across the onboarding and implementation phases yielded top-tier development outcomes:

First Rank – WikiClub UIT Contribution Marathon: Recognized as the highest-performing contributor during the intensive, collaborative development sprint hosted by WikiClub UIT.
Inclusion in Global Metrics: Performance metrics were formally verified and indexed within the global WikiClub Tech India Technical Impact Report and the Road to Wiki Contribution Ledger.

Engineering Governance: Core Implementation Principles

For developers aiming to scale code into global production networks, I recommend adhering to the following professional protocols:

Prioritize Comprehension Over Code Volatility: Dedicate 80% of the engineering lifecycle to studying historical Phabricator tasks, system architecture docs, and technical video sessions. Restrict active coding to the final 20% of the lifecycle to avoid debt.
Ensure Testing Parity: Never submit a functional logic adjustment without accompanying unit or regression tests. Secure your code against future regressions.
Optimize for Global Audiences: Always implement internationalization (i18n) design patterns. Code must scale seamlessly across multilingual locales and diverse user archetypes.
Value Architectural Consistency: Focus on delivering high-quality, continuous weekly commits rather than volatile bursts of disconnected code.

Future Trajectory

My engagement with open-source systems has established a reliable foundation for complex systems engineering. My upcoming roadmap involves deepening technical contributions across MediaWiki Core, Pywikibot, and Abstract Wikipedia (Function Orchestrator).

Simultaneously, I will leverage this expertise to architect technical initiatives and mentor incoming developer talent within WikiClub Tech India, WikiClub UIT, and GDG Prayagraj, fostering a continuous culture of professional engineering excellence.

Technical Profiles and Portfolio References

Phabricator Identity: Gkm563 Architectural Identity
Gerrit Version Ledger: GKM Upstream Gerrit Ledger
GitHub Production Repository: gkm563 Version Control History

Keywords: #roadtowiki, #gkm563, gautam kuamr maurya, #wikiclub, #techtech india, roadtowiki cohort 2, gdg prayagaaj, Wikimedia Open Source, MediaWiki Core Development, Gerrit Code Review, #IIIT Hyderabad, #WikiClub Tech India Technical Impact Report, #Prayagraj Engineering Student, #Road to Wiki Cohort 2, Wikimedia Contributions, MediaWiki Core, Gerrit Tutorial, GitLab Merge Request, GitHub Pull Request, Wikimedia Developer, Open Source India, Software Engineering Journey, Function Orchestrator, Abstract Wikipedia, GrowthExperiments, MinervaNeue, Pywikibot, Engineering Student, WikiClub Tech India, Open Source Contributions, Code Review, Phabricator, CI/CD, Google Summer of Code, #GSoC Preparation. #GautamKumarMaurya #GKM563

From Engineering Student to Cyber Investigator: My 12-Day Journey at APCSIP-2026 Gautam Kumar Maurya (GKM)

Gautam Kumar Maurya — Thu, 25 Jun 2026 02:39:19 +0000

From Engineering Student to Cyber Investigator: My 12-Day Journey at the Amroha Police Cyber Security Internship Program (APCSIP-2026)

How OSINT, malware sandboxes, UPI fraud trails, dark web recon, and 45+ mentors and co-interns turned a government internship into the most intense classroom of my engineering life

By Gautam Kumar Maurya

"I arrived in Amroha as a complete outsider. I left it as part of a 45-person network of investigators, officers, and analysts who'll probably be in my life for years."

In May 2026, I submitted an application for something called APCSIP-2026 — the Amroha Police Cyber Security Internship Program. I expected a certificate course. Maybe a few lectures on cybersecurity basics.

What I actually walked into was 12 days that took me from filling out tower-dump cell ID maps, to sandboxing Android malware, to tracing UPI fraud trails with bank nodal officers, to standing inside a confidential briefing I still can't talk about in detail, to receiving a Best Content Creator Award from DSP Anjali Kataria Ma'am on the final day.

This is the full story — exactly how it happened, day by day, tool by tool.

Why I Applied

I'm a B.Tech student with a strong pull toward Data Science and Cyber Security. Like most students in this space, my learning so far had come from courses, YouTube, and lab simulations. Useful — but disconnected from how cybercrime is actually investigated on the ground.

APCSIP-2026 promised something different: direct exposure to a real Cyber Crime Cell, real case logic, and real officers who deal with fraud, malware, and digital evidence every single day. I had to try.

Phase 1: The Selection Journey

Application Submission — May 2026

I applied with my academic background and a short note on my interest in digital forensics and threat tracking. Then came the part every applicant dreads: waiting.

Shortlisted for Screening — 21–22 May 2026

The shortlist dropped, along with test instructions sent to registered emails. My name was on it. One gate down, one to go.

The Online Screening Test — 24 May 2026, 6:00–6:30 PM

Thirty minutes. 50 MCQs — 40 on computer applications, IT fundamentals, and basic cybersecurity, plus 10 on general awareness. No negative marking, but also no room to relax.

Offer Letter — Early June 2026

The selection email arrived with the official offer letter, code of conduct undertakings, legal rules, and reporting guidelines from Amroha Police. This wasn't a casual internship — it came with the weight of an actual law-enforcement program attached to it.

Onboarding — June 2026

Document verification, policy undertakings, registration guidelines — all completed before I even set foot in Amroha.

Arrival at Amroha — 10 June 2026

I travelled to Amroha and arrived at Shri Venkateshwara University, set up accommodation, and prepared for what the program called a "12-day intensive training regimen." It would turn out to be 13 days of life, if you count how long it actually took to process everything that happened.

DAY 00 — Welcome: Registration & Orientation

The first day was about structure, not content. I completed onboarding documentation, collected the official welcome kit — badge, offer letter, program materials — and verified my credentials with the student coordinators.

In the afternoon, the program orientation laid out attendance parameters, evaluation criteria, and a code of conduct that made one thing clear immediately: this program ran on discipline, not vibes.

Takeaway: Day 0 set the baseline — successful state-level collaborations begin with operational discipline, not just enthusiasm.

DAY 01 — Cell Briefing: Inside the Cybercrime Ecosystem

The official inauguration ceremony brought together law enforcement and cybersecurity officials for expert talks on why this program — and cybersecurity itself — matters right now.

In the afternoon, we went deep into the cybercrime threat ecosystem: modern attack vectors targeting everyday people, and — more importantly — how local Cyber Crime Cells coordinate with national systems like the NCCRP (National Cyber Crime Reporting Portal) incident logs.

Takeaway: A cyber investigator's real job is mapping the full security loop — from human awareness, to system hardening, to case coordination with state agencies.

DAY 02 — Recon & OSINT: Reading People and the Internet

This was the day cybersecurity stopped being abstract for me.

Session 1 — Cyber Psychology: We studied how scammers, hacktivists, and even terror networks weaponize human emotion online — and the five motivations behind almost every attack: financial gain, revenge, recognition, power, and ideology.

Session 2 — Open Source Intelligence (OSINT): Hands-on, passive data-gathering using Maltego (link analysis), Shodan (IoT search), Google Dorking, Canary Tokens, DeHashed, and FotoForensics.

Then came the moment that actually unsettled me a little: I ran a self-audit on my own digital footprint and found leaked data points from past breaches I didn't even know I'd been part of.

Takeaway: Vulnerability almost always lives in human trust and residual digital footprints — and you can query open registers for intelligence without ever exposing your own investigation.

DAY 03 — Telecom Sorting: Law, Research, and AI

Sessions 1 & 2 — Cyber Laws & Research: A full walkthrough of India's digital legal frameworks under the IT Act, paired with the technical research backbone every case file needs — problem statements, literature reviews, data collection pipelines, sampling layouts, and formal reporting standards.

Sessions 3 & 4 — Career Guide & AI: A career advisory panel on certifications and professional roadmaps, followed by a sharper conversation: how Machine Learning, Deep Learning, and Generative AI are now active tools in threat pattern recognition and predictive cybersecurity.

Takeaway: Building a real case file means combining legal frameworks, structured research methodology, and predictive technology — none of the three works alone.

DAY 04 — Triangulation: Malware and the Forensics Pipeline

Session 1 — Android Malware Analysis: Studying how Android malware is packaged, how it maps to Command & Control (C2) servers, and running static/dynamic binary auditing inside safe, sandboxed environments.

Session 2 — Digital Forensics: The full forensics pipeline — evidence collection, bit-stream imaging, preservation guidelines, and hash verification standards (MD5/SHA-256) that keep proof legally valid.

This was the day I understood, viscerally, that chain of custody isn't bureaucracy — it's the difference between evidence and noise.

Takeaway: Metadata signatures trace threat agents back to their source, but only if data integrity is protected at every single step.

DAY 05 — IP Analysis: SOC, Threat Intel & Bug Bounty

Session 1 — Security Operations Center (SOC): SIEM and EDR architecture, event correlation, and reading log records using Wazuh, Elastic, Wireshark, and NXLog. We also pulled IP reputation checks via VirusTotal, Hybrid Analysis, and IBM X-Force.

Session 2 — Bug Bounty & Ethical Hacking: Subdomain enumeration, API endpoint testing, and business logic flaw-hunting — alongside the ethics of responsible disclosure, severity scoring, and platforms like HackerOne, Bugcrowd, and Intigriti.

Takeaway: Network security isn't a one-time fix. Continuous monitoring and crowdsourced bug bounty programs work together to keep hardening the same endpoints, every single day.

DAY 06 — Mobile Forensics: Compliance & Industry Reality

Session 1 — "Swipe, Secure, Comply": The DPDP Act, RBI and SEBI CSCRF guidelines, the SWIFT Customer Security Program, and incident reporting rules. We also dug into fraud prevention — mule account network detection, SBOM/CBOM, and supply chain security risk.

Session 2 — Industry Experience: Guest speakers shared first-hand career guidance and how to keep skills current in a field that changes every six months.

Takeaway: Compliance frameworks and early cyber-resilience planning are what stand between an organization and a supply chain attack — not just good intentions.

DAY 07 — Vulnerabilities: Blockchain and Real Police Cases

Session 1 — Blockchain & Crypto: Blockchain structure, public/private key cryptography, consensus algorithms, smart contracts, and Web3 security gaps — including private key leaks, smart contract bugs, 51% attacks, and DNS hijacking.

Session 2 — Real Investigations: This was the session that stayed with me longest. Serving police officers walked us through actual cybercrime investigations — digital evidence collection, legal workflows under Section 91 of the CrPC, and live case studies tracing transaction nodes across public ledgers.

Takeaway: Blockchain security lives or dies on cryptographic key protection — and investigators trace transaction nodes across public ledgers the same patient way detectives trace footprints.

DAY 08 — Financial Fraud: UPI, Privacy Law, and a Confidential Session

Session 1 — Data Privacy Law & AI: We studied K.S. Puttaswamy vs. Union of India — the landmark ruling that established privacy as a fundamental right in India — alongside the ethics of responsible AI usage and user data protection.

Session 2 — Confidential Session: I genuinely can't go into the details of this one. It was a closed briefing on professional responsibility, discretion, and trust — how cybersecurity professionals handle sensitive threat intelligence without compromising it. What I can say: it changed how seriously I take confidentiality in this field.

Takeaway: Integrity and confidentiality aren't soft skills in cybersecurity — they're the actual basis of professional investigation work.

DAY 09 — Social Media: Offensive Security & the Dark Web

Session 1 — Offensive Security: Passive and active reconnaissance, system enumeration, directory brute-forcing, and network scanning — plus auditing web security configurations like cross-origin setups and subdomain exposure.

Session 2 — Dark Web & Investigation: The architecture of Tor, the real difference between the clear web, deep web, and dark web, and how onion routing works. We mapped digital footprints across onion nodes using cyber kill chain models.

Takeaway: To defend a system, you first have to think like the person attacking it — mapping subdomains and open ports is half of mitigating exposure.

DAY 10 — Dark Web: Malware Forensics and the Best Content Creator Recognition

Session 1 — Malware Analysis: Working inside isolated VMs (FlareVM, REMnux), parsing network traffic, and tracing trojans, rootkits, and ransomware execution using Process Hacker, Wireshark, TCPView, and PEStudio.

Session 2 — Mobile Forensics: Logical, physical, and filesystem dump extraction, plus advanced methods like JTAG and hardware chip-off for locked or damaged devices.

And then, in the middle of all that technical density, came a moment I genuinely didn't see coming: I was recognized as the Best Content Creator among all internship participants.

I'd been documenting the journey since Day 1 — daily LinkedIn logs, breaking down dense sessions into something people outside the room could actually follow. I didn't do it for recognition. Turns out, it got noticed anyway.

Takeaway: Forensic integrity has to survive even the hardest extraction methods — and sometimes, the work you do quietly in the background is the work that gets seen first.

DAY 11 — Case Simulation: Chain of Custody, Hygiene & Yoga Day

Session 1 — Mobile Forensics: A deeper pass on acquisition standards and strict chain-of-custody protocols — because evidence that isn't preserved correctly might as well not exist in court.

Session 2 — Hygiene & Ethics: Cyber hygiene fundamentals — strong password practices, MFA setup, digital safety loops — followed by something unexpected: group exercises for International Yoga Day, focused on mental clarity and discipline.

It sounds like an odd pairing — forensic chain of custody and yoga, in the same day — but it landed perfectly. High-pressure forensic work needs a calm mind as much as it needs the right tools.

Takeaway: Technical execution means nothing without ethical responsibility behind it — and mental discipline is what keeps decision-making sharp under pressure.

DAY 12 — Review Panel: Presentation, Certification, and DSP Anjali Kataria Ma'am

Day 12 began with the weight every internship's final day carries.

Morning — Evaluation & Presentations: I presented my weekly findings and technical reports to the Cyber Crime Cell valedictory board, then sat in on a discussion about secure software design pipelines and open database setups with senior officers — a reminder that this program respected us enough to include us in real operational conversations, not just lecture us.

Afternoon — Valedictory & Distribution: I received my official internship certificate, recognizing the successful completion of APCSIP-2026.

And then came the moment I'll remember longest: meeting DSP Anjali Kataria Ma'am, who personally presented the Best Content Creator Award along with a commemorative cyber mug — a small, specific gesture that somehow made the whole program feel personal rather than procedural.

We closed with final networking, peer group discussions, and a group photograph with mentors and coordinators — the same faces from Day 0, now impossible to call strangers.

Takeaway: I walked out with strong, hands-on capability in OSINT recon, malware analysis, and location-mapping frameworks — but the certificate was never really the point.

Honors & Recognition

🏆 Best Content Creator — #APCSIP2026, awarded by the Cyber Crime Cell, Amroha Police
☕ Commemorative Cyber Mug, presented personally by DSP Anjali Kataria Ma'am
📜 Certificate of Appreciation for outstanding contribution to APCSIP-2026
🎓 Official Internship Completion Certificate

The People Behind the Program

Twelve technical days are only half the story. The other half is the people who led them:

Anjali Kataria — Deputy Superintendent of Police (DSP), Cyber Crime Cell, UP Police
Bhanu Sharma — Program Coordinator, APCSIP-2026
Vikash Kumar — Student Coordinator, Logistics
Rakshit Tandon — Senior Cyber Security Consultant & National Advisor to law enforcement agencies
Amit Dubey — Cyber Crime Investigator, National Cyber Security Expert & Author
Saumay Srivastava — Threat Intelligence Researcher, OSINT & Dark Web Profiling Specialist
Yugal Pathal — DFIR Specialist, Digital Forensics & Incident Response
Nitin Pandey — Cyber Security Expert, Network Audits & Penetration Testing
Kailash D Agrawal — Payment Security Consultant, Financial Cyber Fraud Analyst
Pakhi Garg — Cyber Law & Legal Advisor, DPDP Act Specialist
Yash Chavhan — Web3 & Blockchain Security Lead, Smart Contract Auditor
Manoj Kushwaha — Student Coordinator, Technical Operations

Every single one of them turned a 12-day schedule into a genuinely operational learning environment.

A Journey of Growth: 13 Days in Amroha

This internship was never just a technical training program — it was a 13-day push completely outside my comfort zone. I arrived in Amroha, a city I'd never been to, knowing no one.

By the end, I'd interacted with more than 45 people — law enforcement leaders, senior state cyber cell officers, national-level industry advisors, student coordinators, and brilliant co-interns. Late-night forensic debugging sessions. Long arguments over how to map a UPI fraud trail. Conversations that started as technical debates and ended as friendships.

I didn't just leave with technical knowledge of mobile forensics, OSINT, and SOC tooling. I left with a professional network and a few lifelong friends — which, looking back, might be the actual return on investment of this entire program.

What I Actually Took Away

1. Evidence is worthless without process. Day 4 and Day 11 made it brutally clear: a perfect technical finding means nothing if chain of custody breaks anywhere along the way.

2. Cybercrime is a coordination problem, not just a technical one. From NCCRP logs on Day 1 to bank nodal communications on Day 8, almost every real case depended on multiple agencies talking to each other correctly.

3. The attacker's playbook is the defender's syllabus. Offensive security, malware sandboxing, and OSINT all taught me the same thing from different angles: you can't protect what you don't understand how to attack.

4. Confidentiality is a skill, not just a rule. The closed Day 8 session taught me more about professional discretion than any policy document ever could.

5. Documentation is its own form of expertise. The Best Content Creator Award didn't come from being the most technical person in the room — it came from being willing to translate twelve dense days into something other people could actually learn from.

Advice for Future APCSIP Applicants

Apply even if you don't feel "ready." I wasn't fluent in OSINT or malware sandboxing before Day 0 — that's the entire point of the program.
Treat the screening test like a real exam. 50 questions in 30 minutes rewards calm, practical thinking over last-minute cramming.
Document everything from Day 0. You won't know which session will matter most until you're several days past it.
Talk to everyone in the room. The co-intern next to you in the forensics lab might end up being one of your strongest professional connections.
Take the confidential and ethics sessions seriously. They teach the part of cybersecurity that never makes it into a tutorial video.

Final Thoughts

I came to APCSIP-2026 expecting to learn a few tools.

I left having sandboxed live malware, traced UPI fraud trails with bank officers, mapped dark web architecture, sat through a confidential briefing I still hold carefully, and stood in front of DSP Anjali Kataria Ma'am to receive recognition for something I built almost as a side effect of just paying attention.

If twelve technical days taught me one thing that wasn't on any slide, it's this: cybersecurity is built by people who are willing to go deep into the unglamorous parts — chain of custody, compliance frameworks, confidentiality — and stay disciplined about them, every single time.

Thank you to the entire APCSIP-2026 team, to every mentor on that list, and to the 45+ people who turned a government cyber internship into one of the most important chapters of my engineering life so far.

If you're working toward a path in cybersecurity, digital forensics, or cybercrime investigation — let's connect. I'd genuinely love to hear your journey too.

Frequently Asked Questions

What is the Amroha Police Cyber Security Internship Program (APCSIP-2026)?
APCSIP-2026 is a 12-day field-based cybersecurity internship run in coordination with the Cyber Crime Cell of UP Police in Amroha, covering OSINT, digital forensics, malware analysis, SOC operations, financial fraud investigation, blockchain security, and dark web reconnaissance.

How does selection for APCSIP work?
Selection runs through an online application, a shortlisting round, and a timed 50-question online screening test (40 questions on computer applications/IT/cybersecurity, 10 on general awareness) completed in 30 minutes with no negative marking.

What topics does APCSIP-2026 cover?
Across 12 days, the program covers cyber psychology, OSINT (Maltego, Shodan, Google Dorking), cyber law, Android malware analysis, digital forensics, SOC operations (SIEM/EDR), bug bounty and ethical hacking, DPDP Act compliance, blockchain and Web3 security, UPI fraud investigation, dark web architecture, and mobile forensics including chip-off extraction.

Who leads the Amroha Police Cyber Security Internship Program?
The program is led by DSP Anjali Kataria of the UP Police Cyber Crime Cell, alongside a panel of national cybersecurity consultants, DFIR specialists, OSINT researchers, and legal advisors.

Is APCSIP useful for engineering students outside core cybersecurity branches?
Yes — the program is built around foundational investigative and digital literacy skills, making it relevant for Computer Science, Data Science, IT, and any engineering student interested in law-enforcement-adjacent technology careers.

GautamKumarMaurya #APCSIP2026 #AmrohaPolice #UPPolice #CyberSecurity #CyberCrime #CyberForensics #DigitalForensics #OSINT #DarkWeb #Blockchain #MalwareAnalysis #BugBounty #DPDPAct #UPIFraud #EngineeringStudent #DataScience #LearningInPublic

My AIT Bangkok Journey Begins: From College Auditorium to Selection Day | Gautam Kumar Maurya

Gautam Kumar Maurya — Wed, 03 Jun 2026 01:54:23 +0000

There are some moments in student life that completely change the way you look at yourself and your future. For me, one of those moments started inside my college auditorium during my 4th semester of BTech.

At that time, I never imagined that a simple briefing session would eventually become the beginning of my international journey toward AIT Bangkok, Thailand.

This blog is not just about a selection process.
It is about confusion, self-doubt, pressure, hard work, summer heat, semester exams, opportunities, and finally saying “YES” to something bigger than myself.

My name is Gautam Kumar Maurya, and this is the beginning of my AIT Bangkok journey.

The Day Everything Started

During our 4th semester, our college organized an official briefing session in the auditorium regarding a summer training and international exposure program at AIT Bangkok (Asian Institute of Technology), Thailand.

The faculty members explained everything in detail:

Eligibility criteria
Selection process
Benefits of the program
Deadlines
Duration of stay in Thailand
Fees and scholarship categories
Documentation process
Overall experience students would get at AIT Bangkok

At first, I was just listening casually.

I was not fully sure whether I even wanted to go.

But somewhere inside me, curiosity had already started growing.

Understanding the AIT Bangkok Package Categories

One important thing explained during the briefing was the package structure provided by the college.

There were mainly 3 categories:

₹15,000 Package
₹35,000 Package
₹55,000 Package

The category assigned to students depended on their:

Academic performance
Overall profile
Evaluation performance
Selection process scores

Naturally, every student wanted a better category.

For me, things were different.

I had already decided one thing in my mind:

“If I get the ₹15K package, I will go. Otherwise, maybe not.”

At that time, I was still confused about whether I should really take such a big step or not.

Applying at the Last Moment

After the briefing session, the college released a Google Form for registration.

Honestly, I filled that form at the very last moment.

I kept thinking:

Should I go?
Should I avoid it?
Is it worth it?
Will I manage everything?

But finally, I applied.

The form was detailed and serious. It asked for:

10th marks
12th marks
JEE details
Academic records
Personal details
Reasons for joining AIT Bangkok
Career goals
Motivation and objectives

It felt less like a normal form and more like the first step toward something important.

The Evaluation Test at DLC

After evaluating the forms, the college shortlisted students for a test.

The test was conducted in DLC (Digital Learning Centre).

I still remember the atmosphere there.

Some students were using phones and unfair methods during the test. But I decided one thing clearly:

“If I qualify, I want to qualify honestly.”

The paper was not extremely difficult. It included:

Reasoning questions
Mathematics
General Knowledge
Verbal Ability

I gave the exam seriously.

When the results came, I scored around 91%.

Some students scored even higher, around 99%, but still, I was among the top-performing students in that evaluation.

At that moment, I started feeling that maybe this opportunity was actually possible for me.

The Interview Call During Semester Exams

After the test, selected students received calls and emails for the next round — the physical interview.

The interview was scheduled at UCER (United College of Engineering and Research), not at UIT.

And the timing?

My semester exams were already going on.

One day before the interview, I had my semester paper.

My mind was already exhausted with studies, pressure, travel, and exam stress.

Still, I decided to go.

Not because I was fully confident.

But because I wanted to know one thing:

“Will I actually get selected for the ₹15K category or not?”

Travelling in Extreme Heat for the Interview

I travelled from Prayagraj to Naini during peak summer heat.

The temperature was around 45+ degree Celsius.

It was chaotic, exhausting, and honestly very difficult because exams were happening simultaneously.

But sometimes opportunities do not come at comfortable timings.

Sometimes you have to choose discomfort first.

Some of my friends also came for the interview process.

Everyone was nervous.

Outside the interview room, students were discussing categories and expectations continuously.

Many students coming out of interviews were saying:

“They offered me ₹55K.”

Hearing that repeatedly made me think:

“Maybe I will also get only ₹15K.”
“Should I even continue if that happens?”

But I still waited for my turn.

My AIT Bangkok Interview Experience

Finally, my interview started.

Faculty members including Divya Bharti Ma’am, Ravi Prasad Tiwari Sir, and Santosh Sir were present there.

They asked many questions:

Why do you want to go to AIT?
What do you know about AIT Bangkok?
What motivates you?
What is your objective?
How will this help your future?
How will you handle difficult situations abroad?
What if someone gets injured there?
Questions about academics and personality

It was not just an academic interview.

They were trying to understand mindset, responsibility, and confidence.

I answered honestly.

I did not try to act overconfident.

I simply spoke about what I genuinely felt.

And then came the moment I still remember clearly.

They said:

“Gautam, congratulations. You are getting the ₹15K category. Are you willing to go?”

And without overthinking this time, I replied:

“Yes sir, I will go.”

That was the moment where my journey truly started.

The Cheque Issue and More Struggles

After selection, the college gave us official documents and asked us to submit a cheque/DD in the university’s name.

Now this became another challenge.

At that time:

My semester exams were still ongoing
I did not have a cheque system available
Time was very limited

Thankfully, my friend Aniket helped me during this process.

I gave him the required amount, and he helped arrange the cheque/DD process.

Again, during extreme heat and exam pressure, I travelled to college for document verification and submission.

Honestly, balancing:

semester exams,
documentation,
travel,
interviews,
and international preparation

was mentally exhausting.

But this process taught me something important:

Big opportunities also bring responsibility and pressure together.

Waiting for the Final Journey

After document submission, I asked the faculty:

“Sir, when will we finally go to Bangkok?”

They replied that the schedule could vary between July, August, or September depending on arrangements and confirmations.

And that was it.

Now the waiting phase had started.

But another important journey was still remaining:

My passport journey.

Because until this point, I had never applied for a passport before.

And trust me, that journey became another completely different experience filled with confusion, learning, travelling, verification, and first-time experiences.

What’s Next?

This blog is only Part 1 of my AIT Bangkok journey.

In the next blog, I will share:

How I applied for my passport
My first passport office experience
Problems during application
Managing everything during semesters
Documentation process
Police verification
Real student struggles during passport processing

And finally, how I received my passport today.

Final Thoughts

Sometimes life changes because of one small decision.

For me, that decision was filling a Google Form at the last moment.

From sitting confused in an auditorium to getting selected for an international opportunity at AIT Bangkok, this journey already taught me:

honesty matters,
opportunities require courage,
and growth starts when comfort ends.

This is only the beginning.

— Gautam Kumar Maurya

contributions. From Simple GitHub Contributions to a Production Wikimedia Merge — My Open Source Journey as Gautam Kumar Maurya (GKM)

Gautam Kumar Maurya — Wed, 27 May 2026 02:21:20 +0000

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)

OpenSource #Wikimedia #GitLab #Gerrit #CI_CD #SoftwareEngineering #OpenSourceContribution #DataScience #Engineering #GKM #GautamKumarMaurya

DEV Community: Gautam Kumar Maurya

From Knowing Nothing About Gerrit to Becoming a WikiClub Tech Envoy: My 9-Month Road to Wiki Journey

The story I never planned

1. Before the first patch, there was a lot I did not know

2. The Developer Playbook that changed everything

3. My first patch merged in just 3–4 days

4. From one patch to exploring the Wikimedia ecosystem

What I learned from actual contributions

5. The recognition that gave me another reason to work harder

The T-shirt moment

6. Even during my internship in Bangkok, the journey continued

7. The gkm563 identity: from learning contributor to a recognizable presence

8. The numbers matter, but the learning matters more

9. The road from Best Contributor to campus leadership

10. The final chapter of Cohort 2: Gurugram, 2–4 October 2026

The Vande Bharat journey

Meeting people beyond the screen

Day 1: Welcome, connection, and robotics

Day 2: Technology, Robo War, and recognition

Day 3: Goodbyes and the journey back

11. What I want to carry forward

Acknowledgements

The road continues

Read the journey through my posts and contribution records

Personal records

Technical contributions

LinkedIn posts documenting the journey

RoadToWiki #WikiClubTechIndia #Wikimedia #OpenSource #MediaWiki #DeveloperCommunity #GautamKumarMaurya #GKM563

From Zero to Wikimedia: An Engineering Blueprint for Open-Source Contributions and MediaWiki Development

From Zero to Wikimedia: An Engineering Blueprint for Open-Source Contributions and MediaWiki Development

Executive Summary: Redefining Open-Source Integration

Architectural Framework: Road to Wiki Cohort 2

Program Parameters & Technical Scope:

Technical Onboarding: Infrastructure and System Training

1. Environment Configuration and Authentication

2. Systematic Technical Analysis: Video Track Audits

3. Upstream Deployment Pipeline

Portfolio of Technical Contributions

1. Gerrit Code Review (MediaWiki Core & Extensions)

2. GitLab Pipeline (Function Orchestrator / Abstract Wikipedia)

3. GitHub Automation (Tooling Ecosystem)

Code Review Optimization and Engineering Resilience

Mentorship Ecosystem and Technical Leadership

Organizational Gratitude

Mentor & Senior Reviewer Acknowledgment

Community Acknowledgement

Documented Outcomes and Milestones

Engineering Governance: Core Implementation Principles

Future Trajectory

Technical Profiles and Portfolio References

From Engineering Student to Cyber Investigator: My 12-Day Journey at APCSIP-2026 Gautam Kumar Maurya (GKM)

How OSINT, malware sandboxes, UPI fraud trails, dark web recon, and 45+ mentors and co-interns turned a government internship into the most intense classroom of my engineering life

Why I Applied

Phase 1: The Selection Journey

Application Submission — May 2026

Shortlisted for Screening — 21–22 May 2026

The Online Screening Test — 24 May 2026, 6:00–6:30 PM

Offer Letter — Early June 2026

Onboarding — June 2026

Arrival at Amroha — 10 June 2026

DAY 00 — Welcome: Registration & Orientation

DAY 01 — Cell Briefing: Inside the Cybercrime Ecosystem

DAY 02 — Recon & OSINT: Reading People and the Internet

DAY 03 — Telecom Sorting: Law, Research, and AI

DAY 04 — Triangulation: Malware and the Forensics Pipeline

DAY 05 — IP Analysis: SOC, Threat Intel & Bug Bounty

DAY 06 — Mobile Forensics: Compliance & Industry Reality

DAY 07 — Vulnerabilities: Blockchain and Real Police Cases

DAY 08 — Financial Fraud: UPI, Privacy Law, and a Confidential Session

DAY 09 — Social Media: Offensive Security & the Dark Web

DAY 10 — Dark Web: Malware Forensics and the Best Content Creator Recognition

DAY 11 — Case Simulation: Chain of Custody, Hygiene & Yoga Day

DAY 12 — Review Panel: Presentation, Certification, and DSP Anjali Kataria Ma'am

Honors & Recognition

The People Behind the Program

A Journey of Growth: 13 Days in Amroha

What I Actually Took Away

Advice for Future APCSIP Applicants

Final Thoughts

Frequently Asked Questions

7. The `gkm563` identity: from learning contributor to a recognizable presence