GSoC Journal: Week 2-Designs, Docs, and Decisions

Week 1 of the community Bonding Period felt mostly about settling in, setting up meetings, understanding the project structure, and connecting with the community. By the beginning of this week, two major sets of tasks were already completed. What remained was the third and probably the most important sets of tasks before coding period officially begins

And honestly, this week made me realize that large open-source projects are not just built with code. They are built with discussions, documentation, reviewes, planning, coordination and hundreds of small decisions that quitely shape the implementation long before the first major PR is opened.

This is exactly why this journal is titled: Designs, Docs, and Decisions.

Turning Meeting minutes doc into the “Source of Truth”

Starting from 8th May, I decided to organize everything (Well… mostly docs. My sleep schedule is still completely unorganized 😢) around a single central document: The Meeting Minutes

Every important resource like mock designs, migration/Testing docs, CUJ spreadsheets, PRD and Proposal doc, Product operation issue, and Pre — Launch doc would be linked there in a single table at the top.

Now, future Nitish would probably say:

“We already had a Drive folder for the project… why didn’t you just use that?”

And honestly… fair enough 😭

But since this was the beginning of GSoC — a completely new journey for me — I ended up overthinking organization a little too much.

Still, the idea behind this setup was simple: instead of wasting time searching through chats, browser tabs, and mails, I wanted one place containing the complete state of the project.

Here’s how the Meeting Minutes table looked after linking all the major documents.

At that point, most of the documents only contained rough outlines and placeholders: titles, descriptions, goals, and initial structures. But gradually, throughout the week, those placeholders started turning into actual project documents.

Designs: Refining the User Feedback Experience

A major focus this week was re-designing and refining the mocks.

During the previous weekly sync with Mohit, I had received several suggestions regarding the design and structure of the modal UI. Based on those suggestions, I reworked the UI flows and prepared an updated mock document containing both:

• user-facing mocks,
• and creator-facing mocks.

After that, I reached out to the design team with detailed context about the project and requested reviews before implementation begins.

This part of the week involved a lot of follow-ups:

• sending context mails,
• re-pinging for review,
• clearing the doubts of Talya (Lead designer for my Project) regarding my project and the issue for which he was working earlier.

The mocks are still under review by the design team — so maybe see the next journal for the continuation of that story 😜.

But jokes aside, getting the user-facing mocks reviewed early is extremely important because once the implementation phase starts, there will be very limited time for major design discussions. Since the project also has strict deadlines, most important design decisions need to happen during the Community Bonding Period itself.

Docs: Building the Project Backbone

This week was probably the most documentation-heavy week I’ve had in a long time.

Some of the major documentation work included:

• preparing migration docs,
• integrating CUJs into WIP documents,
• Updating milestones tables in proposal.

I also completed work on CUJ(critical user journey) spreadsheet and shared it with mentors for review.

One area I was particularly struggling with was integrating CUJs properly into the WIP document. To better understand this, I reached out to Jayam, and we had a very helpful discussion regarding:

• how Playwright testing could impact the project,
• how CUJs should ideally be written,
• and how acceptance testing may evolve during implementation.

That meeting helped me a lot in understanding the correct direction for integrating my project’s CUJs into the WIP doc.

I also got to understand that there is still some ambiguity around Playwright migration and testing infrastructure, which means the final acceptance tests may or may not eventually remain in Puppeteer.

That uncertainty itself was honestly an interesting learning experience because it showed me how real-world engineering decisions are often evolving rather than fixed from the beginning.

Decisions: Planning Before Coding

Around May 9th, Hardik (Org admin) had commented on my proposal and listed down many of the concerns that mentors and PMs had regarding the project direction. Some of the major concerns were:

• UI mocks needed more work,
• the timeline felt too ambitious,
• and whether we should collect any session information before the user explicitly checks the consent checkbox.

The first two concerns: UI mocks and timeline restructuring — were already being actively worked on throughout this week.

But the third concern regarding session information collection was the one that genuinely made me nervous for a while.

The concern was simple:

“We shouldn’t collect any data if the checkbox is unticked.”

At first glance, that sounds completely reasonable. But the issue was technically much deeper than that.

The current design of the project captures things like:

• console errors,
• failed network requests,
• and navigation history

inside temporary frontend memory buffers before the user submits feedback. The checkbox only controls whether that information is actually attached and sent along with the feedback report.

The reason behind this design is that browsers do not provide historical debugging information retroactively. If tracking only started after the checkbox was selected, then:

• console errors that already happened,
• failed API calls,
• or the navigation path that caused the issue

would already be lost.

That context is often the exact thing needed to debug the issue.

Still, when the concern was raised, I became slightly unsure because if the mentors ultimately decided against this approach, then a large part of the proposal and technical planning would need to change — and we were already running close to the proposal finalization deadline of 17th May.

So I spent quite some time carefully writing a detailed response explaining:

• how the data was only stored temporarily in frontend memory,
• how nothing was persisted to local storage or backend systems,
• and how the information would never leave the user’s device unless explicit consent was given.

Thankfully, after the discussion, mentors agreed with the explanation and clarified that this approach was acceptable since the information stayed entirely on the client side until the user opted in.

Later during the week, Chris also reviewed the proposal again and resolved many of the earlier comments he had raised. A few comments still remained open, so a good portion of the remaining week went into refining the proposal further and responding to those remaining discussions.

Finally, on 13th May, I requested another re-review of the proposal.

Beyond My Own Project

Apart from project planning, I also spent time contributing to the Oppia community:

• helping contributors on CORE issues,
• reviewing PRs,
• reproducing reported issues that have been blocking Translation team,
• Onboarding Members into CORE team.

Looking Back, compared to week-1, this week felt far more intense.

Last week felt like onboarding. This week felt like Preperation.

The documents are no longer empty outlines. With the coding phase approaching quickly, everything now feels both exciting and slightly overwhelming at the same time.

But more than anything else… It finally feels thrilling.

🔗 Connect with Me

• GitHub: https://github.com/NITISH084
• LinkedIn: https://www.linkedin.com/in/nitish-kumar-464995280/