GsoC 2026 Contributor Introduction - Interested in the Experimental feature flags and processes

Mentorship Google Season of Code
1

My name is Ayman Refat, and I am a junior Computer Science student at the American University in Cairo (AUC). I have hands-on experience with backend web development, most recently building Ecenter, a Django-based online learning platform designed to support high school students in Egypt.

I think a multi-layered approach works best depending on the scope of the new feature. Here is a consolidated proposal:

1. Third-Party Packages (For massive features)
If an experimental feature is big enough, it should start as a separate, standalone package. Once it is battle-tested by the community, we can migrate it directly into the Django core as a stable feature.

2. The django.experimental Namespace (For new core modules)
For completely new classes or modules, they should live in a .experimental folder. This forces developers to explicitly opt-in via imports (from django.experimental import ...), making it obvious the code is subject to change.

3. The EXPERIMENTAL_FEATURES Setting (For tweaking existing core systems)
When modifying tightly coupled core systems (like the ORM) where namespacing isn’t viable, we can use a single dictionary in settings.py:
EXPERIMENTAL_FEATURES = {'NEW_ORM_AGGREGATES': True}

4. The @experimental Decorator & Warnings
We can wrap unstable functions/classes with an @experimental('FEATURE_NAME') decorator.

  • If it’s not enabled in settings: Raise a hard RuntimeError requiring explicit opt-in.

  • If it is enabled: Emit a native Python FutureWarning to remind developers that the API might change.

5. The Feature “Graveyard” & System Checks (To prevent upgrade crashes)
To prevent silent breaking changes when an experimental feature is eventually removed or renamed, Django can maintain a registry of retired experiments. We can hook this into the System Check Framework. If a developer upgrades Django and runs manage.py runserver with a dead feature still enabled in their settings, the server will immediately halt with a clear, actionable error.

Finally, I want to know your thoughts on these ideas for developing a solution for this problem.

Note: I combined ideas from previous suggestions in this thread and tried to enhance them with architectural patterns from other frameworks. I used AI to help structure and write this final proposal. I am very interested in this problem and would love to work on implementing this for the Google Summer of Code (GSoC) program!

2

This is a reasonable start, but misses the community aspects of this project. Django doesn’t yet have anything experimental, so before any code is written we need to formalize the definitions involved which this project and update the associated policies before any code is written.

There also needs to be consideration that most features likely don’t belong in core Django. Most belong as third-party packages as the capacity of maintaining code in core is limited, as such ought to be a consideration for this project.

3

Thanks for your response, so as I understood: I have propose new development strategy for the Django community before working on the feature itself?

4

I would familiarise yourself with the process of how new features (new-features repo) are currently developed. This project ought to directly impact parts of that process otherwise it will not be accepted or adopted by the community.

It’s not a new development strategy, but proposing alterations to the existing one where it makes sense.

Read this carefully as well: SummerOfCode2026 – Django

1 Like