# GsoC 2026 Contributor Introduction - Interested in the Experimental feature flags and processes **URL:** \ **Category:** Google Season of Code\ **Created:** [March 8, 2026, 4:23pm UTC](https://forum.djangoproject.com/t/gsoc-2026-contributor-introduction-interested-in-the-experimental-feature-flags-and-processes/44417 "2026-03-08T16:23:15Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![AymanRefat](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/aymanrefat/32/31811_2.png) [@AymanRefat](https://forum.djangoproject.com/u/AymanRefat)\ **Post date:** [March 8, 2026, 4:23pm UTC](https://forum.djangoproject.com/t/gsoc-2026-contributor-introduction-interested-in-the-experimental-feature-flags-and-processes/44417/1 "2026-03-08T16:23:16Z")
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!_ ---
**Author:** ![nanorepublica](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nanorepublica/32/14211_2.png) [@nanorepublica](https://forum.djangoproject.com/u/nanorepublica)\ **Post date:** [March 8, 2026, 4:32pm UTC](https://forum.djangoproject.com/t/gsoc-2026-contributor-introduction-interested-in-the-experimental-feature-flags-and-processes/44417/2 "2026-03-08T16:32:05Z")
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. ---
**Author:** ![AymanRefat](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/aymanrefat/32/31811_2.png) [@AymanRefat](https://forum.djangoproject.com/u/AymanRefat)\ **Post date:** [March 8, 2026, 4:39pm UTC](https://forum.djangoproject.com/t/gsoc-2026-contributor-introduction-interested-in-the-experimental-feature-flags-and-processes/44417/3 "2026-03-08T16:39:32Z")
Thanks for your response, so as I understood: I have propose new development strategy for the Django community before working on the feature itself? ---
**Author:** ![nanorepublica](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nanorepublica/32/14211_2.png) [@nanorepublica](https://forum.djangoproject.com/u/nanorepublica)\ **Post date:** [March 8, 2026, 4:43pm UTC](https://forum.djangoproject.com/t/gsoc-2026-contributor-introduction-interested-in-the-experimental-feature-flags-and-processes/44417/4 "2026-03-08T16:43:23Z")
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](https://code.djangoproject.com/wiki/SummerOfCode2026#Experimentalfeatureflagsandprocesses)