@manas_23 asks: “How can I contact the Project Mentor for Review of the Proposal?” and @deepikareddy also asks for mentor feedback.
So far many folks have been asking about how to get mentor feedback, so I’ve added this to the FAQs:
You’re welcome to ask questions (also quite detailed ones, as you see above) here until March 24th, and I’ll do my best to answer them. Then, if you have a draft ready by March 24th, you can have an opportunity to get feedback before final submission. I’ll post 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.
@Sushant_Bansal asks: “Can I share my some ideas in the forum?” and " how can I start working on this project Bring Visual Tests to Processing?"
Feel free to share ideas for public feedback here! I’m happy to comment on ideas or questions related to specific projects. The thread is getting long so I will also be adding to the FAQ document, and if you like you could check there first if your question has already ben answered. For the visual tests project, here are some tips on getting started based on prior questions.
Also, I saw you’re having technical issues; have you tried looking up how to correctly expose port 8000 in Docker so it’s reachable in your browser?
@deepikareddy asks “the best way to proceed?” on the Friendly Sketch embedder project.
Welcome! Please check this summary of all the tips and guidance on that project specifically, and do feel free to ask about anything not covered, or for clarification!
@Hritvik-Bhatia asks if PRs in one repository (p5.js-website) are still relevant to a project in another repository (p5.js-web-editor)
First of all, I’ve seen the PRs, thanks so much for jumping in to improve the website! Also, your translation is also now live.
To anyone reading this who has had PRs merged: we use the all-contributors specification, so if you merged a PR on p5.js core library or the website, please follow these instructions to add yourself to the list, and use the emoji key for code, translation, documentation, or anything else applicable. Especially if the contribution is in another repository, please be sure to comment on that PR what the contribution was, otherwise I’ll comment and ask about it.
Secondly, to your question, and to @yehirasheed’s question: “Also, if some of my contributions aren’t directly related to the specific project I’d like to work on for GSoC, would they still be considered when evaluating my application?”
Yes it’s no problem, PRs in one of the repositories support any of the proposals.
@touro asks:
So I’ve been pretty interested in shaders, WebGL, and all things graphics lately and was wondering if a custom proposal revolving around those topics would be possible this year? And if there’s any suggestions for projects that touch on those areas that would be useful for p5.js or Processing. Is there someone I should talk to in particular about this?
First of all, welcome! To this question: though a custom project is possible, the existing list has been specifically curated so that it does not have challenging dependencies with ongoing work, but still has impact. Both Processing and p5.js have a lot of major updates coming up; on p5.js, one of the exciting new things is actually about shaders. That is why WebGL is not on the projects list: to allow GSoC projects to be creative, ambitious, and impactful, but still relatively self-contained.
So, I would suggest even if you do something very particular to shaders, consider if it’s possible to do it within the scope or direction of one of the projects on the list? For example, visual tests, or sketch embedder could have interesting WebGL aspects? I’m not sure what that can look like, but if you have an idea, go for it!
I hope that helps, please feel free to ask about it further.
@yehiarasheed asks: “I had a quick question about the maximum two PR submission rule for GSoC applicants. Is this limit organization-wide (including Processing 4, the websites, etc.), or does it apply separately to each repository?”
Welcome, and thanks for this question! For everyone reading: this refers to the guidance on p5.js Editor contribution.
The purpose of the rule is to avoid excessive PRs, especially if they relate to features or issues that have not been approved for work. This rule is for the editor, but for Processing and p5.js you can also check the Contributor Guidelines before making PRs, 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.
The reason for this rule is that making lots of PRs might not actually be as helpful to your proposal as taking the time to research and develop a strong technical concept and execution plan. We strongly encourage folks to dedicate lots of time researching the project areas, reflecting on the existing issues, and crafting their proposals.
@Lakshit asks about the Bring Visual Tests to Processing project:
I read the GitHub issue #882 - Implement image comparison for visual tests and also checked out the p5.js snapshot testing system. I’d love to learn more about how this could be adapted for Processing’s Java environment.
Would it make sense to start by porting some existing p5.js snapshot tests to Processing, or are there other priority areas to focus on first?
Welcome, and thanks for this excellent question!
In general, now is a good time to do implementation research, but keep in mind: you do not need to start implementing to write your proposal.
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.
I hope all this is helpful, and thanks again to all who are asking questions! I’ll be back in a few days to respond to the next round. Wish you all a nice rest of your week.
Best,
Kit