Recommendations for GSoC aspirants

Hello GSoC aspirants!

Some of you are already asking a lot of questions about the best way to be selected on a GSoC project.
Here are my advices (ex- or future mentors, feel free to add more if I forgot anything):

  • The most important criteria is the quality of your proposal. It should demonstrate that you understand the problem to be solved and that you have a reasonable understanding about what Plone is.

  • We do not expect you to make any PR before you are actually working on your GSoC project. The purpose of the GSoC process is to teach students how to become good contributors. So by definition, we do not expect these students to be good contributors before GSoC. (Note: making PRs before the GSoC project starts might even be counter-productive in some cases, in the past years some repositories have been flowed with poor-quality or non relevant PRs from GSoC aspirants trying to show off, and that's no fun for the repositories managers which are already very busy with other stuff).

  • To prepare yourself before the proposal phase, you can go through some trainings, so if for example you are more a frontend developer, you can learn how to develop a Volto block and a Volto theme. That way you will get a good understanding of the architecture.



Please DO NOT send us direct or private messages here or on Twitter or LinkedIn, etc. about how to get selected or what to do to be considered for GSoC.

There are lots of resources here and on and on explaining this.

If you have questions, please ask them here where other mentors and members of the Plone community can respond.


A couple more tips.

  • Read the documentation, especially for how to install Plone 6.
  • Regarding Eric's comment about making a pull request to a Plone project, if you choose to proceed, and before you do anything, you must:
    1. Sign and return the Plone Contributor Agreement.
    2. Try out or install Plone.
    3. Become familiar with the project's contributing guidelines. All Plone repositories have either the default minimal contributing policy or override it with their own. For example, see Documentation and Volto.
    4. Do not ask to work on, or be assigned to, an open issue. Plone is a "do-acracy", which means if you want something done, just do it. However it's a good idea to make sure no one has already done the work. Check for linked pull requests and issues. Sometimes we forget to close open issues that have already been resolved, or work was started in another pull request and abandoned. You are welcome to ask for clarification of the scope of work, especially before starting work.
  • For support, ask your question in this forum. There are over 2000 users here, which is the single largest audience for support for Plone. If you ask for support in other channels, we will just direct you back here. When you ask for support, include sufficient information for other people to reproduce or diagnose your issue, but please do not post images of error messages.

Can be please pin this thread in Discourse?

:fire: I approve this message :slight_smile:

If you do post an error message, it is far more valuable to include the actual text from the error message. Extra points if you take the time to use the correct markdown so that it shows up as code and not standard text!

Hello Sir ,
Amit here and i am interested in contributing to the project - Refactor class components to functional components. Can you please guide me and let me know what all will be required in the project proposal for this idea and let me know how can i get my draft checked before submission

hello sir,
where can i submit my proposal for a review?

Through the GSOC portal, as stated in the GSOC documentation and rules.

Got it. Thanks for answering