Google Summer of Code 2026 Guidelines and Project Ideas

Project ideas are proposed by mentors from the Plone organization, not potential contributors. Potential contributors should discuss ideas (see below section) in the Community Forum's Google Summer of Code category. See the Google Summer of Code 2026 Timeline.

Plone Google Summer of Code guidelines

The Plone Foundation has been a mentoring organization for the Google Summer of Code program for many years. It is great to have students working on Plone and related projects during the summer. It has brought many new contributors to the community.

Since a few years ago, the number of candidates has been significantly growing, and we are very happy about that. However, the amount of candidates is not easy to manage for us as a community. Please remember, Plone mentors and community members are all unpaid volunteers.

The following dos and don'ts for the GSoC candidates are a guide to help them get started with Plone, and to help us manage the number of candidates.

Don't create issues, pull requests, or comments in GitHub

GitHub is used by contributors who use Plone for their work. GitHub is not a place for GSoC candidates to ask for guidance, help, or support. GSoC candidates should not create pull requests, issues, or comments.

Don't request to ask to become a member of the Plone GitHub organization. You will become one only if your GSoC project is accepted.

Doing any of the above actions may result in your suspension or banishment from the Plone GitHub organization. Additionally, it will prevent you from being selected to participate in GSoC.

Don't contact individuals

Please don't contact us individually via chat, private message, email, or any other account or social media service. Doing so will prevent you from being selected to participate in GSoC.

Don't introduce yourself

We are aware that introducing yourself seems like basic politeness, but due to the number of candidates, it only adds noise to the messages we receive.

Don't be disrespectful

Candidates must treat other developers and GSOC mentors with respect, both in text and communication. Disrespect will prevent you from being selected to participate in GSoC.

Do watch this page for updates

This page is the authoritative source for everything to do with GSoC. Check back often.

Do your reading and research first

Please ensure that you have reviewed our training and documentation.

Doing so should answer most of your questions on how to install, use, and develop Plone.

Do learn about Plone

Plone is a complex system, and it is not easy to get started with it. We expect that you have started to learn about Plone before applying.

The best way to learn about Plone is to follow our online trainings and our documentation.

Do use our community forum

If, after you have reviewed our training and documentation, you have questions, use our community forum's search feature to check if your question has already been answered.

If your question has not yet been answered or you require further clarification, ask in the community forum.

If you have technical questions, such as running into a problem installing Plone, read our guidelines on how to ask for help.

You are welcome to ask questions about the GSoC projects on their dedicated threads. You can propose your own ideas in new threads.

When you post to the forum, use the category "Google Summer of Code".

Do focus on your application

The primary criteria for selection to GSoC is the quality of your application. Make your application stand out by showing that you have learned about Plone and that you have a good understanding of the project you are applying for.

Don't use artificial intelligence (AI) to generate your application. We can tell the difference between thoughtful and AI-generated applications. We will throw away AI applications.

Ideas

IMPORTANT: this is a temporary list, we will refine it in the coming weeks

Recycle / trash bin: an earlier GSoC project completed the back end functionality, so we need the Volto front end done now.

Update collective.ifttt to work with latest Plone and Volto

Create collective.zapier that does much what collective.ifttt does

Theming in Volto as add-on

A unsplash integration that allows to use images from there in Plone

Convert docstring tests to python ones, which will allow to use pytest eventually

Volto + RestAPI

Support to manage content-type constraints in Volto

  • Needs to implement the constraints support on plone.restapi
  • Needs to implement the equivalent frontend in Volto

Refactor content-rules support

  • Improve UX on the Content Rules control panel
  • Support for custom action forms
  • Move from class-based components

Refactor/improve user management

  • Improve UX for user management tasks (Add user, edit user, add user to groups, view user details.

Refactor/improve TTW type creation

  • Ensure all features available in the Classic UI are implemented on the Volto control panel

Implement Configuration Registry control panel

  • Allow users to view/edit the configuration registry

Volto

Support for custom add/edit components

  • Allow developers to implement their own Add or edit components for a content-type

Distributions

Implement a new Plone distribution with Backend and frontend components

  • Some ideas

Typing

plone-stubs / @plone/types

  • Improve coverage of both packages
  • Write a detailed guide about using typing in Plone

Bio

A bio add-on that allows you to add a bio object, and then mark the person in the bio as either a creator of a news item or the presenter of an event.

The bio page would then contain both the author bio, as well as a list of items they’ve authored or presented.

That would be useful because for a lot of sites, authors and presenters aren’t necessarily the Editors/Members of the site, and these bio pages would then be editable by actual Editors of the site.

Dev overview

Create a high-level overview of the content in a given website. Use case: a new developer joins your company and you have to explain everything that has been built on a given Plone powered website.

Create a visualization where you can see:

  • all your content types
  • list of adapters
  • list of utilities
  • list of viewlets and to which interfaces/content types are they related
  • list of portlets(?) registered
  • list of volto blocks available
  • list of custom control panels
  • list of custom events
  • list of custom rules (and where they are used)
  • list of plugins installed

And that with a fancy UI that allows searching and navigation (i.e. not just a server side rendering huge dump).

Bonus points if that can be exported with docstrings from the classes/functions that implement all of that, so you can read and reference that in a way or another.

Provide more documentation to editors

  • define, somewhere, in a control panel, the base URL for your internal documentation
  • add a way to provide a relative link (rooted to the internal documentation URL) for each field (either z3c.form or volto block) of a given content type field or behavior’s field
  • show a nice and simple icon next to each field that points the editor to that documentation
  • provide a way to generate a documentation system that can have stable URLs pointing, so the above URLs work, and editors/developers can explain as much as they need their internal policies/best practices, etc

Example use case: on a News content type, there is the company policy that titles have to be “Like This Because That’s Our Preference”, be certain characters long, have certain tone of voice, etc etc.

Onboarding new editors can be “almost” self-done as every field of every form will have its related icon that points you to the breath of documentation and policies about what to do with that field.