# \[GSoC 2026 Proposal Draft\] Experimental Feature Flags in Django

**URL:** <https://forum.djangoproject.com/t/gsoc-2026-proposal-draft-experimental-feature-flags-in-django/44734>\
**Category:** Google Season of Code\
**Created:** [March 27, 2026, 2:41pm UTC](https://forum.djangoproject.com/t/gsoc-2026-proposal-draft-experimental-feature-flags-in-django/44734 "2026-03-27T14:41:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mikko2577](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/mikko2577/32/32064_2.png) [@mikko2577](https://forum.djangoproject.com/u/mikko2577)\
**Post date:** [March 27, 2026, 2:41pm UTC](https://forum.djangoproject.com/t/gsoc-2026-proposal-draft-experimental-feature-flags-in-django/44734/1 "2026-03-27T14:41:55Z")

</div>

Hi everyone,

My name is Jiachan Li, and I am a Computer Science student at Northeastern University, currently focusing on software engineering and AI. I am very interested in contributing to Django through Google Summer of Code 2026.

I would like to work on the **“Experimental feature flags and processes”** project, and I would greatly appreciate any feedback on my proposal draft below.

* * *

### Problem Statement

Django’s strong commitment to backward compatibility makes it difficult to experiment with new features directly in the core codebase. Once an API is released, it becomes hard to change or remove, which slows down innovation and iteration.

An experimental feature flag system could provide a safe mechanism for introducing and testing new features without breaking stability.

* * *

### Proposed Solution

I propose introducing a structured experimental feature system with the following components:

1. **Settings-based feature flags**

```auto
EXPERIMENTAL_FEATURES = {
    "NEW_FEATURE": True
}

```

This allows developers to explicitly opt into experimental functionality.

* * *

1. **`django.experimental` namespace**

```auto
from django.experimental import new_feature

```

This makes it clear that a feature is unstable and subject to change.

* * *

1. **`@experimental` decorator**

- If the feature is not enabled → raise a RuntimeError

- If enabled → emit a FutureWarning

This ensures both safety and visibility.

* * *

1. **System checks for deprecated/removed features**

Django could track removed experimental features and provide clear errors if users still enable them.

* * *

### Implementation Plan

**Phase 1 (Weeks 1–2):**

- Design API for feature flags

- Define decorator behavior

**Phase 2 (Weeks 3–6):**

- Implement settings-based flag system

- Add runtime validation and warnings

**Phase 3 (Weeks 7–9):**

- Integrate with selected Django components (e.g., ORM or templates)

- Write comprehensive tests

**Phase 4 (Weeks 10–12):**

- Documentation and examples

- Incorporate community feedback

* * *

### Expected Outcomes

- Safer experimentation within Django core

- Faster iteration on new features

- Reduced risk of breaking changes

* * *

### Questions

I would really appreciate feedback on the following:

- Is this combined approach (settings + namespace + decorator) appropriate for Django?

- Is this scope reasonable for a 350-hour GSoC project?

- Which Django components would be best for initial integration?

* * *

Thank you very much for your time and feedback!

---

<div class="post-metadata">

**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 27, 2026, 3:00pm UTC](https://forum.djangoproject.com/t/gsoc-2026-proposal-draft-experimental-feature-flags-in-django/44734/2 "2026-03-27T15:00:46Z")

</div>

Hi there,

I would advise you go back and read our GSoC wiki, the [feature](https://github.com/django/new-features/issues/3)request and DEP 2. Your current proposal makes a fair number of assumptions which may not hold up to examination. This proposal doesn’t show any understanding of the feature development process that Django uses and what would be appropriate for us in the experimental process.

This project is more process oriented over getting code into Django to begin with.

Thanks

---

<div class="post-metadata">

**Author:** ![mikko2577](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/mikko2577/32/32064_2.png) [@mikko2577](https://forum.djangoproject.com/u/mikko2577)\
**Post date:** [March 27, 2026, 3:17pm UTC](https://forum.djangoproject.com/t/gsoc-2026-proposal-draft-experimental-feature-flags-in-django/44734/3 "2026-03-27T15:17:23Z")

</div>

Thank you for your feedback!

I realize now that I focused too much on a technical implementation rather than understanding Django’s feature development process.

I will go back and carefully review the GSoC wiki, the feature request discussion, and DEP 2 to better understand how experimental features should fit into Django’s development workflow.

I’ll revise my proposal with more focus on process design and come back with an updated version.

Thanks again for pointing this out — I really appreciate the guidance.

---

<div class="post-metadata">

**Author:** ![mikko2577](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/mikko2577/32/32064_2.png) [@mikko2577](https://forum.djangoproject.com/u/mikko2577)\
**Post date:** [March 28, 2026, 4:20pm UTC](https://forum.djangoproject.com/t/gsoc-2026-proposal-draft-experimental-feature-flags-in-django/44734/4 "2026-03-28T16:20:20Z")

</div>

Hi @nanorepublica,

Thank you for the detailed feedback — I appreciate you pointing this out.

After going back to the GSoC wiki, the feature request discussion, and DEP 2, I realize that my previous proposal made several assumptions about implementation (such as feature flags and APIs) without first grounding them in Django’s existing feature development process.

I also understand now that this project is primarily about defining and aligning process, rather than introducing a specific mechanism upfront.

In particular, I see that I did not sufficiently account for:

- how new features are proposed and discussed (e.g. new-features repo, community consensus),

- how DEPs are used to formalize changes,

- and how backwards compatibility and deprecation policies influence what is acceptable in core.

Based on this, I will revise my proposal to focus on:

- defining what “experimental” should mean in the context of Django’s existing processes,

- describing how experimental features would move through proposal, discussion, and acceptance,

- and clarifying how this integrates with DEPs, release cycles, and deprecation expectations.

Any implementation ideas will be treated as secondary, and only introduced if they clearly support the defined process rather than drive it.

As a next step, I will revisit DEP 2 in detail and review recent discussions in the new-features repository to better align the proposal with current thinking.

If you have any suggestions on specific discussions or examples I should study, I would really appreciate it.

Thanks again for your guidance — this was very helpful.