Skip to content

FAQs (2026)

Jump to bottom
Claire Peng edited this page Mar 16, 2026 · 3 revisions

This page covers GSoC 2026 FAQs! With many thanks to the prospective GSoC applicants who asked excellent questions and therefore helped to make this resource possible.

Key Links:

Application Forms:

More info:

Timelines:

  • Feb 26 - March 16: Ask questions on the Discourse thread and Discord.
  • March 16 - March 22: Applicants may request feedback via the feedback form
  • March 16 - March 31: Register on the site and submit proposals for projects. After this, proposals will be reviewed by mentors.
  • April: Mentors will review applications. Successful applicants will be contacted within a few weeks. Please see GSOC official timelines for more.

How to approach writing the proposal?

View more details 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.

How should I engage with projects and mentors outside of my feedback request and application?

  • Please use Discourse as your primary channel of communication for any questions about the application process & projects. Do not contact mentors directly outside of these channels. We would like to make sure all information is available to all applicants.
  • Engagement in the Processing OSS projects is not limited to PRs. We also look at community engagement in Discourse, Discord, repo issues & PR comments. We are looking to work with kind and collaborative developers, and this can be demonstrated outside of coding work.

How are proposals evaluated?

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.

More details

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. 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.

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.

How do get started on contribution?

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 it 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!

What if there are technical roadblocks, like installing something?

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!

Tips for the 2026 projects

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!

E2E Testing for the P5.js Web Editor

This project can be understood as having three distinct parts:

  1. Setting up e2e testing on the p5.js web editor CI pipeline
  2. Defining key user flows & writing tests for at least one of these flows (ideally more)
  3. Writing documentation so that other devs can continue the e2e testing work after GSOC

Why was this project proposed?

We have a view in the near future to refactor/cleanup the backend of web editor repo & continue typescript migration, and this area of the project is quite old/missing love! We want to do this, but it's a bit scary to work on due to lack of tests in some areas.

The e2e tests would help us be able to make refactors without fear of accidental regression & it would be faster to add a suite of e2e tests vs. adding unit tests incrementally.

This would also help a lot with speed of code reviews -- PRs will need to past this new E2e test prior to review, so it would give reviewers more confidence in passing bigger blocks of changes

What are you looking for in a proposal & applicant?

Soft Skills:

  • Curiousity & ability to independently explore/research technical implementation. Ability to communicate their proposed approach clearly and without too much verbosity.
  • Kind & helpful engagement in the OSS community via past engagement.
  • Understanding of the p5.js Web Editor flows. You don't have to be a historical user, but it would be good to see that you've tried writing sketches and know how to describe the experience we are trying to secure.

Hard Skills:

  • Past experience with frontend testing from either work experience, or a personal project.
  • Github actions experience is nice, but not mandatory.
  • Ability to describe technical details in approachable, non-technical language. Part of writing end-to-end tests will be describing user flows in non-technical language. As part of the project, you may also want to communicate with users to ask about their most important flows to see what to secure first.
  • Project/product management skills. It will be up to the mentee to define and choose which flows to prioritise to implement within the timeframe of GSOC.

Technical Knowledge / Research:

  • A proposal for a specific E2e testing framework that is justified by research into the framework & the existing codebase compatibility.
  • A high-level understanding of Github Actions, and the risks/considerations that we would need to take to integrate e2e testing on CI (When should this trigger? What are considerations with concurrent test runs? How to approach interactions with databases and third-party services? etc.)
  • Research into past & existing repo-issues related to this project

Clone this wiki locally