We’d recommend starting by exploring the codebase, going through open issues, and setting up the project locally. If you have any doubts or need help getting started, don’t hesitate to ask in the Discord — the community is very supportive!
Hi everyone! I’m Adetunji Akeem, a final-year student from the University of Abuja (Nigeria) and an intermediate Java developer with experience in Spring Boot. I’m interested in the Code Translation project because I recently started exploring creative coding to step outside of standard backend work. This project is the perfect way for me to use my solid Java background to help build a bridge into the creative web space.
@kit@raclim Thanks so much for reviewing my proposal, the feedback is very good and detailed as expected. Currently, I am going throughout my whole proposal keeping all your points in head. It is really helpful!
Your background in Java and Spring Boot is impressive. The Code Translation project sounds like a great fit for someone who wants to bridge technical and creative spaces. The Discord server is where most active discussion happens, so definitely join if you haven’t already.
Good luck with the Code Translation project
I’m Samarth, a final-year engineering student with a strong interest in software development, particularly in building practical and user-focused tools.
I’ve been exploring the Processing Foundation and really appreciate its mission of making creative coding more accessible and inclusive. I’m especially interested in contributing through GSoC 2026, and I’ve started going through the project ideas and repositories (particularly around the p5.js ecosystem and developer tooling).
I have experience working with JavaScript, building web-based applications, and developing APIs, and I’m currently strengthening my skills in frontend systems and tooling. I’m excited about the possibility of contributing to projects like the p5.js web editor, testing infrastructure, or developer-focused improvements.
I’d love to get started early and contribute before submitting my proposal—any guidance on beginner-friendly issues or areas that need attention would be greatly appreciated.
Also, I wanted to ask if there is a preferred proposal format or any specific expectations that contributors should follow while preparing their GSoC proposal.
Looking forward to learning and contributing to the community!
Sure, For the Code Translation project, I’d suggest
joining the p5.js Discord server. Once you’re in,
the #contribute-to-p5 channel under the “Code” section
is where most contributor discussions happen.
Hi, @samarth_27 . Great to see you joining the Discourse!
Based on your interest in developer tooling and the web editor, here is where to look:
p5.js-web-editor: It’s perfect for someone with your API and web app experience. Look for issues labeled good first issue or help wanted.
p5.js: The core library. If you’re interested in testing infra., check out the Unit Testing or Developer Experience labels.
Start with the p5.js contributor docs. Improving documentation or adding a missing test case is a highly valued way to show you understand the codebase.
Also for questions around GSoC and proposal you can refer the first post. If still you have any doubts, you are welcome to ask them.
Great to see your interest in p5.js web editor and GSoC 2026.
A few things that might help:
check out the 2026 project ideas list linked in
the first post.
The proposal template is already available, you can
access it from here- proposal template
We have sent all the reviews of proposal drafts! Thank you all very much for your patience, and for all your careful, inventive, and thorough work. If you did not receive an email with feedback, please @ me.
We were able to get to all initial feedback requests and all follow-up requests! These were only possible for a few people who submitted their initial request earlier on.
It was a team effort with all the mentors (Claudine, Claire, Divyansh, Diya, Kevin, and Lee), maintainer Dave, and org admin / p5.js Editor project lead Rachel. We sincerely hope the feedback has been useful for everyone, and we look forward to reading all the submitted applications!
Good luck with the final preparations, everyone! I will do my best to answer any urgent questions as quickly as I can, I know how the last few days before a deadline can be.
@diyaayay For the eyedropper tool, I am displaying the coordinates of the pixel as well. But in the 2D canvas, the origin is at the top-left corner, for WEBGL the origin shifts to the center, and shaders use normalized floating-point coordinates. I thought of keeping the coordinates uniform to maintain consistency across all renderers but after getting my feedback, I am re-thinking whether or not that is a good idea. Please let me know your thoughts on this.
Hi @Kit, I hope you’re doing well. I realize I submitted my draft quite late and may have missed the review cycle. If you happen to have any availability, I would really appreciate any feedback on my proposal, even brief pointers. Totally understand if it’s not possible at this stage.
Thank you for all the effort you and the mentors have put into helping everyone!
I’m Alina Doorbekova, a second-year CS student at ELTE (Budapest). I recently started using p5.js and I’m genuinely enjoying it—I’d like to go deeper by contributing to the project.
I’m especially interested in the p5.js Web Editor for GSoC 2026. I’m going through the codebase and contribution guidelines and hope to open a small first PR soon.
I’m looking forward to learning from the community and contributing where I can.
Hey @NishthaJain, I’m also working on the eyedropper tool and had the same thought about coordinates.
What I think is, showing mode-specific coordinates would feel more natural to users. Like if someone is working in WEBGL mode, they are already thinking in that coordinate system, so showing unified coordinates might just feel off to them. so mode-specific coordinates would be more contextually accurate.
But want to know what others think, am I missing something here?
Since you are already going through the codebase, you are definitely on the right track.
For your first PR, the “good first issue” label on the p5.js web editor
GitHub repo is a great place to start.
Also if you haven’t joined the p5.js Discord yet, do join it.
One thing I’ve been thinking about while working on this: the eyedropper samples color from the canvas pixel buffer (via getImageData or WebGL’s readPixels), which always operates in canvas pixel coordinates regardless of the rendering mode.
Even if we want to show WEBGL-space coordinates, there’s a bit of translation involved - like handling the flipped Y-axis and centered origin. Maybe showing both could be useful: raw pixel position for accuracy, and mode-aware coordinates for context.
Would love to hear your thoughts, and happy to compare notes if you want to dig into this more.
Hey NishithaJain @Geeta112@KhushiMishra — thanks for bringing this up! I really appreciate the discussion here.
I actually started with uniform coordinates too, thinking consistency across renderers would be cleaner. But after seeing this thread (and some feedback), I’m now leaning toward mode-specific coordinates as well.I actually started with uniform coordinates too, thinking consistency across renderers would be cleaner. But after seeing your feedback, I’m now leaning toward mode-specific coordinates as well. @Geeta112’s point really resonated with me — users working in WEBGL mode are already thinking in that coordinate system, so showing them something different might actually be confusing rather than helpful. Context matters more than cross-mode consistency in this case. @KhushiMishra I like your idea about showing both! Though for the default UI, I think starting with mode-aware coordinates makes the most sense — maybe raw pixel data could be an optional/advanced view if needed.
Thanks again for sharing your thoughts — really helpful to hear different perspectives on this!