Hello everyone,
I am Praful Gulani, and I have been selected for GSoC 2026 to work on the project “Implementing a Formal Experimental API Framework for Django Core” and I will be mentored by Andrew Miller @nanorepublica.
Project Proposal: Link
Project Summary
This project aims to create a safe middle ground where:
-
Experimental features can be merged into the main repository but remain explicitly non-stable.
-
Users can easily opt-in to test these features in real-world scenarios.
-
The community can iterate on API designs based on actual feedback.
DEP 2 Rewrite & Implementation
The goal of this project is to completely rewrite DEP 2 and then implement it. I am starting this discussion to gather community ideas on the technical and governance approach, which will form the foundation of the DEP 2, I would love to gather your thoughts on a few key areas before drafting the DEP:
1. The Technical Approach
My proposal researches two main directions to isolate experimental code:
-
Approach A: Settings based feature flags
-
Approach B: Using Python package extras (pip install django[experimental]) to include extra code
Are there any other methods you would like to suggest? I am open to researching alternatives that might offer a better balance of safety and developer experience.
2. The Evaluation & Sunset Clause
How should we decide when an experiment ends? The current idea in the proposal is a flexible Evaluation Period where features are reviewed after each minor release, rather than setting a strict deadline. What should be the deciding factors for a feature to be promoted to stable or purged to prevent experimental bloat?
To test the logic safely, my plan is to first build the experimental framework as a standalone third-party package for the community to try. I will be following this thread closely and incorporating your feedback into the DEP 2 draft.
Looking forward to hearing your thoughts!
Best regards,
Praful Gulani