Before Writing Code, I Reviewed 104 Pull Requests
My Community Bonding Journey as a GSoC 2026 Contributor for WebiU
Sometimes the most important code you write during GSoC isn't written during GSoC at all.
When people think about Google Summer of Code, they usually imagine coding.
Building features.
Opening pull requests.
Writing thousands of lines of code.
Getting things merged.
I thought the same.
Then my GSoC journey started with something completely different.
Reviewing 104 pull requests.
Not writing them.
Reviewing them.
And honestly...
I didn't expect that experience to completely change how I think about software engineering.
From Contributor to GSoC Contributor
A few months ago, I was just another contributor trying to understand an unfamiliar codebase.
WebiU, the project I now work on under Google Summer of Code 2026, is an open-source platform developed by C2SI to showcase repositories, contributors, projects, research work, publications, and community activity.
Like most contributors, I started small.
A few issues.
A few pull requests.
A few discussions.
Then more discussions.
Then architectural discussions.
Then feature planning.
Then roadmap discussions.
And somehow...
Before I realized it, I had become deeply involved in the project.
By the time proposal season arrived, I wasn't proposing random ideas anymore.
I was proposing solutions to problems I had already experienced firsthand.
Problems like:
- GitHub API rate limits
- Slow request-time data fetching
- Scalability bottlenecks
- Missing persistence layers
- Future infrastructure concerns
- Long-term maintainability
The proposal I eventually submitted focused on transforming WebiU from a request-driven GitHub data platform into an event-driven repository intelligence system.
At that point, it sounded ambitious.
What happened next was even more interesting.
The 104 Pull Request Audit
During Community Bonding, one of the first major tasks wasn't coding.
It was auditing pull requests.
A lot of them.
104 open pull requests.
Damnnn.
That number sounds much smaller until you actually start reviewing them.
Some were active.
Some were outdated.
Some solved issues that no longer existed.
Some duplicated each other.
Some conflicted with the future direction of the project.
And some were genuinely good contributions that had simply been sitting there waiting for attention.
The challenge wasn't technical.
The challenge was human.
Every pull request represented somebody's effort.
Someone had spent hours.
Maybe days.
Maybe weeks.
Trying to contribute.
Closing a pull request suddenly feels very different when you realize there's a real person on the other side of it.
For the first time, I experienced open source from the maintainer's perspective instead of the contributor's.
And that perspective changes everything.
The Funny Side of Open Source
Not every review was serious.
Thankfully.
Because after reading pull request number 63, your brain starts asking difficult questions like:
"Why am I doing this to myself?"
XD
One of my favorite moments was opening a pull request discussion expecting serious implementation reasoning...
...only to find random laughing reactions in the middle of a completely serious technical conversation.
There we were discussing architecture decisions...
And somebody was apparently having the time of their life.
Those little moments remind you that behind every GitHub profile is an actual human being.
Open source communities are built by people.
Not repositories.
What Reviewing 104 Pull Requests Actually Teaches You
Reviewing code teaches lessons that writing code never will.
As contributors, we mostly see our own work.
As reviewers, we see everybody's work.
Different coding styles.
Different problem-solving approaches.
Different levels of experience.
Different interpretations of the same issue.
You start noticing patterns.
You start seeing why maintainers ask for seemingly "small" changes.
You begin understanding how tiny implementation details can become future technical debt.
Most importantly, you start appreciating how difficult maintaining a project actually is.
After reviewing that many pull requests, I became significantly more careful when creating my own.
Because now I understood what reviewers see.
Conversations That Changed The Project
Once the pull request audit was largely complete, Community Bonding shifted into something else.
Conversations.
Lots of conversations.
Google Meets.
Slack threads.
GitHub discussions.
Private architecture reviews.
Roadmap planning sessions.
Shoutout to Mahendra Bhaiya and Utkarsh Bhaiya here.
One thing I genuinely appreciated was how direct and practical every discussion was.
Nobody cared about fancy architecture diagrams.
Nobody cared about buzzwords.
Nobody cared about building something that simply looked impressive.
Everybody cared about one thing:
Building something that would actually work.
And that mindset changed how I viewed my own proposal.
The Proposal Was Just The Beginning
When I originally wrote my proposal, I focused heavily on architecture.
Webhooks.
Event-driven systems.
Background workers.
Caching.
Repository intelligence.
Persistent storage.
Queue-based processing.
All the fun distributed systems stuff.
The proposal aimed to move WebiU away from this:
Frontend
↓
Backend
↓
GitHub API
And toward this:
GitHub Events
↓
Webhook Layer
↓
Queue
↓
Workers
↓
Database
↓
Cache
↓
Frontend
At the time, it felt like the perfect plan.
Then mentor discussions began.
And oooh boy...
The proposal started getting challenged.
In a good way.
The people helping select the proposal were often the same people questioning parts of it the hardest.
Looking back, many of our meetings felt less like mentor meetings and more like architecture review boards.
And honestly?
That's exactly how it should be.
Nobody cared about protecting the proposal.
Everybody cared about improving the project.
Defining The Real P0 Priorities
One lesson became obvious very quickly.
Successful projects are not built by solving every problem.
They are built by solving the right problems first.
Together, we started identifying the actual P0 priorities.
The things that absolutely had to be done before anything else.
1. Deployment Strategy
Before building features, we needed deployment clarity.
Where does the frontend live?
Where does the backend live?
How do we keep costs low?
How do we keep maintenance manageable?
Turns out deployment decisions affect architecture far more than most people realize.
2. Long-Term Cache Strategy
Caching sounds simple until you have to maintain it.
Then suddenly you're discussing:
- Cache invalidation
- Data freshness
- Expiration policies
- GitHub API limits
- Future scalability
And you realize there are entire careers built around solving these problems.
3. GitHub API Dependency
One of the biggest architectural concerns was reducing dependency on live GitHub API requests.
Every design discussion eventually came back to the same question:
How do we serve more data while making fewer GitHub requests?
That question influenced nearly every major decision.
4. Commitments To Project Leadership
This was probably one of the most eye-opening discussions.
Mentors don't just build features.
They are accountable for outcomes.
They make commitments.
They manage expectations.
They balance technical decisions against practical constraints.
Understanding that changed how I approached every discussion moving forward.
The Maintainer Access Moment
At some point, I noticed something unusual.
I wasn't only contributing anymore.
I was helping review work.
Helping make decisions.
Helping plan execution.
Helping close pull requests.
Helping shape project direction.
That's a level of trust I don't take lightly.
Because every merge.
Every review.
Every approval.
Every decision.
Eventually affects somebody else.
And that's a responsibility worth taking seriously.
Building The Roadmap
Once priorities became clear, I started planning the implementation roadmap.
One thing reviewing 104 pull requests taught me is this:
Large pull requests are painful.
Painful to review.
Painful to test.
Painful to merge.
Painful to maintain.
So instead of building everything at once, we broke the project down into focused phases.
- Infrastructure Cleanup
- Authentication Foundation
- Deployment Preparation
- Backend Improvements
- Admin Features
- Webhook Foundations
- Repository Intelligence Systems
Each PR would have a single responsibility.
Each merge would move the project one step forward.
Simple.
Predictable.
Reviewable.
Maintainable.
Accountability
One message from GSoC's Community Bonding period stuck with me.
Mentors guide.
Contributors execute.
The responsibility ultimately belongs to the contributor.
And honestly, I think that's one of the best lessons GSoC teaches.
So I've been documenting everything.
Meeting notes.
Decisions.
Roadmaps.
Discussions.
Trade-offs.
Reasoning.
Not because anyone asked me to.
Because future contributors deserve context.
And because six months later, nobody remembers why a decision was made unless somebody writes it down.
What Comes Next
The funny thing is...
The coding phase has barely started.
The audits are done.
The architecture discussions are done.
The deployment direction is mostly finalized.
The priorities are clear.
Now comes the difficult part.
Execution.
Over the next few months, the goal is to transform WebiU into something faster, more scalable, easier to maintain, and less dependent on request-time GitHub API calls.
But regardless of what gets built next, one lesson will stay with me.
Open source isn't just about code.
It's about responsibility.
Responsibility toward contributors.
Responsibility toward maintainers.
Responsibility toward the people who trust your decisions.
And somehow...
That lesson started with reviewing 104 pull requests.
A Small Surprise
Over the last few weeks, quite a few people have messaged me asking questions like:
- How did you write your proposal?
- How detailed was it?
- What architecture did you propose?
- What actually gets someone selected?
And honestly...
When I was applying, I had the exact same questions.
I remember spending hours searching for accepted proposals, architecture documents, timelines, and implementation plans.
So instead of gatekeeping it, let's do the opposite.
Here's the exact proposal that got me selected for Google Summer of Code 2026.
Read it.
Critique it.
Learn from it.
Improve upon it.
Disagree with it.
That's how engineering gets better.
Proposal
https://drive.google.com/drive/folders/1xY4t65HgWwPl6TlEChYB4cvcGIL7i2eQ?usp=sharing
Just remember:
The proposal got me selected.
The real work started after that.
:)
Let's Connect
If you're interested in:
- Google Summer of Code
- Open Source
- Angular
- NestJS
- System Design
- Distributed Systems
- Building in Public
Feel free to reach out.
GitHub
https://github.com/TarunyaProgrammer
https://linkedin.com/in/tarunyakesharwani
Portfolio
https://tarunyaportfolio.vercel.app
DEV.to
I'm always happy to discuss open source, review ideas, exchange feedback, or just talk about building things on the internet.
And if you're contributing to WebiU...
There's a decent chance I've already broken the thing you're trying to fix.
XD
Top comments (1)
excited to see new contribtors subsequent year XOXO