🛬 [INBOUND] - django-rest-framework

[browniebroke]

What's the URL to the project?

https://github.com/encode/django-rest-framework

Who are the current maintainers?

@auvipy @browniebroke @carltongibson @peterthomassen @tomchristie

Other maintainers

Less active lately

@adamchainz @jpadilla @kevin-brown @pauloxnet @rpkilby @tfranzel @xordoquy

Does the project have the required attributes?

• Are you a member of the Django Commons organization? (if not, open an issue to add yourself as a member)
• Does the project have tests?
• Does the project have documentation?
• Has the project adopted Django Commons's Code of Conduct?
• Do you have permissions to transfer the repository to the Django Commons organization?
• Does the project use readthedocs for documentation? No

Who will be the new maintainers of the project?

Same folks

Do you use test PyPI or want to test the packaging process?

• Does the project have a test.pypi.org project?
• Would you like to test your deployments with uploads to test.pypi.org (you'll need to create the project first)?

[github-actions]

User django-rest-framework does not exist.

[browniebroke]

"django-rest-framework" = {
  description         = "Web APIs for Django. 🎸"
  # Different merge strategies can be enabled/disabled
  allow_merge_commit  = false # Allow merge commits on pull requests
  allow_rebase_merge  = false # Allow rebase and merge commits on pull requests
  allow_squash_merge  = true # Allow squash and merge commits on pull requests - Recommended
  allow_update_branch = true # Allow updating source branch on pull requests
  
  has_discussions     = true # Enable discussions in project's repository
  has_wiki            = false # Enable wiki in project's repository
  admins = [
    # Include people who can release new versions
    "browniebroke",
    "carltongibson",
    "tomchristie",
  ]
  committers = [
    # Include people who can commit to main / merge changes
  ]
  members = [
    # Include people who can assign/triage tickets
  ]
}

[browniebroke]

Following from https://github.com/orgs/django-commons/discussions/166, we discussed with @tomchristie and @carltongibson at DjangoCon EU the possibility to migrate DRF to django-commons and decided to start the discussion here, to see whether there are any blockers.

From my perspective, the main blockers I see are around funding and ownership of the django-rest-framework.org domain.

• There is a dedicated funding page on a subdomain. Where does this money go? Should we keep this page and if yes, where should the funding go moving forward?
• Does django-commons have any existing structure for owning domains? Or should it remain under the control of the project admins?

Tom raised a few more concerns in the original discussions.

[auvipy]

may be we can just create a new org named DRF / DjangoRESTframework and move the drf project there?

[lovelydinosaur]

Moving the project to a new organisation is helpful if it provides an opportunity to seed new funding and fresh maintainership.

Same folks

I wouldn't want that no.

Something like a three person team would be sufficient. Project "maintainership" here should reflect something meaningful - project admin rights & deployment keys.

Additionally we should be strict about boundaries here - there's a chronic issue on GitHub with low quality issues & attention spamming, there's no need for us to be overly generous in how we tackle that issue.

There is a dedicated funding page on a subdomain. Where does this money go? Should we keep this page and if yes, where should the funding go moving forward?

Sponsorships fund https://www.encode.io/ - eg. in addition to REST framework the Uvicorn, Starlette & httpx projects were all authored as a result of the funding.

If we do move REST framework then existing sponsorships would remain as they are.

The new maintainence team would deal with any future project sponsorships, eg. with a view to helping fund a new django fellowship position.

There's plenty of scope for the guidance to be much more pushy wrt. recommendations for sponsorships being a requirement for corporate usage.

Does django-commons have any existing structure for owning domains? Or should it remain under the control of the project admins?

Practically I don't think there's any substantive issue here. Encode OSS currently owns the domain, and would be in a position to transfer it if there was a compelling reason to do so.

[tim-schilling]

It appears that this would transfer the project in with a reduction of existing maintainers for the project. My understanding was that the project was looking for new people to get involved and shepherd it along. It appears @tomchristie you second that understanding:

Moving the project to a new organisation is helpful if it provides an opportunity to seed new funding and fresh maintainership.

If that's the case, discussing a move to Django Commons is a bit premature. The next set of maintainers needs to be identified first, then Django Commons can be evaluated as a potential home (or as @auvipy suggested, creating a new org). If someone can lead that search/recruitment effort, that would be great. @tomchristie has laid out some excellent points in another discussion that will help guide people and understand the challenges of maintaining DRF.

[lovelydinosaur]

I think it'd be rather lovely to get this landed. I've been in a maintainership position since the project's release in 2011, and have been thinking about stepping back since a long time ago. Having the project settle into a new home under the banner of django-commons just seems like the right thing to do.

The next set of maintainers needs to be identified first

In that case I don't have any objection to the OP suggestion, and I'm happy to stay on in the background to deal with whatever security or handover issues crop up. I'm open to other leadership suggestions, tho Bruno has been the primary maintainer of late, so I'm likely to be plenty okay with whatever guidance he suggests.

[browniebroke]

OK, I think we've left this settle long enough... Carlton helped push the last few releases but I believe his efforts are more directed towards other initiatives lately. If that's correct, that leaves 3-4 of us who are active maintainers. We can start with the most actives ones for now, as we're focusing on the project stability.

may be we can just create a new org named DRF / DjangoRESTframework and move the drf project there?

From my perspective, moving to @django-commons org is preferable (vs creating a brand new DRF one) mainly for the simple reason that it's less admin work (at least for me). The way the org is structured reduces the bus factor massively, offering better garantees that the project will stay around. If we create a new org with the 3-4 current maintainers, we'd be running pretty thin, e.g. if a couple of us move on...

In terms of seeding new maintainers, I know a bunch of folks have joined the org as they wanted to contribute more, so maybe there is an opportunity here.

Would love to move this forward 👍🏻

[carltongibson]

@browniebroke Yep. I'm happy to hang around if there's still value in that, but beyond that I'm focused elsewhere as you say.

[auvipy]

We can start with the most actives ones for now, as we're focusing on the project stability.

you can also count me in the maintenance effort.

[browniebroke]

I've just been reminded that there is sibling repo for the DRF tutorial: https://github.com/encode/rest-framework-tutorial. It would be nice for it to be part of a potential transfer.

[browniebroke]

One pre-requisite to move this forward would be for the maintainers to join the @django-commons org. Folks can request to join by opening a new memebr issue here: https://github.com/django-commons/membership/issues/new?template=new-member.yml

[browniebroke]

What are the next steps required to move this forward? I think we usually have a call with the admin team... I'm on vacation next week so realistically I won't be available until the 25th of August.

[ryancheley]

@browniebroke would you and the other maintainers be able to attend the admin meeting on August 29 at 1700 UTC? That would likely be a good time to review the next steps. Since this is such a large and established project we thought it might best to do some pre-planning to review any potential “gotchas” before the actual migration call. If that won’t work would you be able to provide 3 different days / times that might work for you?