GSoC 2026: Implementing a Formal Experimental API Framework for Django Core

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

4 Likes

16 posts were merged into an existing topic: Implementing a Formal Experimental API for Django

  1. I can’t think of anything else that would be needed at this point, we may discover a third thing we need once we’re doing it, but this looks complete to me.
  2. I think every experiment is going to have a different lifespan and that’s ok. The only thing we should agree on is that if an experiment is added in version X.Y.Z (or future YYYY.X) that it will remain in AT LEAST that version. I think some experiments might live on for 2 maybe even 3 versions before we make it permanent or remove it, but most would likely just be experimental for one version. I think it will be up the Steering Council to review all experiments and sunset any as they see fit.
2 Likes

Hi Frank,

Thank you for the feedback!

After posting this initial thread, the discussion shifted from how to implement this to why we need this project.

Could you take a look at these two threads and share your insights when you have a moment?

I’d highly value your thoughts on either of those threads, your experience with Django’s governance would be incredibly helpful in shaping the DEP 2 draft.