DEV Community: Gautam Kumar Maurya

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