GSoC'26 Proposal Review - {4.1 Support for Lesson Progress, Study Guides, and Worked Examples} {Aditya Verma}

[itsadityaaaaa]

Hi all,

I have drafted a proposal for the project idea {{4.1 Support for Lesson Progress, Study Guides, and Worked Examples}}. Please take a look at the doc, up to the first part of section “3.2: HOW” and let me know if you have any comments.

Thanks, and looking forward to your feedback.

Link - Google Doc

[adhiamboperes]

Thanks @itsadityaaaaa! We will review this within the next 2 days.

[itsadityaaaaa]

Thanks @adhiamboperes Waiting for feedback.

[adhiamboperes]

@itsadityaaaaa, please address my review comments to enable me to review the "HOW" section.

[itsadityaaaaa]

Thanks! @adhiamboperes for the feedback. I will let you know once I address all the review comments.

[itsadityaaaaa]

@adhiamboperes I have tried to addressed your comments. Thanks! for all the feedback Please take a another pass, Waiting for reviews.

[itsadityaaaaa]

Hi, @BenHenning actually my tech review is still pending and the deadline is tommorow, can you please consider to take a pass, even a high level pass on the main factors will be sufficient.

It will be great if you take a pass by today, so I have some time to address the feedback

Thanks!

[BenHenning]

@itsadityaaaaa I don't believe you submitted a request for a TL review, and it being past the deadline really means that I won't have time to review this, I'm sorry.

Some high-level feedback that I can give after quickly scanning the proposal (which generally applies to most proposals):

• Use diagrams to clearly explain concepts at different levels. These can be very useful for both showing the flow of data through the system as well as showing dependencies between new files being introduced. Both are useful in basically all full-app projects and definitely apply to 4.1.
• Make sure to fill out each relevant section carefully. Don't add things to unrelated sections, and make sure that you've added all the details you think make sense based on the proposal template descriptions for each section.
• Be clear about what files are being introduced or changed, and why. Both code blocks (for the actual public API changes and KDocs related to those) and bullet lists (to describe behaviors) are excellent ways to communicate this.
• Make sure you've carefully represented the milestone and project requirements based on the ideas page.
• Leverage the technical details on the ideas page as heavily as you can. A lot of time was spent writing those specifically to make the proposal writing easier and allow you to focus on making it clear that you understand the project and how it should be implemented.
• As much as possible make sure to clean up formatting errors, typos, inconsistent formatting, wrong headings, etc. Cleaner documents are easier to read and thus easier to understand.
• Make sure to carefully think through your milestone table. I generally recommend people frontload their PRs in milestones such that the first couple PRs are the largest or most complex because these undergo a lot more scrutiny. Expect these to take 1-2 weeks longer to merge than you expect, and assume you'll need to be coding multiple PRs in parallel (i.e. make sure not to only start a new PR around the time the previous is merged unless there's a dependency). Also, fewer PRs is better but you do want to make sure PRs are distinctly separate from one another (i.e. don't plan to implement all of milestone 1 in a single PR).
• Finally, do review accepted proposals from past years. These are not only exemplars of what we look for in good proposals, they also underwent significant editing during community bonding to make them excellent engineering design artifacts.

I hope these high-level thoughts are helpful to you.

[itsadityaaaaa]

Thanks @BenHenning for the suggestions.