Experimental feature flags and processes
I saw this project and I though what if whether experimental features could live under a dedicated namespace such as django.experiment.
This would require developers to explicitly import experimental APIs (e.g., from django.experimental import new_query_api), making the opt-in intentional and visible in code.
I am a student in my undergrad and I would like to contribute in it as I have experience in working with and also it was my first framework that I learned. I have made lot of projects via django which is present in my github. I would like to know if we could solve it via experiment library.
It is relatively rare where a new feature needs to be part of Django itself.
Django is quite extensible via third-party packages. That is the general recommendation for the implementation of new features. Create your feature as a separate package that can be installed.
This works for completely new features, however if we wanted to add experimental features into existing features, then this needs an alternative solution.
Just a quick note, that this project will start with mostly documentation and gaining community consensus.
I agree that most new features should be in third-party packages.
But I see the experimental feature flag idea a bit differently. It seems more about creating a safe process for testing potential core APIs before they become stable, rather than adding new functionality directly. I believe it might need to be hadled at django core level instead of as a separate package
It depends upon the specific feature in question.
When all else fails, it’s always possible to monkey-patch a module.
Can you identify a specific feature that you are thinking about that can’t be modified using an existing option?
As asked above, can you identify a specific feature that would require this? (Something that can’t be tried and used via currently-existing options.)
When Django transitioned from url() to path(), both APIs coexisted before deprecation, but the new API was immediately part of the public, stable interface.
I was wondering whether an experimental mechanism could allow significant API changes (for example in the ORM or model field APIs) to be iterated on more freely before being covered by long-term backwards-compatibility guarantees, rather than relying on third-party replacements
I’m talking generically at this point and that’s not to it won’t use existing techniques. The project is about progressing DEP 2 among other possible new DEPs.
This has been accepted by the Steering Council as a GSoC project for this year and I have agreed to be the mentor.
1 Like
Okay. So the focus would be on refining or extending the DEP process itself like DEP 2), rather than directly implementing a technical feature flag mechanism at this
I hope we get to do both, but the initial steps are about definitions, what the process could be and getting agreement on this.
Then we would be in a position to consider the technical implementations required to support that process (if there are any)
So what could be its lifecycle of it I mean how will we start and what should be our expected output
Side note: You can edit your messages after the fact, please stop double replying.
If your selected, the start would be crafting a proposal (or a several) for the community to discuss. The output to begin with would be updated documentation in the first instance.
thanks for the side note. So the first part would be discussion with the community accoding to that we will proceed , that looks like a good start. I will review DEP 2 and other documents to better understand how such updates could be framed clearly and practically. If i get selected It would be great to work with you and the whole django community.
1 Like
After reading the DEP process, I believe that this would fall under a Process DEP. The first step would be drafting a proposal and refining it through community discussion. Once there is a agreement, the Steering Council would make a decision, and implementation would follow.
Please let me know if I am understanding the workflow correctly.
1 Like
Let me check and get back to you.
1 Like
I had a question regarding the process.If the first step is drafting a proposal and discussing it with the community, would the gsoc contributor be involved in preparing that proposal and guiding the discussion? and if the proposal is discussed with the community and there are significant objections or the approach is not accepted, how would the project typically proceed in that case?
@nanorepublica I have been reading DEP and recently steering council released their meeting discussion. I Believe that the experimental library that we have been discussing could solve or atleast could be the first step for technical governance reform. I think by providing the structured environement for new features, without implementing for long term, this would also decrease the burden on the maintainers. I have been reading DEP, it specefically addresses the capacity does our approach aligns with it? .Please let me know am I following it right?
The technical governance is nothing to do with this project. That is do with how the community manages who is in what roles and how people get chosen for said roles.
There is an existing process for proposing new features within the new-features github repo. We will be exploring how to modify this to allow for experimental new features into Django. I need to refresh my understanding of DEP 2 before commenting further.
okay thanks for the clarification sir, I misunderstood technical governance.
hi @nanorepublica I believe you must be researching about DEP 2 for our project. As you might know, the GSoC proposal application period begins the day after tomorrow. I would like to ask for your advice on what I should mention in my proposal. Should I include my contributions to Django tickets, my previous experience, my experience with open-source contributions, and my achievements?
I would appreciate your feedback so that I can write a proposal that aligns with the Django community and the project requirements. I hope I get the opportunity to work on this project for the benefit of the whole Django community. @KenWhitesell your advice would also be appreciated