-
Notifications
You must be signed in to change notification settings - Fork 2
FAQs
This page covers GSoC 2025 FAQs! With many thanks to the prospective GSoC applicants who asked excellent questions and therefore helped to make this resource possible.
Right now is the time to explore and to develop proposals. To get feedback before final submission, please submit a feedback request between March 24 and April 1. Final submission via GSoC website is due April 8 (please check the time and timezone of this deadline as well!)
After proposals are submitted, some will be accepted, and then work can begin. So for now, please feel free to try things out and explore (and keep asking questions!), but please do not work on the projects directly.
We suggest getting familiar with the part of the code and ecosystem more relevant to the project you’d be interested in. Each project lists which codebase it is related to. If you find a good first issue that is relevant to your interests, go ahead and comment your interest!
First, please be sure to review the official GSoC guidance on writing a proposal, as well as all the resources we've put together in this wiki.
Second, if you’re not sure were to start, we do generally recommend checking out this possible structure but we will not be evaluating you on a specific structure. We would rather get to know you and your ideas and interests through the proposal: if you think in bullet points or diagrams, keep those! No need to turn them into paragraphs or structures that don’t feel helpful. The page I shared above just gives some ideas of content you can include; you can include any of that information that you think is helpful. There is NO set template. Please use the format and style that best suits you to describe a project proposal. A proposal should be around 3-6 pages, but it might be longer or shorter depending on the content.
Third, one of the most important parts of the proposal is creating both a technical outline of work and a timeline. One helpful rule of thumb here might be that less is more. Regardless of project size, please feel free to build in buffer for uncertainty or experimentation. A more kind and thoughtful timeline is better than a one with too many tasks to be realistic. Planning to do 1 thing well, with time for exploration and testing is more compelling than planning to try out 5 things without enough time to really go deep on any one of them.
Proposals are welcome to integrate a little bit of prototyping or user research into the timeline, as long as it doesn’t make the project very difficult to finish on time
No matter how much experience with programming you might have, estimating how long a technical task really takes can be really hard! So the more your timeline can reflect your own self-knowledge, the better. If you don’t know how long a task will take, is it possible to break it down into smaller pieces that can be more easily understood? Can buffer be built in to help make your timeline more possible?
You can start putting your proposal together, and we'd suggest to first envision what you’d want the final result to potentially look like (maybe imagine 2-3 different ideas of a final outcome you’d be happy with, and pick one!) and then work backwards to create a timeline.
- Feb 26 - March 24: You’re welcome to ask questions on the Discourse thread
- March 24 - April 8: Register on the site and submit proposals for projects. After this, proposals will be reviewed by mentors.
- May 8: Selected projects and participants are announced, and mentorship begins!
The time to submit proposals will be March 24 - April 8. Just before then, we'll post on Discourse and here instructions on how to send in your draft to us for individual feedback with the relevant mentors. That way, if you have a proposal ready at that time, you can get a round of feedback from the mentors before submitting in to GSoC directly.
To get feedback before final submission, please submit a feedback request between March 24 and April 1.
You’re welcome to continue ask questions (also quite detailed ones) on Discourse, and we'll do my best to answer them. I am sure many questions also apply to others, so that’s why we are taking this grouped Q&A approach to answering them. The public Discourse thread is still the fastest way to get your questions answered - but the above form is an opportunity to get some input on your specific application from mentors as well.
Both technical understanding in the scope of your project and community values and process alignment are very important, and both are necessary. Neither requires making PRs! You’re welcome to be creative in how you’re approaching showing each of these in the proposal.
Regarding the technical side: a proposal that is more realistic is better than one that promises bigger results!
Regarding the community side: please demonstrate having meaningfully engaged with PF online community spaces. Participating in the Discourse thread is the easiest way to do this; other ways to participate include getting involved in GitHub issues and PRs, but please be mindful of the contributor guidelines in each project.
The proposal itself is very important. We are looking for your creativity and detail in proposing technical work and planning it our before actually doing it. As the “proposal” section in this example GSoC Template suggests: “Explain what algorithms/technologies you intend to use/study (if any). You can also include links to additional details like diagrams, etc., outlining your ideas acting as supplementary information for your proposal outside of this scope.” and “How do you plan to spend your summer? … The project plan and its timeline will form a significant part of the assessment of your application, as well as mid-term and final evaluations.”
Overall, a proposal probably should be 3-6 pages. You should justify the use of particular tools, but it’s not just technical considerations. For example, if you’re more familiar with tool X, that is also a pro (because it makes your timeline more realistic); or if tool Y is very technically robust but is really hard to use and understand, that is a con (because it could make your work harder to share and maintain with the wider community).
Please do not include AI-generate pro/con lists, these are often very generic and don’t contain important considerations. Decisions on what tools to use and how to move forward are the heart of technical work, so we’re interested in hearing how you would approach it. Any structure is fine, whatever helps you present your idea best.
Selection will be taking the application as a whole. The proposal matters a lot, and a good proposal is one that showcases your idea, and reflects that you’ve done some research (for example, understanding some relevant GitHub issues or commits to find out what specific decisions have been made in the past and why, and what are the concrete challenges of implementing your idea in specific.)
In addition to the proposal, we will consider all forms of contribution, as PF follows the all-contributors spec for both p5.js and Processing 4. The means that you can mention as contribution not only PRs, but also blog posts, events you might have hosted in the past, etc. Contribution also includes constructive participation in our online community spaces - that means GitHub issues as well as on Discourse.
In the application, the purpose of contribution, like the purpose of research, is to show that you’ve gotten a little familiar with the technologies you’re proposing to work with and that you’re comfortable with the code of conduct and contributor guidelines that applies to the project you’re proposing about.
If you’d like to dig further into the open issues on GitHub, here are some help wanted and good first issues in each of the project repositories:
If you are finding it difficult to find good first issues relevant to your project proposal, keep in mind that contributions may be either on GitHub or outside! both Processing4 and p5.js adopt the all-contributors specification, which means that a contributor is someone who works in any of these areas: Emoji Key ✨ (and Contribution Types) So if you cannot find an issue that is available and helps you write a proposal, you can also think about another form of contribution, like a blog post, tutorial, series of examples, bug reports of accessibility issues, etc!
Please be sure to check out the Contributor Guidelines first, especially:
You should not file a pull request (or start working on code changes) without a corresponding issue or before an issue has been approved for implementation; that is because the proposed fix may not be accepted, need a different approach entirely, or the actual problem is somewhere else. Any pull requests filed before the issue has been approved for fixing will be closed until approval is given to the issue.
This is really important, and I know if can be frustrating to wait for responses, but that is why it may be helpful to keep in mind that, under the all-contributors specification, there are many ways to contribute outside of GitHub, too!
Installation can sometimes be challenging because each piece of software can require multiple other pieces of software with specific versions. Usually, if an installation guide specifies a version of anything, it is very important to follow that exactly. So if you are having problems, please try to follow the steps as precisely as possible; if you are still having problems anyway, then it could be a bug! When you file a bug please make sure to include as much information as possible in your new issue / bug report: which step did you get to in the installation guide successfully? What error output do you see?
Having installation problems is really common, so I hope the above can be helpful more generally too: when in doubt, try to clean up your (digital) workspace, start from step 1 of the installation guide, and document what’s going on so it’s possible to ask for help!
All these comments are based on questions that came up in the Discourse thread. Keep in mind some of the tips might be applicable even beyond the specific project!
If you want to work on this project, one way to go about it is to investigate what existing methods and tools exist (many of them out there!) and then figure out which (and how!) can be meaningfully combined into an embedder tool. This investigation can look like trying out existing tools, maybe even creating open-source examples/tutorials about them (this would certainly count as a contribution!), but not quite yet developing the project itself. I encourage anyone thinking about this project to check out existing methods of embedding sketches:
- Editable editor with previews, like in the p5.js reference or the tutorials - keep in mind that sometimes people want to include code; sometimes not editable; sometimes not at all. Sometimes people might want multiple sketches on a page with different settings; if it’s a sketch that makes sound, for example, when should it autoplay or not?
- More details on instance vs global mode - based on this, try to create a local testing ground where you embed some sketches into a page!
Keep in mind that one of the most important uses of p5.js is to create interactive works that can be embedded in the browser with a <script> tag. As you noticed the <iframe> method is already supported by the p5.js Editor “share” option, so in proposals for this project we’re interested in what you can imagine as a more fully-featured approach, so more focus on what’s possible with <script> would be exciting to see. If you use an iframe, you’re limited in being able to control sketches or have them potentially interact in some interesting way with each other or the site. If you don’t use an iframe, you can’t update your sketch from the Editor directly. If you use script tags and attach to a div, you need to use instance mode which can be a barrier to entry for beginners. If you’re an educator, then including the code and making it editable is also desired, and that’s different technically as well. Various examples have been mentioned on this thread before, too, and these may be helpful to check out!
In the case of the friendly sketch embedder project, using the p5.js Editor to make some sketches and then trying to embed them using existing tools/methods would be a good way to get familiar with various tools. Use the p5.js reference to explore different functionalities, and also use Examples and Tutorials on the websites to make more complex sketches to see how they work, and if some are more difficult to embed than others.
When we were discussing this project, we envisioned some balance of using some of the many tools/methods out there, and building something stand-alone so that it could be really user-friendly and straightforward.
Because this particular project is pretty stand-alone, you can propose any framework that supports your vision. It’s important the p5.js sketches can be robustly embedded in that website, so that’s something to consider when making your proposal. You can check out how embedding sketches with editable code currently works in the p5.js-website repository, as an example, if you’re curious; but this is very flexible.
For this project, you can assume that the audience for the embedder is people in the community who already use or teach using p5.js, so they may not know all the p5.js features or details, but you can assume they do have sketches that they want to embed somewhere!
This is a project idea is one we expect to be around Medium difficulty, and also has (like all the projects on the list!) great community impact potential. If you’re more excited in crafting an end-user-facing feature, this may be the right project for you to consider.
Let’s say you have a feature idea related to this project. How to explore this idea?
-
First, what’s the motivation? Identify a concrete problem / use case. Them, can you find sketches or perhaps community libraries that have examples that can demonstrate the issue that you’re describing? VSCode is already used for p5.js and offers more advanced code editing. The web editor is specifically offering a very simple environment that is easy to share and easy to get started with. Thus, a proposal of this feature could directly consider: is the motivation of this feature consistent with how the p5.js Editor is used by the community? (If there are other motivations you can think of, we are open to fresh perspectives!)
-
So with the above in mind: what are the technical possibilities, how difficult would they be to implement, and how difficult would they be to maintain over time? The p5.js Editor is mostly volunteer-maintained, and so as you consider maintainability, it might be useful to look through the “Needs Discussion” issues.
For a proposal, you don’t actually need an answer yet, but rather diving deeper into the pros and cons of each approach. For example, running something directly in the browser can be very helpful for educational contexts which tend to have challenges with overuse of wifi by too many machines for too many tasks. So anything that needs really quick and smooth UX benefits from doing as much locally as possible.
Also, with any of these approaches, anyone writing a proposal about this project is welcome to think beyond autocompletion; consider what information would be most helpful. For possible ideas, you can check out the p5.js 2.0 updates thread where there is a lot of discussion about how best to support users of p5.js 1.x to become familiar with major new changes in p5.js 2.0. Is one of the technical solutions to autocomplete (local static analysis) that can help (such as noticing use of preload with 2.x)?
Thinking about existing UX and how to improve it, and thinking about different use-cases is a great start! The p5.js Editor is used by artists, students (in classrooms and beyond), and teachers; and by people at different levels. When considering the project list, we discussed this project as either updating the autocomplete widget, or adding a custom context menu widget. A custom context menu would be something that comes up when a user right-clicks, so it’s a very different kind of tool than the autocomplete, with different technical UX possibilities.
Please feel free to think creatively about what’s possible here! Only if it’s informative or inspiring, feel free to check out the PRs that introduced the existing hinter (former GSoC project, in fact!):
This project could also have a different scope depending on what is being proposed: 90H-175H.
In the skills, we write “Familiarity with digital accessibility (a11y); TypeScript; and/or documentation.js/JSDoc can be a plus.” - these are topics that might be informative depending on what direction you want to take your proposal. So if it’s something you’re interested in, you could look into the topic a bit as you’re working on the proposal, but it’s up to you whether you look into it or how deeply. If you do have these skills/interests, it’s great to mention them in your proposal, but they are not required!
It would be totally in the spirit of the project to propose something more extensive/integrated. We marked it as “Easy/Medium” because we were thinking about how this project could benefit from the input of someone who is interested in web accessibility, but is also new to it - so they can more easily have an intuition on what motivated newcomer contributors might struggle with.
So as you’re putting together a proposal, you can make a list of everything you’re finding confusing about web accessibility implementation. The ARIA roles implementation as a starting point for this project is also meant to be a bridge like this, but you certainly don’t need to start coding. One place to look would be closed issues on the p5.js Editor related to accessibility, and reading through what was easy and hard. Another place would be to look for inspiration beyond the p5.js ecosystem for ways web accessibility testing happens.
For this one in particular, I suggest checking out the most recent Processing4 release. It does have Java tests. If you’re not already familiar with how p5.js snapshot tests work, that would also be really helpful here (you can read about them in the last section of the p5.js unit testing doc).
Picking one test and trying to port it might be good research on how challenging the porting itself may be. To figure out the priority areas for what parts of the functionality tests should cover, you can also research old GitHub issues! Closed or open bug reports, for example.
Ultimately, the purpose of tests is to make it more comfortable for contributors to add new features or make performance improvements without accidentally breaking anything unexpected. So if your proposal suggests which areas are most important to cover, and explains why you think that (from reading old issues or any other approach!), that would be an excellent evidence-based prioritization of the project.
In terms of preparing and getting familiar with all the repositories - for all projects but especially for the more developer-tools ones like this, it is likely to be much more informative for you to go through the open discussions; and older closed issues or PRs related to specific updates (when was a particular test added? What can you learn from that?). Most likely, there aren’t many “good first issue” opportunities for these more complex projects, so it’s not a problem at all if during the proposal phase you focus on understanding the challenges that exist.
This could be a really impactful project (as they all would be!) and (as with all of them:) we are open to your ideas. You can check out existing tutorials where Processing sound is used but can’t be demonstrated in the browser. How can you approach translating that Processing code into p5.sound.js code? If you haven’t played with p5.sound.js and Processing sound yet, that would be a great starting point too, to understand where they overlap and where they don’t:
This project in particular requires thinking creatively about how to translate creative/artistic/musical code between different environments and devices that might have different capabilities.
It might be helpful (keep in mind it’s outdated, so maybe not) to check out this older existing project that generally translates processing to p5.js: website and code You’re welcome to suggest a tool, or build in time to research transpiler tools into the timeline.
At the stage of writing the proposal, please present your ideas on how the development process should look like. The GH Actions would likely need to be added to the website repository, but keep in mind that it’s not obvious exactly when they should ring. For example, if documentation in core library changes (in p5.js repo) that should result in some kind of check whether translation is outdated in the website (p5.js-website repo) so there’s a number of different ways to do that kind of verification when the source of truth for some of the website (reference) is actually in another repo.
Keep in mind that right now is the proposal stage, so it is not the time to add any actions to the repository, but you could test out ides about actions in isolated repositories.
You can check out open “Translation” issues to get a sense of how translation has to be managed currently. This project idea is one that we expect to be medium/hard in difficulty, and that the technical solution is something we are very open to. The current system first generates part of the website (the reference) from the core library code (documentation.js); then the .mdx files in English are built from that; then each language translation is manually added. Thus, updates to content require manual checking of what needs to be updated and where. Meanwhile, translation is typically one of the best ways for newcomers to get involved in open-source, so making any aspect of this much smoother would be really impactful in the community, and could even make it possible to expand language support! So if you’re interested in working with multiple repositories, an integrated workflow over multiple technologies (see the stack in the ideas list), and if you can feel yourself excitedly imagining multiple possible engineering solutions to try out, then this could be the right project for you to consider.
Right now there are no automations around translation. If you check out this current issue about translating the Code of Conduct, you can get a sense for the current process, and maybe get some ideas of what might be helpful. Additional to creating new translations is maintaining translations; such as the reference.
Proposals about translations should try to answer the question: How can friendlier developer tools - such as GitHub automations - could help contributors work on translating documentation? There’s actually already some other work on a web-based UI for translation in the website that can be used; what’s really needed in this project is a robust way to understand what needs to be translated and when.
More comments on what part to automate - workflow vs translation itself:
The reason to not replace manual translation is that fully automated translation can be worse in lower-resource (less data) languages or language pairs, and can lack nuance, even though it is already very good and getting better. More importantly, generated and auto-translated text can be more wordy and less precise than a manual translation. Right now, a fully automated translation is already available in Chrome, so if you can also experiment with using automated translation of technical documentation to check out where it works well and where it struggles.
Lastly and most importantly, translation can be a wonderful way for total beginners with Open Source to get involved and learn GitHub and all the different Open Source tools - and to share their language with the community. Right now, you can see the website has only a few translations, and many people who would be happy to translate into their own languages as a community project! The aim of these automations is to support community access.