How do we feel about the DRF situation?

[nanorepublica]

When I say 'we' above I'm referring to the Django commons members.

Is DRF a repository that could be migrated here? I expect it would require the support of Tom for it done respectfully.

Does it fit with the existing processes we have in place?

I'm just asking questions at this point, but my general expectation is that a call with Tom from someone who knows him well is probably the best course forward.

encode/django-rest-framework#9186 (comment)

[browniebroke]

How do we feel about the DRF situation?

Tom has been quite transparent about wanted to wind down the development efforts for a few months now. However, I was still surprised and found the shutting down of issues and discussion quite sudden. A project like DRF is too big to just go away now suddenly, it's used in tons of organisations and will definitely live on somehow. How is up to the community.

Is DRF a repository that could be migrated here?

Technically, I don't think anything preventing this, and IMO django-commons is best placed to be a new future home. I found it has a great way of managing access to repos and the multi-admin by default avoid a BDFL bottleneck. A few potential challenges to overcome for transfer might be around the domain django-rest-framework.org and where the docs are hosted (which I think is GitHub pages now), but the bigger one is more to get support/approval from Tom.

Failing a transfer, the community will most likely start to maintain forks... Could django-commons be the home of the main one? I would hope so.

PS: I started to help with triage a few months ago and started helping the maintenance a few weeks ago and would like to help maintain a potential fork/transferred repo.

[bckohan]

Agree with @browniebroke

For the health of the broader Django ecosystem the goal here should be to avoid a bunch of forks - which will definitely happen unless development restarts.

I depend heavily on DRF and it'd be easier for me to help maintain it than rework a bunch of perfectly fine legacy code.

The big challenge here is the size and scope of DRF usage. This necessitates a governing structure with a healthy skepticism of all the new hotness and a steady hand to incorporate new stuff that makes sense. If we move into django-commons we should avoid the appointment of a defacto new BDFL.

[nanorepublica]

It would seem to me there are 2 next steps if django-commons were to adopt DRF:

1. Gather a list of new maintainers & contributors that would be ready to take it on. I would suggest 3 at a minimum for this to aid in burnout etc of the new maintainers and prevent a new defacto BDFL.
2. Someone to reach out to Tom to see if he is open to the idea of a transfer? Perhaps someone who has a history of contribution to the project in the past and is still active in the community? A first step might be identifying potential people to do this?

[tim-schilling]

I think the team size is a bit dependent on the work that's going to be done. Keeping DRF open to new issues, addressing security concerns and keeping it relevant with the latest version of Django may not require a ton of effort. Where things differ is if a person wants to actively change how something works.

[ulgens]

I just came to start this discussion and I'm happy to see it's already open and going 🙂

I've been a supporter of this migration and pushing it since the day Tom created a discussion for the project's feature (which is no longer accessible, here is a web archive link). My first recommendation was DSF, knowing that DSF doesn't exactly maintain packages, but I was thinking that it's the best place to come up with a solution. Now we have this organization in place, and hopefully, django/dsf-working-groups#19 will be a thing soon, I believe that the mission definitions of these organizations' cover the empowerment and/or maintenance of tools like DRF.

I also don't believe that DRF is feature-complete. It may not need new features as much as before, but the web is an ever-changing organism and saying an API wrapper won't get new features roughly translates to "We won't be following the modern tech and let the tool die." And tens, if not hundreds, of bugs and performance issues still exist.

As we all know, Django doesn't have an internal API layer. With the web becoming even more automated each day, API tools are becoming a vital part of web frameworks. I'd say that DRF is one of the things that makes Django what it is today, and even though it's sold separately, it's one of the batteries people plug in first. Letting it die like this would hurt the ecosystem and cause Django to lose momentum.

[bckohan]

Yeah, a quick look at pypistats shows you how important it is. It has roughly half the downloads that Django itself has. Since this mostly tracts CI workflows its fairly safe to say ~50% of professional Django projects are using it. Thats critical. If it slowly dies, there's pretty serious risk of the perception of deadness leaking onto Django itself.

[nanorepublica]

On the packaging working group, I think that is currently stalled until someone interested wants to be chair (Thibaud is unlikely to do this as he is president this year) and move the PR forward in terms of refining the document to a state ready to be voted on.

[thibaudcolas]

Yep, for now I’ve closed the working group proposal and made it clear how I think others could proceed. I still do a lot of packaging work and am happy to be involved in discussions but don’t have capacity to join more working groups.

[tomchristie]

To further illuminate on this... REST framework is complete more-or-less. Given its size it is imperfect, tho being parked and pushing back on net negative changes is a positive quality for the project at this stage in its lifetime.

Making sure there's hard boundaries in place reduces both risk and also unnecessary busy work.

I've been maintaining the project for more than a decade, and I'm acutely aware of the tendency for pressure to be applied in issues and PRs that end up to the detriment of the project.

I'm not necessarily against talking through proposals for new maintainership, tho I've not seen anything compelling, or that demonstrates what I'd consider to be a full awareness of the trade offs here.

[tomchristie]

👋🏼 I'll be right here.

I don't much care what position I occupy within that, tho I do have a long term view onto the elements of the project that other may or may not have. And I do feel some sense of responsibility in terms of taking a call on any proposal to move the project.

Some points for any maintainance proposal to consider perhaps?...

• Does django-commons (or wherever) demonstrate a more inclusive and welcoming environment for the project?
• What future "development" are any new maintainers proposing? Be specific.
• Can a new maintainence team demonstrate awareness of the trade-offs between "forward progress" and risk of change. Is there a full understanding of why is the project currently pushing back on almost every suggested pull requests.
• What funding approach would a new team be proposing?
• What elements would be functionally (or emotively?) different if the project existed under django-commons than under encode?
• Why is there an assumption that the project being in a neutral parked state is a negative. Is that assumption valid?

As I see it, the most pressing issue with the encode/django-rest-framework property is that it has become swamped as a male-presenting environment. This affects the style and direction of the project. How it feels to work on day-to-day. It's an online environment that does not give me warm fuzzies and isn't reflective of our off-line working spaces, conferences, and businesses.

That's about as much as I can say about it for now.

---

I expect it would require the support of Tom for it done respectfully.

This made me laugh. Yeah, I'd hope so.

I was still surprised and found the shutting down of issues and discussion quite sudden.

That's valid and understandable yes. I'm reseting some expectations here, and the discussion is ongoing. I am much more willing now to put hard & fast boundaries in place where I feel they are needed.

It has roughly half the downloads that Django itself has

Okay, so... Important that we're creating a working environment that we actually want to be part of.

but my general expectation is that a call with Tom

Ah yeah I think there's wisdom in that. So much easier to get across nuance and actually build working relationships than text-speak.

[tim-schilling]

I wanted to clarify two of the questions because they may be read as directed at the Django Commons org.

Does django-commons (or wherever) demonstrate a more inclusive and welcoming environment for the project?

This would be more up to the maintainers of the project than the broader community.

What funding approach would a new team be proposing?

This would likely be dependent on the team specifically rather than Django Commons as an org. We're still investigating options to fund Django Commons as w hole, but it's very murky. Funding a specific set of people is much more managable from all sides currently.

[tomchristie]

This would be more up to the maintainers of the project than the broader community.

That's very perceptive Tim, yes.

Funding a specific set of people is much more managable from all sides currently.

This is true.

There's also something to be said about the value of small teams, and slower more considered conversations here.