DEV Community: Akanksha Trehun

Week 2: Pull Requests, Rejected Code, and the Art of Not Breaking Things

Akanksha Trehun — Sat, 13 Jun 2026 15:53:27 +0000

GSoC 2026 | CircuitVerse × Canvas LMS LTI 1.3 Integration

If Week 1 was about getting familiar with the codebase and understanding what needed to be built, Week 2 was about learning the hard way that writing code is only half the job. The other half — the messier, more humbling half — is getting that code accepted by the people who actually maintain the project.

This week was full of detours, rejected pull requests, reviewer feedback that stung a little, and a surprisingly frustrating fight with a two-letter word in Ruby. But by the end of it, I had something real to show: a clean, reviewed, and submitted change to CircuitVerse that lays the foundation for the entire LTI 1.3 integration. Let me walk you through it.

A Quick Refresher: What Are We Building?

CircuitVerse is an open-source platform where students can build and simulate digital circuits right in their browser. The project I'm working on aims to connect CircuitVerse with Canvas, one of the most widely used Learning Management Systems (LMS) in universities around the world.

The technology that makes this connection possible is called LTI — Learning Tools Interoperability. Think of it as a universal plug that lets any educational tool (like CircuitVerse) slot into any LMS (like Canvas) so that students can log in once, get assignments, submit work, and have their grades flow back automatically — all without leaving their course page.

There are two versions of this plug: LTI 1.1, which is old and uses a simpler (but outdated) security mechanism, and LTI 1.3, which is newer, more secure, and what Canvas actually recommends today. My job is to bring CircuitVerse fully up to LTI 1.3 standards.

Monday–Tuesday: A Pull Request That Taught Me to Read Diffs

I started the week with what I thought was a solid pull request (PR) — a fix for a bug in CircuitVerse's existing LTI 1.1 grade passback feature. "Grade passback" is the process where CircuitVerse sends a student's score back to Canvas after they complete an assignment.

My PR got reviewed, and the reviewer left two comments that immediately made me wince:

Comment 1: "It seems that the whole schema is sorted. This issue has been fixed upstream."

Translation: I had accidentally included a massive, unrelated change to a file called schema.rb — a file that describes the structure of CircuitVerse's database. When I ran a command to regenerate this file on my laptop, a newer version of the Rails framework (the toolkit CircuitVerse is built on) quietly reordered every single database column alphabetically. This produced a diff with hundreds of changed lines — none of which were related to my actual fix. The reviewer spotted it immediately.

Comment 2: "You are downgrading gem version here."

Translation: I had accidentally rolled back a security upgrade. CircuitVerse uses a library called jwt (JSON Web Tokens — a way to securely verify identity online) that had recently been upgraded from version 2.x to 3.x. My branch had unknowingly reverted it to the older version because of a chain reaction: another library I'd updated (webpush, used for browser notifications) happened to be incompatible with jwt 3.x, pulling the version back down without me realising.

The Fix: I had to undo the schema changes by restoring the file to exactly what the main CircuitVerse codebase had, restore jwt to version 3.2.0, and also downgrade webpush back to the version that didn't cause the conflict. Three files. Careful surgery with git commands. Then push the corrected version, re-commit, and update the PR.

This taught me something I'll carry for the rest of the summer: always check your diff before opening a pull request. A diff is the list of everything your code changes compared to the original. If anything looks unfamiliar or unexpected, it probably shouldn't be there.

Wednesday: The PR I Had to Close

After fixing those issues and updating the pull request, I got some harder news: the PR had to be closed. The grade passback code I'd written depended on an old library (ims-lti) that used LTI 1.1's way of doing things — OAuth 1.0, an older form of authentication. The problem was that several other files in the project also depended on that same library, and changing it was causing things to break in places I hadn't touched.

It felt frustrating. But my mentor pointed me in the right direction: before fixing the grade passback flow, I needed to first upgrade the underlying library itself. That meant replacing ims-lti with something modern that could handle LTI 1.3 properly.

Wednesday–Thursday: Reviewing Someone Else's Pull Request

While I regrouped, I was asked to review another PR that had been submitted — a Dependabot update (an automated tool that suggests library upgrades) proposing to bump ims-lti from version 1.2.9 to 2.3.7.

This was a useful exercise. Looking at what changed between the two versions, I spotted that:

The 2.x version had removed support for the OAuth library entirely — the same one that LtiScoreSubmission (the grade passback code) depended on
A class called IMS::LTI::ToolProvider, which is what the controller uses to verify a student's identity when they launch CircuitVerse from Canvas, simply doesn't exist in 2.x

Merging this PR would have silently broken every LTI launch and every grade submission. I wrote up a review explaining this and recommended the PR be held until the LTI code was properly migrated to 1.3. The PR was not merged.

Reviewing other people's code with a critical eye is a skill in itself, and this was good practice.

Thursday: Syncing With the Main Codebase (A Surprisingly Tricky Task)

Before writing any new code, I needed to make sure my local copy of CircuitVerse was up to date with the changes the main team had been making. This process is called "fetching upstream" — pulling in changes from the official CircuitVerse repository.

It should have been simple. It wasn't.

Git (the tool developers use to track code changes) threw an error about corrupted branch references — essentially, some branch names in the CircuitVerse repository contained spaces in their names, which git wasn't expecting. These bad references were blocking the entire fetch operation.

The fix involved tracking down these broken references, deleting them, and then fetching again. Once that worked, I had a new problem: a merge conflict. The main codebase had changed the jwt library version (to 3.2.0), while my local copy still had the older pin (2.10.3). Git didn't know which one to keep, so it stopped and asked me to decide.

I chose the upstream version (3.2.0) — the right call, since that's the one the maintainers had intentionally upgraded to. I also removed a manually-added entry for a library called faraday (used for making HTTP requests) since it was already included indirectly through other libraries and didn't need to be declared explicitly.

There was also a leftover reference to a submodule (a separate mini-repository embedded inside CircuitVerse) that I'd already removed in an earlier session. The merge picked it back up; I removed it again. After all of that, the sync was complete.

Friday: Finding the Right Gem — A Detective Story

With the codebase up to date, it was time to research the actual replacement for ims-lti. The library I'd been asked to migrate to is called lti_advantage.

Here's where it got interesting. There are two different things with very similar names:

lti_advantage (version 0.0.3) — published on RubyGems (the standard place Ruby libraries are shared), authored by an individual developer, with no publicly accessible source code and almost no documentation.
lti-advantage (version 0.1.0) — embedded directly inside Canvas LMS's own codebase, maintained by Instructure (the company that builds Canvas), with full source code, tests, and comments linking to the official LTI standards.

Since the entire point of this integration is to work with Canvas, using the library that Canvas itself uses was clearly the right call. The Canvas version is battle-tested, actively maintained, and built to the exact same LTI 1.3 specification we're implementing.

I updated the Gemfile (the file that lists all libraries a Ruby application depends on) to point to Canvas's version of the gem, directly from the Canvas GitHub repository.

Friday Evening: The Two-Letter Word That Cost Me an Hour

After setting up the Gemfile, I ran a quick test to verify the library had loaded correctly. Instead of a confirmation, I got a wall of red error text.

The culprit? The word it.

In Ruby 3.4 (released late 2023), it was introduced as a new shorthand inside code blocks — a way to refer to the current item being processed without naming it explicitly. The Canvas team had adopted this syntax in their codebase.

But CircuitVerse runs on Ruby 3.2.2. In that version, it isn't a special keyword — it's just an undefined method name. So when the library tried to load, Ruby 3.2.2 hit the word it and said: "I have no idea what this is."

The solution was to find the specific point in Canvas's git history just before this syntax was introduced — a commit from March 2025, before the Canvas team upgraded their Rubocop linting tool to support Ruby 3.4 style. By pinning our Gemfile to that specific historical commit, we get the full functionality of the library without the Ruby version incompatibility.

After making that change, the verification check finally printed what I needed to see:

0.1.0
LtiAdvantage::Messages::ResourceLinkRequest

The library was in, working, and ready.

Wrapping Up: 793 Tests, 0 Failures

With the new library loaded, the last step was making sure I hadn't accidentally broken anything else in the process. I ran CircuitVerse's full test suite — 793 individual automated tests covering models, controllers, API endpoints, background jobs, and more.

793 examples, 0 failures.

Every part of the existing application still worked exactly as before. The only test excluded from this run was the one specifically for LTI — which I already knew would fail, because it still references the old library. Rewriting that test is part of next week's work.

I created a clean pull request with a single, focused commit describing exactly what changed and why, linked it to the issue (#7509) I'd opened for the work, and submitted it.

What I Learned This Week

Read your diffs. Every line in a pull request should be there intentionally. Unexpected changes are usually a sign something went wrong.
Library upgrades are never just library upgrades. Every dependency has dependencies of its own, and changing one can quietly shift others.
Reviewing code is as valuable as writing it. Catching a breaking change before it merges is just as important as shipping a feature.
Version numbers matter — down to the commit. Pinning a library to a specific historical commit felt overly cautious at first, but it was the only correct solution given the Ruby version gap.
A clean pull request with one clear purpose is worth far more than a large one with many. My first PR of the week was rejected partly because it accidentally carried in unrelated changes. The PR at the end of the week had exactly one commit, one purpose, and zero noise.

Next week: I start the actual code migration — replacing the old LTI 1.1 authentication logic with the new lti-advantage library's APIs, rewriting the tests, and wiring up the full OIDC launch flow that Canvas LTI 1.3 requires.

The foundation is set. Time to build.

GSoC 2026 · Week 1 — What Happens When a Student Clicks "Open Assignment"?

Akanksha Trehun — Sat, 06 Jun 2026 17:46:44 +0000

Testing the LMS–LTI integration in CircuitVerse

A behind-the-scenes look at debugging a silent integration — and what it taught me about the gap between code that exists and code that works.

Project: CircuitVerse · Week: 1 · Focus: Testing & fixing the LMS–LTI assignment workflow

TL;DR

In my first week, I tested the full LMS–LTI flow end to end — a student opening an assignment from Canvas, building a circuit in CircuitVerse, and a teacher grading it back in Canvas. On the surface the feature looked complete. In reality, four interconnected bugs were silently breaking the handoff. Here's how I found and fixed each one.

#	Symptom	Root cause	Fix
1	Student hit a login page	Session was never established after launch	Add `sign_in(@user)`
2	Student landed on the wrong page	Redirect pointed at the group home, not the project	Redirect to `user_project_path`
3	Teacher couldn't grade	Grading form hidden until deadline passes	Allow past deadlines for testing
4	Grade showed `0` in Canvas	Feature flag off, missing LTI session, `maxPoints = 0`	Enable flag, launch via Canvas, set max points

First, some context: what is LMS–LTI?

LMS stands for Learning Management System — the software your university uses to manage courses, post assignments, and track grades. Canvas, Moodle, Google Classroom, and Blackboard are all examples.

LTI stands for Learning Tools Interoperability — an industry standard that lets an LMS talk to an external tool like CircuitVerse, so students don't need separate accounts or a second login. In theory:

A student clicks a link inside Canvas and is transported directly into CircuitVerse, identity already known.
The teacher grades the work from Canvas.
The score flows back automatically.

In practice, making that seamless handoff actually work is where things get interesting.

Setting up the test

Before any real testing could happen, I needed two systems running side by side and talking to each other. So I set up:

A local Canvas instance and a local CircuitVerse instance.
A test course in Canvas, with a test student and a test teacher enrolled.
An LTI assignment configured to point at CircuitVerse.

With everything in place, I logged in as the student and clicked the assignment link.

Bug 1: the student ended up on the login page

The first screenshot told the whole story. Instead of landing in CircuitVerse on the assignment, the student was redirected to /users/sign_in — CircuitVerse's standard login page.

The LTI handoff itself had worked. Canvas had sent all the right information to CircuitVerse:

Who the student was
Which course they were in
Which assignment they were opening

CircuitVerse read that information, found the matching user, and even created a blank project for the student to fill in. But it never told CircuitVerse's authentication system that the student was now logged in.

Think of it like a hotel. The front desk checked your reservation, confirmed your identity, and handed you a room key — but forgot to actually activate the key. Every door you try still says "access denied."

The fix was a single line in the code that handles student LTI launches:

sign_in(@user)

Adding this before showing the student their assignment established the session properly. After this fix, the student landed authenticated and ready.

Bug 2: the student landed on the wrong page

With authentication fixed, the student was now signed in — but being sent to a course overview page with no obvious path to their actual assignment. The intermediate "please wait" page CircuitVerse shows during the handoff was opening a new browser tab pointing at the group's home page, not the student's specific work.

The fix was conceptually simple: redirect the student straight to the project that was auto-created for them during the launch.

# Before: took the student to the course home page
group_path(@group)

# After: takes the student straight to their project
user_project_path(@user, @project)

Now when the student's browser opens the new tab, they land on their own project page with a clear "Launch Simulator" button waiting for them.

Bug 3: the teacher could not grade

With the student flow working, I switched to the teacher's perspective. The teacher launches the same LTI assignment from Canvas, lands on the assignment management page, and can see the student's submission — the circuit they built — in a preview panel.

But there was no grading form. Nowhere to enter a score.

This one required reading the code rather than guessing. The grading form is deliberately hidden until the assignment's deadline has passed:

def can_be_graded?
  mentor_access? && assignment.graded? && (assignment.deadline - Time.current).negative?
end

The last condition — negative? — means the deadline must be in the past. My test assignment had a deadline set a week in the future.

The logic makes sense for real classrooms: you don't want teachers accidentally grading before students have finished submitting.

There was also a secondary problem: the date picker on the assignment edit form had a minDate restriction that prevented selecting any past date — so even if you knew the workaround, the UI would reset your choice.

Both restrictions were removed for the editing flow, allowing a past deadline for testing. Once the deadline was in the past, the grading form appeared immediately.

Bug 4: the grade did not appear in Canvas

This was the most layered problem of the four, and the most instructive.

After the teacher submitted a grade of 68 in CircuitVerse, I went to the Canvas gradebook expecting to see 68. Instead, it showed 0.

A grade of zero when you entered 68 is never a simple problem.

I pulled the Rails server logs to see exactly what happened on submission:

POST "/grades"
Parameters: {"grade"=>{"project_id"=>"15", "assignment_id"=>"19",
             "grade"=>"68", "remarks"=>"average"}}
...
Completed 200 OK

The grade was saved successfully in CircuitVerse — but there was no outgoing HTTP request to Canvas anywhere in the log. The code that should have sent the grade back was never reached.

Three conditions had to be true simultaneously for the grade passback to fire:

A feature flag called lms_integration had to be enabled. CircuitVerse uses feature flags to toggle capabilities without deploying new code. This one was off by default. Running Flipper.enable(:lms_integration) in the server console switched it on.
The teacher had to have launched via Canvas LTI before grading. The passback code checks session[:is_lti] — a marker that says "this session started from an LTI launch." Logging into CircuitVerse directly never set it. The fix: always initiate grading from Canvas by clicking "Load LTI test in a new window."
The Canvas assignment had zero maximum points. LTI sends scores as a decimal between 0 and 1 — so 68 out of 100 becomes 0.68. Canvas multiplies that by the assignment's max points:

With max points 0 → 0.68 × 0 = 0
With max points 100 → 0.68 × 100 = 68 ✅

After resolving all three, the Canvas gradebook finally showed 68 out of 100 for the test student.

What made this hard

None of these bugs announced themselves loudly:

The server returned success codes.
Pages loaded.
No errors appeared on screen.

The student reached CircuitVerse — just not authenticated. The grade was saved — just not forwarded. The grading form existed in the code — just not rendered.

This is the particular difficulty of integration testing: two systems each behaving correctly on their own, but the handoff between them silently failing. The only way to catch it is to walk through the entire experience from beginning to end, as an actual user would.

The lesson is simple but easy to forget:

A feature is not done when the code is written. It is done when a real person can use it from start to finish without needing to know what is happening underneath.

The moment it worked

After all of the above, I went back to Canvas, clicked the LTI assignment as the teacher, entered a grade of 68, and reloaded the gradebook.

It showed 68 out of 100.

That number, small and unremarkable on its own, represented a complete round trip:

A student identity handed from Canvas to CircuitVerse
A circuit built and saved
A grade entered by a teacher
A score carried back to where the course lives

What's next

The workflow works. Now the real work begins — upgrading it from LTI 1.1 to the more secure and capable LTI 1.3.

Thanks for reading my Week 1 update. More to come as the LTI 1.3 migration gets underway. 🌸

Getting Selected — The Night I Couldn't Sleep

Akanksha Trehun — Tue, 12 May 2026 04:37:40 +0000

If you haven't read my previous post about the pre-GSoC journey the two months of contributing, the early mornings, the proposal drafts I'd suggest starting there. This post picks up right where that one ended: the proposal had been submitted, the deadline had passed, and there was nothing left to do but wait.

Waiting, as it turns out, is its own kind of difficult.

After the Submission

I hit submit at 11:20 PM on March 31st, ten minutes before the deadline. And then, almost immediately, the adrenaline wore off and a very different feeling took its place.

When you're in the middle of writing a proposal, you have something concrete to do:

Sections to draft
Diagrams to make
Timelines to think through
Drafts to improve

The work itself keeps the anxiety at a manageable level because you can always channel it into doing something. But the moment the submission is in and there's nothing more you can do to improve your chances, the anxiety has nowhere to go. It just sits there.

I kept contributing to CircuitVerse during the waiting period. Partly because I genuinely wanted to stay involved, and partly because it gave me something productive to do instead of refreshing my email. It was the right instinct. Staying active meant I was still:

Building context in the codebase
Building relationships in the community
Becoming a better contributor regardless of what the outcome would be

But I'm not going to pretend the nervousness wasn't real. It was. Every time I thought about the results, there was a knot of uncertainty that I couldn't quite reason away.

The Message on April 10th

On April 10th, I got a message from one of the mentors.

I had been shortlisted for an interview round.

I remember reading it twice, just to make sure I had understood correctly. Someone had read my proposal and thought it was worth having a conversation about. That felt significant, and it was.

It also meant a whole new category of nervousness had arrived. I had no idea what the interview would look like. Would it be:

Highly technical — testing my knowledge of the codebase in detail?
Proposal-focused — asking me to defend my timeline and technical approach?
Background-focused — asking about my prior contributions and understanding of the project history?

I didn't know, and not knowing made it hard to prepare efficiently. You can't study for an exam when you don't know what subjects it covers.

What I decided to do was prepare for everything.

Three to Four Days of Preparation

I had roughly three to four days between finding out about the interview and actually sitting down to do it. I used all of them.

Here's exactly what I covered:

Revisited the entire codebase — not just the parts I had contributed to, but the broader architecture: how the different components connected, what the data models looked like, how requests flowed through the system
Reviewed every contribution I had made since February — not just what the changes were, but why I had made them, what problem each one was solving, what I had learned in the process
Studied the project history — the previous year's proposals, what had been attempted before, why it hadn't been selected, what the mentors had said they were looking for
Prepared to be honest about Ruby on Rails — I was still not deeply comfortable with it. Two months of contributing gives you familiarity, but it doesn't make you an expert. I knew which parts I understood well and which parts I had been moving carefully around

Being honest about uncertainty is better than pretending to know something you don't especially when the people you're talking to know the codebase far better than you do.

All the mentors for my project were present in the interview. I found that out when I joined the call and saw all the names. The opening minutes were nerve-wracking. But once the conversation started, it felt less like an interrogation and more like a genuine discussion — which is, I think, exactly what a good technical interview is supposed to feel like.

I came out of it thinking I had done reasonably well. I wasn't certain, but I felt like I had represented my actual understanding accurately.

There Is a Second Round?

A few days later, I got another message.

I had cleared the first round. There would be a second interview — five days later.

My initial reaction was not pure excitement. It was something more complicated.

On one hand:

I had cleared the first round — the mentors thought the conversation went well enough to continue
That was genuinely good news

On the other hand:

I had assumed there would be one interview
Finding out there was a second one raised the stakes again
I had let myself feel like the hardest part was behind me — it wasn't

And then there was a very concrete problem: the day after the second interview, I had my compiler design lab exam.

I want to describe this dilemma accurately because I think it's the kind of thing that doesn't get talked about enough when people write about GSoC. The romanticised version of applying is that you pour everything into it and everything else makes way. The real version is that everything else doesn't make way at all.

College keeps happening:

Exams keep being scheduled
Assignments keep being due
Real consequences for your grade don't pause for GSoC

I spent a while genuinely unsure what to do. I couldn't do both properly. Something had to give.

I chose the interview.

I decided it was better to go into the interview focused than to spend the day before it with my attention split between two things. I crammed for the exam after the call. I don't know whether that was the optimal decision in terms of the exam result. But it was the decision I made, and I stand by it.

The Second Interview

I prepared for the second interview much as I had for the first:

Went back over my contributions
Reviewed the proposal thoroughly
Made sure I understood the technical details clearly enough to explain them under pressure

The conversation itself went well. What I'll say is that by the time it ended, I had a sense — not certainty, but a sense — that it had gone the way it needed to go. I had said what I thought, explained my approach clearly, and been honest about the boundaries of what I knew.

And then I waited again.

April 30th

I had been watching the clock on April 30th for most of the evening — not because I was actively anxious, but because I wanted to see it. The official thing. The acceptance letter in the profile. The Google stamp on it.

By the time 11:30 PM arrived, I was in bed, phone in hand, scrolling through Netflix trying to find something to watch. A completely ordinary end to an ordinary evening. I opened my GSoC profile, and there it was.

I cannot sleep when I am that happy. That is just a thing I have learned about myself.

I lay there for what felt like hours with my brain going at full speed — not anxious anymore, just overwhelmed in the best possible sense. I:

Texted people I probably shouldn't have texted at that hour
Sent voice notes
Called someone
Told everyone who was close to me

The next morning I wrote a long email to all my mentors. I thanked them properly, not just a quick reply for selecting me and for the conversations during the interview process, and I asked about the next steps. Writing that email felt important to do well. It was the beginning of a professional working relationship that was going to last at least three months, and I wanted to start it on the right note.

The Part Nobody Tells You About

There is something that happens after you get selected for GSoC that I don't think people talk about enough.

There is a brief period maybe a day or two where the excitement is so overwhelming that you feel like you could do anything. You are riding an enormous wave of:

Relief — months of uncertainty finally resolved
Happiness — the kind that makes you text people at midnight
Satisfaction — of having worked hard for something and actually gotten it

And then, slowly, the reality of what you've committed to starts to come into focus.

You have:

Twelve weeks of a coding period
A specific project with real deliverables
Mentors who are experienced, thoughtful people paying attention to your progress
A proposal with your name on it, full of specific claims about what you will accomplish and when

For me, that moment of reality arriving wasn't frightening — but it was sobering in a healthy way. It reminded me that getting selected is the beginning of the work, not the end of it.

The weeks of contributing in February and March, the early mornings, the proposal drafts — those were the audition. The coding period is the actual performance.

I found that realisation motivating rather than deflating, which I think is probably a good sign.

What I Believe About This Process

Looking back at everything — the two months of contributing, the early alarms, the proposal drafts, the two interview rounds, the waiting I want to say something honest about what the GSoC application process actually is.

It is not:

A competition for the most brilliant developers at the most prestigious universities
Something that requires a perfect academic record
Something that requires years of professional experience

What it actually requires:

Requirement	What it looks like in practice
Genuine interest in open source	Showing up even when no one is making you
Consistent effort	Contributing every day, even for something small
Clear communication	Asking questions, responding to feedback, being honest
Technical curiosity	Reading code you didn't write, understanding systems you didn't build

I was a sixth semester engineering student who had never written a line of Ruby before February of this year. I had no prior experience with the CircuitVerse codebase. I was balancing a full college schedule, internal exams, and assignments throughout the application period. None of that disqualified me.

The process also teaches you things that are genuinely valuable regardless of whether you get selected:

Reading a real production codebase is a skill you can only build by doing it
Writing a defensible technical proposal requires a kind of thinking most coursework never asks for
Building credibility through consistent small actions is a professional skill that transfers directly to the working world

If you are reading this as someone considering whether to apply next year and aren't sure whether you're ready: you probably are. Start contributing now, before the application period opens. The earlier you start, the more comfortable you will be, and the stronger your proposal will be.

The worst possible outcome is that you spend several months learning more than you expected and become a meaningful contributor to a real open source project. That is a genuinely good outcome.

The best outcome is an email that keeps you up all night too happy to sleep.

Next up: the community bonding period, meeting my mentors properly for the first time, and what the next twelve weeks actually look like.

Pre GSoC — Finding My Way to CircuitVerse

Akanksha Trehun — Wed, 06 May 2026 18:51:19 +0000

This post is going to be a long one. I figured if I'm going to write about the two months that led up to my GSoC selection, I should do it properly the whole thing, from the very beginning, not just the highlights. So grab a coffee, get comfortable, and let's go back to where this story actually starts.

A Classroom Demo I Never Forgot

The first time I heard the name CircuitVerse, I was sitting in a Digital Principles of Design class in my third semester. I'm currently in my sixth semester, so that's about a year and a half ago now. It wasn't a big moment. It wasn't even really part of the class.

Our faculty and I'm genuinely grateful to her for this had pulled up CircuitVerse on the projector one day just to show us something. It wasn't in the syllabus. It wasn't going to be on the exam. She just wanted us to see what it actually looked like when the circuits we were drawing on paper came to life on a screen. We were studying:

Half adders and full adders
JK flip flops
Foundational digital logic that you spend your first years drawing on paper or building with actual wires on a breadboard

She simulated a few circuits in front of us, walked us through how the inputs and outputs worked, showed us how you could change values and watch the circuit respond in real time. It was maybe twenty minutes of a single class period. And then we moved on.

But I remember thinking even then, as a third semester student still getting used to the pace of engineering college that this was a really interesting platform. There was something satisfying about seeing the logic work visually, in real time, without needing physical components. I didn't do anything with that thought at the time. I just filed it away somewhere.

That's where it started. One classroom demo that I technically didn't need to pay close attention to.

Why This Year

Fast forward to the beginning of this year. I'm in my sixth semester, roughly halfway through my degree, and I had been thinking about GSoC for a while not in a serious, planned out way, but in the background. I knew what it was. I knew it was something I wanted to try. I just hadn't pulled the trigger.

This year felt different. I had a feeling and I think a lot of students who've gone through this will understand it that if I kept waiting for the perfect time, the perfect time was never going to arrive. There is always:

An exam
A project due
Some reasonable-sounding reason to push it to next semester

And at some point, next semester becomes next year, and next year becomes too late.

I'm in sixth semester. If I didn't apply this year, I'd have my seventh and then my final eighth semester, and by then everything gets consumed by placements and final year projects. The window felt like right now, not later.

So when the 2026 GSoC organisations were announced and I saw CircuitVerse on the list, something clicked immediately. I already had that memory of it from third sem. I'd always had a genuine interest in circuits and digital logic it goes back further than that DPD class, actually, all the way to eleventh and twelfth grade in school, where I first encountered electronics properly. It was one of those subjects that made sense to me intuitively in a way that not everything does.

And I thought: I know what this platform is, I care about what it does, and I can try. So I did.

Starting From Zero

I want to be honest about where I was when I started contributing to CircuitVerse in February. I was not a well-prepared, experienced open source developer who had been waiting for the right organisation. I had contributed to a few other open source programmes before, so I wasn't completely new to pull requests, issues, and code review. But CircuitVerse specifically? I was starting from scratch.

And the first thing I ran into was the codebase itself.

CircuitVerse runs on Ruby on Rails. For those unfamiliar:

Ruby on Rails is a web application framework built on the Ruby programming language
It has its own conventions, its own file structure, its own way of thinking about problems
It is absolutely not part of the curriculum at my college

I had never written a line of Ruby before February. I had never built anything in Rails. Both the language and the framework were entirely new to me.

The codebase is also large. This is not a small hobby project — CircuitVerse is a platform used by students and educators all over the world, and the code reflects years of development from many different contributors.

The first time I cloned the repository and opened it, I felt genuinely lost. Not discouraged — but lost.

So I did what you do when you're lost. I started from the very beginning:

Watched Ruby on Rails tutorials and beginner walkthroughs on YouTube
Read the official Rails documentation
Read the CircuitVerse contribution guides and developer documentation
Spent time building a mental map of how the whole thing fit together before I tried to change any of it

Did I fully understand it after a week? No. But I understood enough to start, and that's all you actually need.

The Rule I Set For Myself

From February onward, consistency became my only rule.

It might sound simple, but it is genuinely harder than it sounds. When you are trying to break into a large open source project as an outsider, the temptation is to wait until you feel ready...until you understand enough to make something meaningful. But that moment of feeling ready never comes on its own. There is no threshold you cross where the codebase suddenly makes sense. You only get there by actually working in it, making mistakes, getting feedback, and going again.

"The journey of a thousand miles begins with a single step" — and in open source, that first step is almost always smaller and more unglamorous than you expect.

So I started small:

Documentation fixes — correcting things that were incomplete or inaccurate
Updating tests — fixing outdated test cases that no longer reflected the current code
Small bug fixes — low-risk contributions that didn't require deep knowledge of the whole system

Not glamorous work, but important work, the kind of work that keeps a codebase healthy and maintainable. More importantly, it got me reading the code every single day, building familiarity one small piece at a time.

I worked hard at it not in the sense of grinding through long sleepless nights, but in the quieter and more demanding sense of showing up without exception. Even on the days when I was tired. Even when the progress felt invisible. Even when I wasn't sure what I was doing was making any difference.

Some days I made several contributions. Some days I barely scraped through with one small fix. But the consistency mattered far more than the volume on any given day. Showing up every day, even for something modest, built a habit. And habits compound in ways that occasional bursts of effort simply do not.

Over the weeks, I started to feel the codebase becoming familiar. I began recognising file names, understanding what different directories were responsible for, knowing where to look when I encountered something I didn't understand. The codebase had not changed. I had just spent enough time in it that it stopped feeling foreign — and that shift, slow and quiet as it was, turned out to be everything.

The Saturday Meetings

CircuitVerse has weekly community meetings every Saturday, and I made it a rule to attend as many of them as I could. The only real exceptions were when I had an exam on Monday, and even then I'd try to go over what had been discussed afterwards.

I want to say clearly: these meetings were more valuable than I expected when I first started attending.

When you're a new contributor reading a codebase alone, you get a limited picture of the project. You see the code, but you don't necessarily understand:

The priorities and ongoing discussions
What the maintainers are excited about
What's been tried and abandoned
What's coming next

The meetings gave me that layer of context that you simply can't get from reading files alone. They also gave me a sense of how the community operated how decisions got made, how contributors communicated, how to bring up a question without sounding like you hadn't done your homework. These things aren't written in any documentation. They're things you absorb from being present over time.

Gradually, I started feeling less like an outsider submitting pull requests into the void and more like someone who actually belonged in the community, at least in a small way. That shift matters more than it might seem.

Growing Into Bigger Contributions

As February turned into March, I started feeling more confident. The codebase was familiar enough that I could look for more substantial issues:

Actual bugs that needed fixing
Missing features that were clearly needed
Things that needed real work rather than just documentation updates

I started creating my own issues rather than only picking up ones that were already listed. I also reached out to the mentors for the specific project I was interested in. This felt more nerve wracking than it probably should have... there's an intimidation factor around directly contacting experienced maintainers when you're a new contributor.

But I sent the messages, asked the questions, and the mentors were approachable. They replied, pointed me toward relevant parts of the codebase, gave feedback on my pull requests. I want to acknowledge that, because I think the attitude of a project's maintainers has a huge influence on whether new contributors stick around or quietly disappear.

Feeling like your questions are welcome makes an enormous difference when you're just starting out.

Deciding It Was Time to Write

At some point in early March I made a call: I have enough now. It's time to start writing the proposal.

I want to be clear about what "enough" meant. It didn't mean:

I had mastered the codebase
I had become an indispensable contributor
I felt completely ready

It did mean:

I had enough familiarity with the project
I had enough presence in the community
I understood what needed to be built well enough to write something credible

Before I wrote anything of my own, I spent time reading. The project I was applying for had been proposed the previous year and hadn't been selected I don't know exactly why, but it meant there was history to learn from. I read:

Proposals from people who had worked on CircuitVerse in previous GSoC cycles
Older ideas pages and discussions
Notes about what had been built and what was still outstanding

That research took days. But it was the most important preparation I did, because it meant that when I started writing, I wasn't guessing at what the organisation wanted. I had evidence.

Seven Drafts, Maybe Ten

I wrote somewhere between seven and ten drafts of my proposal. I lost count after a while.

I kept going back to it. The cycle looked something like this:

Write a section
Read it the next morning
Decide it wasn't clear enough
Rewrite it entirely
Add diagrams → delete diagrams → add them back in a cleaner form
Restructure the timeline
Rewrite the problem statement
Change the order of sections → change it back

The hardest section, without question, was the timeline.

In college, someone gives you a deadline and you work toward it. You're not usually asked to commit, in writing, to what you will accomplish in each specific week of the next three months. GSoC asks you to do exactly that — to look at twelve weeks and say with real specificity what will be done by the end of week one, two, three, all the way through.

In my case, there was an additional layer of complexity — I had to account for my college schedule, which I can't fully predict:

Internal exam dates aren't announced at the beginning of the semester
Assignment deadlines shift based on faculty schedules
Lab work takes unpredictable amounts of time

I had to build buffer into my timeline without making it look like I was padding. I spent more hours on that timeline than on any other part of the proposal.

The second hardest section was the problem and solution where you show that you actually understand what you're proposing to build, not at a surface level, but in real technical depth.

Five Forty-Five AM

All of this was happening while I was attending college, sitting internal exams, completing assignments, and trying to maintain some kind of normal student life.

The time I found was in the mornings.

I started setting my alarm for 5:45 AM and trying to be up by six. That gave me an hour to an hour and a half before I had to think about anything else before college, before messages, before the day's demands started stacking up.

It doesn't sound like much. But when that's the only truly quiet time available in a given day, you make the most of it. And over six or seven weeks, those morning sessions added up to something real.

There were mornings when the alarm went off and getting out of bed took everything I had. Days when I sat at my desk with coffee going cold and the proposal open and nothing useful in my head. But I showed up anyway, did what I could, and went to college. And slowly the drafts got better.

Submitting

I was late submitting my proposal for mentor review, which meant I didn't get as much feedback as I'd wanted. I got some — one mentor gave me genuinely useful notes that I was able to implement... but I wish I'd started the review process earlier.

If there's one piece of advice I'd give to anyone applying next year: send your draft to the mentors at least two weeks before the deadline. You need enough time to actually act on the feedback, not just read it.

The final deadline was March 31st, 11:30 PM IST. I submitted at 11:20 PM.

Ten minutes to spare. I'm not recommending this approach.

I was proud of what I submitted though. It was specific, honest, reflected months of work, and was genuinely mine in a way that felt important. And then there was nothing left to do but wait.

What This Process Actually Is

I want to end this post with something I believe is genuinely truemnot just something people say to make those who weren't selected feel better.

The pre-GSoC period teaches you things that cannot be learned any other way:

Skill	Where you learn it
Reading a real-world codebase	By actually working in one
Writing a credible technical proposal	By writing seven drafts and rewriting them
Consistent community contribution	By showing up every single day
Professional communication	By reaching out to maintainers and getting feedback

GSoC is not a competition for the most brilliant students at the best universities. It is an opportunity for anyone who is genuinely interested in open source and willing to put in consistent, honest work.

I was a sixth semester student who had never written Ruby before February. I didn't have a polished portfolio or a list of impressive prior projects. I just kept showing up every day and tried to get a little better.

If you're reading this and considering whether to apply next year — start now. Not next month. Now. The earlier you start contributing, the more comfortable you'll be with the codebase by the time the proposal period opens. And even if you don't get selected the first time, the work you do in the process is real and valuable in itself.

In the next post: what happened after the submission the shortlist, rounds of interviews, and the night I found out I got in.