what is the biggest need for maintenance / future plans right now?

At a minimum we need someone to determine if there any release blockers for 3.15, which probably comes down to are there any outstanding PRs required in order to fully support Django 5.0? Once we've answered that then we can roll a release.

Got it. I think the discussion on#9210 is a good starting point and I'll check there if there is anything I can help with.

@tomchristie I merged this recently#9233

It should be maintained, yes. Intent should be minimal noise on here, keep pace with changes in Django and squish any security issues. It doesn't need any ongoing featurification.

The issue list since the 3.15 release is a good example of the negative trade-offs that changes to the project introduce at this point in it's lifespan...

...We'll be able to resolve those and get a new point release out, but it highlights where our priorities for the project should be.

Our policy (in my view) should be a very clear...

No pull requests will be accepted except for:

• Changes required to support newer Django releases.
• Security fixes.
• Documentation improvements.

...The project is mature, with plenty of scope for third party packages and adaptation. Further changes at this point are just creating risk, churn, and unnecessary busy-work.

This part of the documentation seems to hint at adding some features to the framework, are there still plans to add Websocket & JWT & CORs support? (https://fund.django-rest-framework.org/topics/funding/)

Or would it be better to improve the documentation?

(I apologize if this is a sensitive area, I just wanted to know what your thoughts are on this at this point).

There's no off-limit conversations here... yep those aspects of the documentation arelong out of date.

(The fundingdid help WebSockets support in Django, to the extent thatuvicorn andstarlette have been instrumental in maturing the ASGI ecosystem. And I'dprobably re-assess "bring existing third party packages into core" as a no at this point.)

I think what we actually want at this point in time is redirecting our funding pages towardshttps://github.com/sponsors/encode and figuring out how we can be dealing with sponsorships and our available funds across the whole range ofencode projects.

Hi@tomchristie, I agree with the scope you laid out above for maintaining DRF, and am interested in stepping up as a maintainer.

We discussed this in yesterday’s DSF board meeting and confirmed what others have said above, which is that we care about the success of DRF but the DSF doesn’t currently have capacity to look after more packages. We haveDEP 7: Official Django Projects as a policy when adopting projects under the Django org, however this still requires forming a maintainer team and renewing it over time. Which is the hardest part of maintenance. So doesn’t feel like it would help too much here (happy to be told otherwise).

And – people like Django Fellows who are paid to do maintenance and community support – are paid to do so for Django itself. They can work on helping with other packages as they deem appropriate, but that’s at their discretion. Everything else is volunteer-based.

Back to what the DSFcan do – collaborative package maintenance over time is a real challenge for open source communities like ours. And DRF is in use in abouthalf the projects out there, so we definitely want to help how we can.

In the short term I’ll get in touch with other people at the DSF and ask them for thoughts. Lots will have experienced package maintenance challenges for Django itself, and with Jazzband, and elsewhere. We have aDSF working groups mechanism to make Django community things happen with formal support (a budget, infrastructure, comms w/ other Django initiatives, etc). Perhaps apackage maintainers working group could be a good way to support the new DRF maintainers in the short term, and also help with open source sustainability considerations in the wider ecosystem?

In the very, very short term – ourDjango Discord server has a #packages channel, which is a good place if you want to ask maintainers for their wisdom. And not Django related but GitHub as a greatMaintainer Community which I’d recommend as a safe place to ask tough open source community questions.

DRF is in use in abouthalf the projects out there

Probably another 10%-20% of projects are doing APIs without DRF. It sounds like Django REST Framework should bebuilt into Django instead of being anoptional add-on. FastAPI and other modern web frameworks are a recognition that APIs are vital (not optional) for building modern web applications.

Valid point. Personally I’d recommend considering this separately from maintenance of DRF. See recentroadmap-level discussions on the Django Forum, in particularBuilt-In API Framework. There was interest but no one volunteering to make a more fleshed-out proposal. I’d recommend starting a discussion on the Django forum to take this further.

This came up again in discussions at DjangoCon Europe. There's no appetite to merge DRF into core, but plenty of people expressed the desire for DRF to not just continue to be maintained (in stasis) but be allowed to evolve again. (e.g. cc-ing@tfranzel, who maintains drf-spectacular was quite passionate in that camp)

As@thibaudcolas says, I think the DSF taking it on is only feasible if we can answer the maintenance question. That would need to be a paid role, as for all the discussions I had,nobody said thatthey were prepared to take on DRF on a volunteer basis. Everyone wants DRF maintained as long as they're not the one doing it, it seems. 🙂 That's totally understandable, but it clearly highlights how any solution here needs to look.

I personally have drifted too far from DRF and am not able to maintain it even on a paid basis.

Having a release process in line with Django's iscertainly a good idea.

Perhaps someone would be motivated in drafting a change to theproject management docs which are somewhat out of date.

the same people will do the heavy lifting.

The lifting here should mostly consist of... improving the docs, making sure we've got a nice safe release process, handling security issues, dealing with any updates strictly required by newer Django versions, and helping say "no" to pull requests and issues.

should appoint a release manager.

I'm unsure how we should handle that. Interested individuals could self-nominate in this thread as a starting point, perhaps?