Introduction

I am Vicky Sharma, a first-year Mathematics undergraduate at Delhi University with a deep focus on applied machine learning and computer vision. Before entering the open-source research world, I founded Pragati.ip an ed-tech startup where I built AI-powered learning systems that adapted to individual student needs in real-time.

In May 2026, I got selected for Google Summer of Code 2026 with the Weecology Lab at University of Florida to work on recovering historical bird annotations from corrupted aerial imagery using computer vision and deep learning.

This post covers everything before the coding phase how I chose the organization, built a working prototype, contributed to DeepForest, went through multiple discussion calls with mentors , and ultimately got selected for one of the most research-heavy projects in GSoC 2026. This series will document that entire journey.

Why This Organization and Project

I didn't stumble upon Weecology. I filtered through dozens of organizations methodically shortlisting sub-orgs, reading every project idea, checking GitHub activity, community health, Discipline in the org, mentor responsiveness. Most orgs had projects that were either too vague or too straightforward.

Weecology was different.

Why Weecology Stood Out

Before even applying, I reached out to a past DeepForest contributor. What came back wasn't the usual "yeah it was fine" it was genuinely positive. They talked about how invested the mentors were, how the codebase was well-structured, how the research actually mattered beyond the summer.

That conversation settled it for me.

The org had everything I was looking for strong mentorship, active research, well-maintained codebase, and a team that clearly valued contributor growth.

Why This Specific Project

Our mentors said something during our first meeting that stuck with me:

"This is not a project you can upload to AI and get a solution in a week."

That was exactly what I needed to hear.

In a world where most engineering problems have an AI shortcut, this project is a direct answer to the question: "What makes a human engineer irreplaceable? How are we diffrent from Ai?"

Recovering 340,000+ corrupted bird annotations from historical aerial imagery isn't something you prompt your way through. It requires understanding the data deeply, designing experiments, failing repeatedly, documenting those failures, and iterating with domain expertise, research methodology, and engineering judgment working together.

No shortcut exists. You have to actually think.

Why It's Right for My Growth

I wasn't looking for a comfortable project. I wanted something that would:

• Push me into research methodology I'd never practiced

• Force me to design systems from scratch, not extend existing ones

• Give me mentorship from people publishing actual papers

• Build skills that compound computer vision, ecological data, large-scale pipelines

This project does all four.

And honestly? The fact that it scared me a little was the clearest signal I was making the right choice.

Contributions, Communication,

and My Proposal

I started by reading the README, documentation, and contribution guidelines cover to cover. I also studied pull requests from past GSoC contributors not to copy their code, but to understand how DeepForest expected contributions to be structured.

My first few PRs were intentionally small: correcting a GitHub Actions hash that was causing workflow failures, adding missing authentication documentation for HuggingFace tokens , fixing broken links in the docs. Nothing flashy, but it taught me the mechanics how to fork, commit, handle pre-commit checks, write clean PR descriptions.

Then I moved to actual code contributions. My first real PR didn't include test cases. I genuinely didn't know they were expected. Henry's feedback was direct: "We aim for >80% coverage." I spent three days learning pytest, wrote the tests, and got the PR merged. That single review taught me more about production code standards than any tutorial.

Some PRs were straightforward adding regression tests for edge cases, exposing config parameters that were previously hardcoded. Others turned into multi-week debugging sessions. PR #1298 took three months and 33 comment threads. The problem was subtle: validation recall looked artificially low when limit_val_batches was set, because the metric compared predictions from 10% of images against ground truth from 100%. My first two attempts missed edge cases. Josh kept pushing me to think harder about multi-GPU environments, about where the logic actually belonged (spoiler: in the metric itself, not in main.py), about writing tests that would genuinely fail on broken code.

By the time that PR merged, I understood DeepForest's evaluation pipeline better than most of the documentation explained it. In the end i had total 8 merged pr's total 11 pr's in the org before results.

---

Building the Prototype

Contributing to existing code is one thing. Proposing something completely new is different.

After my initial PRs were merged, I reached out to Ben Weinstein with a direct question: "The corrupted bird survey dataset is SIFT homography + HSV detection a viable approach?"

I didn't ask "how do I contribute?" or "what should I work on?" I came with a specific technical hypothesis and asked if it was worth pursuing.

His response came in 8 hours. Not "try it and see" but "Here are the accuracy thresholds that would make this useful. Here's what we'd need for the data to be trainable."

That clarity let me move fast.

I downloaded the actual corrupted dataset from the S3 bucket 18,304 screenshots, 49,204 rows of metadata. Before writing a single line of pipeline code, I spent two weeks just analyzing the data. I measured dot diameters (8.0px median), identified annotation colors (6 distinct hues), calculated circularity scores (0.57 mean). Every parameter I'd need for detection, I derived from the data itself, not guessed.

Then I built the prototype. Six approaches failed before one worked. OCR on the dialog boxes? 4-15% precision. Narrow HSV color bins? 44% accuracy. Text watermark filtering? Accidentally removed real bird dots because birds sitting in colony rows looked like text to the algorithm.

The breakthrough came from widening the HSV bins and using SIFT-only mapping for training data. That combination hit 70.8% detection accuracy with 98.3% precision.

I documented every failure in a learnings.md file. Not to pad my proposal, but because research is supposed to be reproducible. If someone else tries this approach in five years, they shouldn't waste time repeating my dead ends.

Have a look to Prototype : Deepforest-bird-recovery-prototype

---

Communicating with Mentors

My communication process with the mentors was very different from the usual “constant interaction during development” approach. Most of the prototype work was something I built independently on my own before the major mentor discussions even started.

After submitting my proposal and building the prototype, the organization scheduled multiple calls with me to deeply discuss everything the prototype, proposal, technical decisions, pull requests, implementation details, limitations, and my overall understanding of the project.

Those conversations were intense and honestly quite nerve-wracking for me because most of the competition came from Master’s students and research-oriented contributors, while I was just a first-year undergraduate student from a non-traditional background.

The mentors asked me to explain:

• why I chose certain approaches,

• how the prototype worked internally,

• what tradeoffs I encountered,

• how I handled failures,

• the reasoning behind my proposal timeline,

• and even details from my PRs and experiments.

Since I had built the prototype myself, I was able to explain not just what worked, but also what failed and why. A large part of those discussions became less about memorized answers and more about demonstrating my actual thought process while building the system.

I was definitely nervous before the results because I knew the selection pool was extremely competitive. But those calls also gave me confidence that the mentors genuinely cared about technical depth, problem-solving ability, and research thinking.

---

The Proposal

I treated the proposal like a research paper, not a project pitch.

Structure: Abstract → Background → Technical Approach → Preliminary Results → Timeline → Deliverables → Risk Analysis → References

What made it different: I didn't propose hypothetical solutions. I included actual code snippets from the working prototype, performance benchmarks on real data, and a comparative analysis of failed approaches. I cited 15 research papers I'd studied.

The proposal didn't say "I will achieve 70% accuracy." It said "Based on prototype results (70.8% on 30 test images), I project 65-75% recovery rate on the full 18,304 dataset, yielding 220K-255K usable annotations." Data-driven projections, not aspirations.

And I kept contributing after submission. Three more PRs merged between proposal deadline and selection announcement. I was already invested in making DeepForest better.

When the selection email came, it wasn't a surprise. It felt like a continuation.Even after the all of this an giving my best, I was extremely nervous before the final results. Most of the applicant pool came from research-heavy backgrounds and Master’s programs, so it was hard not to feel intimidated as a first-year undergraduate. But at the same time, those discussions reassured me that the mentors valued depth of thinking, experimentation, and problem-solving ability more than credentials alone.

More information about my project https://summerofcode.withgoogle.com/myprojects/details/Hvyi10NT

The Team

Organization: Weecology Lab, University of Florida
Project: Recovering Computer Vision Annotations from Historical Airborne Imagery for Biodiversity Monitoring

My Mentors:

• Dr. Ben Weinstein (@bw4sz) , Henry Senyondo (@henrysenyondo), Dr. Ethan White (@ethanwhite) , Dr. Josh Veitch-Michaelis (@jveitchmichaelis)

#google-summer-of-code#gsoc#gsoc2025#github#deepforest#ai-agents#opensource#open-source-beginners-guide#open-source-contribution