Hey @kit and @divyansh013 just submitted my proposal and its the same question as the ones above me. My email is stargrazer11hd@gmail.com. Thank you
You should go through the proposal template and the application checklist.
Hi everyone
thanks for your patience. Thanks to mentors @claudine and @divyansh013 for their thoughtful responses too, and @Aaditya @rahulchaudhary for jumping in to help answer questions!
review requests received for: @KhushiMishra @NishthaJain @khuntvidisha13 @Geeta112 @rahulchaudhary @StarGrazer @geetth I only listed those who mentioned it publicly! I know I can be slow to respond to longer private messages but if you just ask about whether request was received I answer very quickly. I know the process and deadlines can be a bit stressful; success in GSoC program does require following process and deadlines set by GSoC. But as much as possible I am happy to make that minimally stressful.
@nixxx19 asks about extending the feedback request deadline. Although I will keep the form open, we may not get to all the requests, so I can’t guarantee it. But we will do our best to respond to as many requests as possible. The deadline to submit a request and definitely get feedback is end of day March 22 (anywhere on earth), after that it’s just luck / how long the queue is.
Eyedropper Projects
It’s exciting to see all the ideas about the eyedropper tool! Regarding the discussion among @KhushiMishra @Geeta112 @NishthaJain:
Since I’m also working on the eyedropper tool, one thing I’ve been thinking about is that the core use case seems to be shader debugging with p5.strands, which tends to be a desktop workflow - so I was wondering if graceful degradation on touch devices might be a reasonable starting point, and if people find themselves wanting touch support down the line, that could always be built on top. (@KhushiMishra)
Thanks for raising this, yes, before digging into UX edge cases, really think through the primary use-case. Rather than thinking about the eyedropper in the abstract, try to do debugging of p5.strands sketches and let your ideas for the functionality be informed by that. Everyone working on eyedropper proposals should try using p5.js v2 and p5.strands - if you haven’t already, there are some featured examples you can start with. If you need help with debugging, the discord #help channel will be helpful. Because p5.strands is a new feature, it’s also possible that you can find real bugs in this way, so stress-testing is very appreciated.
Lastly, for all projects: while some code illustrations or prototypes are welcome in the proposal, you should not complete the whole project before the program begins, or even complete most of it. This time should be used primarily for reflection, research, and connecting with community.
cc @diyaayay (mentor for this project; @claudine is supporting with reviews) in case you have any thoughts to add here!
Translation Tracker & Automated Issue Assignment Idea
To respond to the ideas from @Darshan-k and @divyansh013’s re claiming and assignment:
@Divyansh013 responded:
I feel this is true across all the processing repos? I am personally not in view of implementing something related to issue assignment which stands true only for a particular set of issues. Also in issues, we are notifying stewards of particular languages to review the issue and act upon it ( whether to themselves take them up or assign someone). However yes this can be tedious process, can you elaborate more of how auto assigning issues will remove this friction?
@Darshan-k’s followup:
My thinking was that a
/claimcommand would reduce the back-and-forth in comments where contributors ask “can I take this?” and stewards have to manually redirect them. But if stewards are already notifying specific language maintainers via cc, maybe the real gap is just visibility — knowing which issues are actively being worked on without reading every comment thread. Would something simpler help, like the bot automatically adding a “in progress” label when a contributor comments they’re starting work, and removing it if no PR is linked within a set timeframe? Or is the manual routing actually working well enough that this isn’t a priority
As Divyansh mentioned, the assignment process for issues is common for multiple repositories, and it’s possible to propose new process, but I agree it should be as general as possible. There are already many differences between repos and projects to keep in mind, it would be good to reduce them.
To clarify: there is an assignment process, and it is described in contributor guidelines. When people complete the same task and duplicate work, that is because they have not followed the guidelines. At the moment, I don’t think claiming or auto-assignment in general would improve the experience. While the general rule of thumb is first-come-first-serve, there are important cases that do require manual review. Not all tasks are appropriate for all contributors. It is important to review recent histories of contributors in some cases to ensure that they would be able to work on it. Finally, the main actual bottleneck is reviewing. Manual assignment being a little slower helps to manage the volume. Many of the PRs people make without being assigned do have to be closed or revised very much because they are missing something crucial in the code - which could have been found on contributor documentation for projects, or during manual assignment. I think automating assignment would not resolve the bottleneck overall; and it would make reviewing even slower because more time would be spent on PRs with major mistakes.
Those are all thoughts in general (and also just my opinion - anyone on the thread who has been getting involved and has had other experiences or ideas, please do share! I’ve tried to explain my reasoning, and I am open to other perspectives.) The translation case is a bit different already. In my experience, it is very rare to see PRs that really miss the mark. I think there are real visibility improvements possible: maybe it’s helpful to think from perspective of stewards who review individual languages? How can their time be more efficiently used? My impression is that that can be a bottleneck: using their volunteer time effectively on translation review more than on process. Similarly for translators. Rather than issue assignment, maybe there are other ways for a translation-specific comment bot to provide better usability.
Lastly, your idea:
the bot automatically adding a “in progress” label when a contributor comments they’re starting work, and removing it if no PR is linked within a set timeframe
Is a really interesting one. I will keep thinking about it, but some initial thoughts: Contributor guidelines do not require a set timeframe for finishing most work, but there is a “please comment your progress / confirm you’re still working on it within 7 days or the task can be reassigned” for anything not marked “Critical” (rare). I do not think there are any real benefits to this being manual right now (or are there?). I think process could be improved for everyone if “status update” reminders or enforcement could be automated; however only if it’s possible to automate without adding a lot of complexity. Maybe a related workflow or action already exists, and all that is needed is to integrate it. Open to ideas!
Best,
Kit
Hi,
I’m Rishabh, a 2nd year IT student from Mumbai University with a background in web development (JavaScript/TypeScript) and some freelance experience. I’m very interested in the “E2E Testing for the p5.js Web Editor” idea for GSoC 2026 and have drafted a proposal for it. I’ve started exploring the web editor codebase locally, tried a small Playwright-based spike for basic sketch create/save, and created a public p5.js sketch to include in my application.I’d love some feedback on whether my initial plan for Phase 1 makes sense: focusing first on a small suite of smoke tests around sketch creation, saving, loading, and sharing, before expanding to more advanced editor features. Does this sound like a reasonable starting scope for the project, or are there specific workflows in the editor you’d recommend prioritizing instead? Thanks!
Good question, and thanks for looking into the existing API and the prior work.
The previous work in PR #6710 mainly added basic .mtl parsing so that OBJ models could use material colors, but it still relies on loadModel() returning a p5.Geometry object that is passed directly to model(). Because of this, introducing something like a new p5.Materials class that changes the model() signature would likely create unnecessary breaking changes.
For this project, the goal is more to extend that pipeline so that a single model can support multiple materials and textures from the .mtl file. That means the structure mainly needs to:
• store parsed material definitions (including texture maps)
• associate those materials with subsets of faces in the geometry
• allow multiple materials/textures per model
Because of this, extending p5.Geometry with some form of material mapping might be a more compatible direction than introducing a completely new top-level class.
Your idea of extending or wrapping p5.Geometry is along the lines of what we’d want to explore. If you can sketch how the OBJ/MTL parsing step would populate that structure and how the renderer would access it, that would be a great next step for the proposal.
Looking forward to seeing the design you come up with!
You should also join the p5.js discord server.
There’s a lot of helpful information on the server plus there are regular meetups too, where project admin, mentors & contributors get together & discuss about different projects of the processing foundation.
Thank you for your prompt reply! I have more clarity on how to go about this project and deliver the architecture that is expected : )
Hi @rish001, I think that’s a good start for the project. If you’ve written a draft proposal for the project, I suggest you submit it for feedback from the mentors using the signup form, as today’s the last day of submission.
Here’s the application checklist & signup form
Thanks a lot for the quick response! I’ve already drafted my proposal for the “E2e Testing for the p5.js Web Editor” project and will submit it through the individual feedback signup form today.
Thank you for the guidance shared in this thread. I’ve drafted my proposal for “E2e Testing for the p5.js Web Editor” and have submitted it through the Individual Feedback Request Form. I’m very open to any suggestions and will be glad to revise the proposal based on your feedback.
Hi everyone — I wanted to share a quick update on the proposal I have been working on.
I submitted my draft to the feedback form today. The idea is SoundBridge: a standalone web tool that translates Processing Sound .pde sketches into p5.sound.js (and back), with a live preview and an annotation layer that explains every non-obvious change in plain English.
The motivation is simple — when you finish a Processing Sound sketch, it lives on your laptop. Sharing it means asking someone to install Processing, or recording a screen video. SoundBridge turns it into a URL.
What I have already built before the summer starts:
-
A working 29-rule translation engine (Node.js) that correctly translates all three official Processing Sound examples —
SineWave.pde,PeakAmplitude.pde, andWhiteNoise.pde -
A full API surface mapping of every Processing Sound class and method to its p5.sound.js v0.3.0-rc.0 equivalent, verified from reading both source codebases directly
-
A research sketch in the p5.js editor that confirmed the most critical finding: the connection model is inverted between the two libraries, and the inversion differs between analyzers (
setInput) and effects (source.connect) — mixing these produces silence with no error
One thing I learned from the research that surprised me: Env in Processing Sound is not an audio node — it is a fire-and-forget controller that patches directly into input.amplitude, bypassing the audio graph entirely. p5.Envelope in p5.sound.js is an actual audio node. This is the only translation category that requires understanding the whole sketch structure rather than individual method calls.
My sketch is live here if anyone wants to look: editor.p5js.org/SamarthShukla17/sketches/CRobbZmjj
Happy to answer questions or get feedback from anyone working with Processing Sound or p5.sound.js. And if you are an educator who uses Processing Sound in a course, I would especially love to hear what the sharing friction looks like from your side — @kit mentioned the possibility of connecting me with respondents from the 2025 survey, but more perspectives are always useful.
— Samarth
Hi @kit and @clairep94, I have submitted the feedback form for my GSoC 2026 proposal. Could you please confirm if it has been received? My email is aadityasingh9601@gmail.com.
Thankyou!
Hi @kit — just a quick check: I submitted my draft proposal via the feedback form on March 22 (for SoundBridge / Sound Translation). Could you confirm it came through?
— Samarth
Thanks for the update @kit.
Hey @kit any update on my second request for feedback?
Hi @kit, I have submitted the proposal for feedback on 21st. Could you please confirm if it has been received? My email is manaswimishra04@gmail.com
Thankyou!
It was received and is on our queue! ![]()