Draft proposal reviews 2026

Open Source Development Google Summer of Code
1

As I have done in previous years, if you would like a review of your draft proposal before the deadline, please send them to me before next Thursday, 3/26, so that I can review them on Friday.

4 Likes
2

Hi @ewpatton,
Thanks for offering to review proposals!

Just to confirm — should I send my draft as a direct message to you, or post it here in the community?

3

You can post a link to the draft here in the GSOC group. Just make sure we can comment on the Google Doc.

1 Like
4

Hi @ewpatton,

I’ve prepared a draft proposal for adding internationalization (i18n) support to App Inventor, based on my recent contributions and investigation into the build pipeline, Blockly, and runtime layers.

The proposal includes:

  • A working runtime prototype (Form-based translation system)
  • A key-based architecture using component UUIDs
  • Blockly integration for key injection
  • Designer-based key management
  • Build-time resource generation (strings.xml)

I’d really appreciate any feedback on:

  • Whether the build pipeline integration approach aligns with expectations
  • If the Designer/SCM storage strategy makes sense
  • Any concerns around key generation or system complexity

Here is the draft:
[Google Doc Link]

Comments are enabled.

Thanks!

5

@shreyash has done a preliminary review of the design doc, and we are unsure if the Trainable ChatBot part concerns actual fine-tuning or simply a RAG implementation. Provided the GSoC wiki, which states the requirement of "RAG familiarity", but has no explicit mention of fine-tuning or RAG used for the Training process.

6

Thank you for offering to review draft proposals.

I’ve prepared my GSoC proposal for the ListView Component Update and would really appreciate your feedback. Please find it attached.

prabhasg5_GSOC_ListView_Component_Update_Proposal

Looking forward to your suggestions.

Best regards,
Prabhas

7

Greetings,

Can you please review my proposal for User defined components/extensions Project.

Here is my proposal Link - Aditya - Gsoc 2026 - Google Docs

Best Regards,
Aditya

8

I have attempted solving the app translation problem in the past, to aid in debugging foreign board posts, through

and

but I ran into the problem of keeping sync between Notifier choice returns and their offerings. ("Quit"/"Cancel"/...)

There is also the problem of Buttons that change their .Text values, for saving application state, like a Start/Stop button whose Click event needs to check its .Text value to decide whether or not to Start or Stop.

I wish you luck with that.

9

Hi @ewpatton! I would love a review of my proposal.
I have submitted PR 3850 (Fixes #3638) as my prior
contribution. Here is my proposal : Saharsh GSoC 2026 Proposal - Google Docs
Project: ListView Component Update

Thank you so much for offering this!

Best regards,
Saharsh

10

That’s a really good point, thanks for bringing it up.

For cases like Notifier responses and dynamic UI state (e.g., Start/Stop buttons), relying on translated text for program logic can indeed cause inconsistencies.

My current thinking is that translation should only apply to user-visible UI, while the underlying logic should remain independent of localized values. For example:

  • Notifier choices could internally map to stable identifiers instead of raw strings
  • UI components should avoid using translated text as a source of truth for logic, and instead rely on separate state variables

I’ll make sure to explicitly address this in the proposal as a constraint and define safe usage patterns to avoid breaking existing behavior.

Really appreciate you pointing this out.

11

Hi @ewpatton, just a quick follow-up on my draft proposal.

I understand things can get busy, but since the submission deadline is approaching (31st), I wanted to check if you might have time to take a quick look. I’d really appreciate any feedback to help me refine it.

Thanks again!

13

Hi @ewpatton and @Susan_Lane ,

This is Pranav (My previous account got affected by an automated flag , so my initial post got deleted). I just wanted to formally update you both that I have officially submitted my final project proposal for Issue #1879: UI for Tracking and Managing Permissions on the main GSoC dashboard.

My proposal focuses on providing developers with a native frontend UI to instantly review the Android permissions required by their .scm project, alongside educational tooltips explaining Android security policies to novice learners.

The proposal deliverables include:

  • An extension of LoadComponentInfo.generatePermissions() to aggregate accurate metadata.

  • A new ProjectService RPC endpoint to route the metadata. (I have already validated this backend architecture with a PoC in PR #3853).

  • A live-updating, GWT-based PermissionsPanel within the Designer.

  • An interactive filtering workflow to visually link canvas components to specific permissions.

I would really appreciate any feedback on the following:

  1. Does the backend architectural approach (using the RPC to parse and aggregate the map) align with your expectations for the codebase?

  2. Do you have any initial concerns about my timeline for handling conditional (per-block) permissions vs. strict component-level permissions?

  3. Any feedback on the overall scope.

Here is the link to my proposal draft for your reference on my actual planned deliverables:

[GSoC_Proposal] (Commenting is enabled)

Thank you so much for your recent guidance on the PR, and I look forward to the possibility of contributing!

Best, Pranav

14

Hi @ewpatton,

I’ve updated my proposal and addressed all of your previous recommendations, including refining the key generation and deduplication strategy.

I’m planning to submit my final proposal on March 30, so if you’re able to take a quick re-review before then, I’d really appreciate it. I understand you’re busy, but any feedback at this stage would help me a lot in finalizing it.

Thanks again for your time and guidance.

Best,
Akash

15

Hi @ewpatton,

I’ve completed my GSoC 2026 application for MIT App Inventor and submitted both the official Google Form and the GSoC portal proposal.

Thank you for your detailed review and feedback — it helped a lot in refining the final proposal.

Looking forward to the opportunity to work on this project.

Best regards,
Akash Gite