Exploring Social Issues: From third-party package to Django core

Hello everyone,

I want to learn about the non-technical challenges you face when trying to get a new feature into Django. As we know, that the first step for any new feature is often a third-party package built and distributed on PyPI. The new-features repo helps create visibility and a process around these ideas, but there are some social issues during this process that I’d like to explore.

I would love to hear about your experiences on these points:

How hard is it to get meaningful community feedback on a new feature idea before it’s completely finalized?

Imagine you built a third-party package to solve a specific Django problem. How challenging is it to market that package to get the community to adopt it and suggest improvements? Does the requirement to drive adoption so that the API becomes “tested enough” for core act as a major bottleneck?

At some point the third-party package is stable and has decent usage and you might decide to merge it into Django core. However, that process often starts a new round of design debates. What are the social hurdles that prevent a successful package from graduating to core, and how does the community reach a consensus on when it has been “tested enough” to move?

Does the pressure to get a design 100% perfect before merging makes the contribution or review process exhausting?

Some features cannot easily live as third-party packages because they require deep integration with Django’s internals. How often do these ideas stall simply because there is no way to test them safely in the real world without a design deadlock?

I am really interested in understanding these bottlenecks. What are the biggest social or communication hurdles that cause features to lose momentum or contributors to step away?

3 Likes