How we make decisions in Django

Speaker 1: Note to self submit a technical talk. Hello everyone Carlton. Um this is me, um Carlton Gibson. Um I'm Carlton Gibson on GitHub. I'm Foster on there, I've got a website. Um I've got a blog, there's an RSS feed, you can subscribe to that. What else? Got a podcast, Django Chat with my friend Will who says there we um have a podcast is pretty old school. Thank you One listener. Um we have guests from around the community and we chat about Django. Do check that out if you haven't had a listen. Um if you don't know me, between 2018 and 2023 I was one of the Django fellows The fellows are contracted by the DSF, the Django Software and Foundation, to do the day-to-day maintenance on Django. They do ticket triage, pull regress review, releases, security fixes, the stuff that keeps makes sure that Django keeps going.

Speaker 1: I'm still around, I'm on the security team, I maintain a few packages, but in December I was elected to the Django Steering Council for the 6. 0 cycle, along with um some other members. Today's talk, it's a bit of a difficult one. It's about how we make decisions in Django. I must have drafted it about 300 times over the last few months. In the run-up to the steering council election, there was a lot of concern. Several social media threads and some blog posts about Django's contributing process Several folks ran for the steering council specifically to look at addressing that contributing process. And so I want to try and give a bit a little bit of context to that. Note to self-water. Let me begin with a disclaimer.

Speaker 1: These are just my thoughts today. They're not unconsidered, and I don't think they're a million miles from things that other steering council members might agree with, but well maybe. But there's certainly not official storage steering council policy or positions or anything like that. And you might think that I'm totally wrong, which is great. You can tell me afterwards, but don't shout at me, okay The bottom line is that contributing to Django is hard. Tick uh tickets for new ideas that get opened on Django's issue issue tracker track And that's not the right place for them. Um Django's established workflow is that new features are discussed on the forum before we open a ticket. So those tickets get closed as one fix and then there's the people are sent to the forum. Because they're marked as poke

Speaker 1: uh as won't fix pending the di any decision, they we can always reopen them, but folk folks see that won't fix and they feel like they've been shut out before the process has even begun. On the forum then that the idea gets proposed and either we have no one ever responds or there's a really long and massive discussion that goes on and on and on and on and on. More oftentimes than not, the discussion peters out without a clear resolution, and then well, what happens at that point? Well no idea. Like there is no resolution. Normally nothing happens. If we do get to an accepted ticket, Django's coding standards mean that it's hard to get a PR merged. The code review is tough, particularly for new contributors. And so on, right? If you've been around Django for a while, I'm hoping these scenarios kind of sound familiar.

Speaker 1: Certainly it isn't new. I gave a talk at DjangoCon Europe in 2018 when I just started as a Django fellow. I talked about getting patch into Django and how there'd be lots of review. Lots of comments, right? We'd work through it with you, we'd get your patch ready, we'd make sure everything would be right, and then we'd go to track and we'd mark it as ready for checking. Right? And then there'd be another review. There'd be more comments Getting your code into Django has always been difficult. There's a quality bar. It's one of the reasons why Django is so reliable. There's always been pushback on new features. We can't accept everything, not by a long way. Sarah's talk yesterday was essentially about how we can't really do much more than we already are at our current capacity level.

Speaker 1: Long discussions, well on the forum, they're no different than those that used to happen on the Django developers' mailing list. Not really. So I think these problems aren't new. but rather that maybe they've built up slowly as Django gots has gotten older. We all know the story, right? Once upon a time in Kansas, a small team got together in the basement of the Lawrence Journal World and created the web frame that framework that we would come to know as Django. I don't know, if you don't know this history off by heart, Frank Wiles gave an amazing talk at DjangoCon US last year where we went through it in detail. But Django is 20 now. Yay, 20! For years now, Django has been either the leading or amongst the leading JPython web framework. It has 20 million downloads a month, millions of users, countless deployments.

Speaker 1: Well, what worked for a small team and even a small community online doesn't necessarily work when you scale it up. Django has always looked for consensus. Well, consensus, what does that even mean? Certainly it can't be, it doesn't, it isn't and can't be that everybody always agrees. Django has so many use cases that there is almost no proposal that is suitable for everybody. So if you ask everybody's opinion, and if consensus has to mean everybody agrees, well no wonder we never get there. This is just a problem about scaling up the community. In Django, we say that Django is first and foremost it's a community and then it's an ecosystem and only finally it's a web framework. So the actual Django bit in Django is the is the least of it The web framework is amazing. It lets us solve the web problem quickly, but by itself it's not the reason that we do half the things that we do.

Speaker 1: It's the community. It's the friendships we make. It's the relationships we build. That's the point of it. That's why we come back every year. And that community is built on the individual efforts that we each put into it. Be that code or be that organizing a conference like this one or a local meetup or answering questions on the forum or whatever it is. But the community is much more than those individual efforts. The community is a shared resource. It's a commons, right? It truly is. And I think that's wonderful. In 21st century, and we have a commons You get to be a part of it. So one thing we can think one way we can think of community that and that can help us think about consensus too is to think of the community as trust. In in smaller groups, trust is easier.

Speaker 1: Consensus never meant that everybody always agrees about everything. A better way of thinking about it is that even though I don't agree I know that my viewpoint was adequately taken into consideration. In a small group where I know everybody and everybody knows me, it's easy to trust that my viewpoint was considered. That enables me to let go. As the community grows, not suddenly but over time, people become anonymous to me and I to them. I can't trust that my viewpoint was considered, how could it be? And so I'm forced to defend it, of course Well what does this mean? It means well for every proposal for change ends up in the long grass. There are other ways we can think about community

Speaker 1: We can think about community as a set of norms, how we behave. The code of conduct is an obvious Example here. As the community gets bigger and more anonymous, it's harder to maintain the code of conduct. It becomes necessary to signpost it more aggressively. People new to the community. Sorry, no spoilers People new to the community they don't know about the code of conduct. We have to tell them. But it's the same with code. There are a million ways you can solve the web problem. So if you are if you were to ask me, well, why Django? Like what what's really unique about it? I would ultimately point to its support and API stability project uh policies and things like that. Django's long-term can continuity over time.

Speaker 1: Django is the web framework you can rely on. You build your application on Django and it's still going to be with you more or less as as is in five or even ten years time The value of that over the software development lifecycle is immense. What that means is that we don't arbitrarily break things without consideration. Yes, we know the forms API is a bit crusty. Well, so would you be if you'd been around so long, right? Right? We need to evolve it, no problem. But we need to do that with sensitivity, not burn it down and build a new a new one that would be totally problem-free, of course. We get we've got the deprecation um policy. We use it every single release. Lots of people think we use it too much. Too much change in Django. But we can't just make radical changes outside that process, so please don't suggest we do.

Speaker 1: That's a norm, right? That's part of what it is to be in the G Django community. But new users don't know that We can think of the community as reciprocity. The community is maintained by what we all put back into it. We all take from it at times. This is what Sarah was talking about yesterday. We all get something from it. New members often take more than they give. They need help. They need orientation. That's all totally normal. It's healthy. As time goes by people goes by, people begin to give feedback or to pay it forward. But the open contribution model that's enabled, particularly by GitHub, mean that the level of transitory engagement that never deepens, which has always been there, is just pumped up to a much higher level until it drowns out the effort that we can all give

Speaker 1: So whether it's on the GitHub issues or the or the on Django, we have a forum, we we get worn out. Here's a quote from um Tim Schilling. So it's the biggest takeaway for me is that if we want to see change in the number of contributors or people who contribute to Django, we have to take time to maintain in ment in mentorship. This is the Django Nort Space Programme. Tim was involved in that. He's now on the Steering Council. The point is that with the noise levels so high, it's really hard to find the space for for that mentorship. And so JangoNort. space created a much smaller, safer environment where that mentorship is allowed to happen. But in the forum we have, it's really hard to give that effort because there's just too much noise.

Speaker 1: The other aspect is code. So Daniel Stenberg who maintains code says once you once merged you own it, right? This was again one of Sarah's points yesterday. He says contributors sending improvements and pull requests to an open source project could be viewed as your friendly neighborhood people helping you shoveling out sand into a pile. The actual resulting pile of sand is yours, on your land. You get help to make the pile better or faster, sure, but the people hanging out do not consider the sand to be theirs in any way. It is yours. A maintainer of a project is someone who actually feels some responsibility or co-ownership for the pile. But most contributors never end up as maintainers Again, this is what Sarah was saying yesterday. Most folks make the PR they need, but then they don't stick around to help maintain it.

Speaker 1: That's totally normal. But as the project grows, it necessarily becomes more conservative, more guarded, because I might not want your pile of sand So community is reciprocity. In the end, I see community as context. It's the context within which we have to make our decisions So what I think helpful is here is to think about the technology adoption lifecycle. This picture is from Wikipedia, right? Here you have a distribution of users segmented by how quickly they adopt a new change or techno or a new or a change in technology. At the leading edge you've got innovators followed by early adopters, then early majority, late majority and laggards. And the question for us is what's the shape of this curve for Jenga? Is it weighted towards the early or towards the late adopters?

Speaker 1: It's difficult to know exactly, right? We don't have telemetry or anything like that. There's a lot we can't see, but I think we can estimate it quite well Maybe there are some lone genius coders out there, but in general, early adoption isn't something you can do in a vacuum. I think it's a fair bet that the vast majority of innovators and early adopters will be part of what we might call the visible Django community They'll come to Django Cons. They'll subscribe to the Django News newsletter. They'll listen to the Django chat podcast. They'll respond to the annual Django Developers Survey. They'll be on the forum or the Discord or whatever. They'll pop up somewhere Okay, well Django is downloaded about 20 million times a month. Using that figure and some simple heuristics, Jacob Kaplan Moss at the last DjangoCon US estimated the Django user base as in the low single millions

Speaker 1: So that's a reasonable estimate for the number of Django Q um users. Well then it's no secret that the Django News newsletter has a low single thousandths number of subscribers. The Django Chat podcast has a low single thousands number of listeners. And when we do the annual developer survey with JetBrains, we get the same low single thousands number of responses. The overlap in those sets won't be perfect, but it's going to be pretty high. So what that means is that the visible Django community uh is to an order of magnitude about 0. 1%, a thousandth of the total user base. So even if those figures are way off Even three times the numbers, five times the numbers, ten times the numbers even. It's clear that the Django user base is weighted heavily around early majority, late majority, and laggards rather than in

Speaker 1: innovators and early adopters. And so even if those people aren't us, right? Even if we want to push forward faster, we need to make sure that their needs are given due weight in our decisions. So I think that number seems about right. About a thousandth of the user base as early adopters. Whilst I was writing this talk, Thibault, who's the DSF president, member of the accessibility team and Wagtail Core team, put up this graph on Mastodon. It shows sorry T bove I robbed this like uh it was too good. It shows the percentage of downloads um from PyPI for Django that are of a supported version, one that's in mainstream or extended support Currently that means Django 5.

Speaker 1: 2, the latest release, which is the new LTS, Django 5. 1, which is now an extended support, and the Django 4. 2 LTS, which goes all the way till April next year. I think this is massively interesting. First, it shows that depending on where we are in the cycle, between 50 and 75 % of all downloads are on a supported version. I think that's amazing. I think you know Django works really hard on backwards compatibility and to have People to have that percentage of people on the supported version I think is a real success. Um so I think we can celebrate that. Second, note that it drops off. There's a big drop-off after each point zero release, just after each. What's happening there is that the previous LTS is going end of life. So next April, when we have Django 6. 0, Just after that, we should see the same thing as Django 4.

Speaker 1: 2 finally goes end of life and folks decide that well they finally better start upgrading to Django 5. 2. Okay. Note that it's not a quick recovery. It takes almost the entire LTS cycle to get back up to where we were at the previous LTS cycle It takes that long for people for it to recover as people slowly upgrade. Django has a great upgrade tour story we like to tell ourselves. And it really does. But the reality of that with third party packages and all the whatnot is that that it's not a painless release day upgrade that we all like to toot about on Mastodon. Oh yeah, I'm on five point two already. You on five point two? I'm on five point It's a bit more nuanced than that, right? So there's a question here. After 3. 0, what's that big drop off there?

Speaker 1: Well, that was when Django 1. 11 finally expired and we dropped support for Python 2 Okay, those are those are all those people that are still on Python too. Early adopters they're not. Anecdotally, I posted on Mastodon that um about a month or so before Django 5. 2 release about had to battle with a pre-Django 5. form template. We started my current project with Django 4. 2 and then we very quickly moved to Django 5. 0 as soon as it released. It was released. There was just one template that was the old 4. 2 style templates, and it was horrible to work on. It was like, ah , I don't want to be here. My point was that Django can't be going that slowly really because there's no way I'd go back what what to what was then the current LTS. Right if Django was so slow moving, being on the current LTS wouldn't be a problem.

Speaker 1: But it isn't slow moving, I don't think. A friend of mine who's both technical and runs a successful business built on Django asked me, well what were all these new features I was so excited about They didn't even know what the new features were. They're using Django 4. 2 and they're happy there and they had no intention of even thinking about updating until Django 5. 2, the next LTS, was available. Early adopters they're not. And that's totally okay. But it means that we have to be realistic about the changes that we make. Can we tear up the API stability policy? No. Even with deprecations, we can't just adjust APIs without a real reason to do so. A breaking change needs to be clearly superior, the stability policy says We can and we do make such changes every single release, but those changes have costs in that those drops in that adoption graph, right?

Speaker 1: We need to be aware of them and we need to keep those in mind. Community is trust, the trust that users have in Django. So I think that story that I've just told is how we got to where we are today. The community grew, making consensus-based decision making more difficult. The user base grew, heavily skewed against innovators and early adopters, making the stability policy vital We want to push forward, but we've got this whole community coming up behind us that we have a duty to to not break their deployments. Again, I want to stress, I think this temp tension is just part of being a successful, large, long-lived

Speaker 1: open source project. It's not something that we're doing wrong in Django. It's a symptom of doing things right. So it's not something we should beat ourselves about. Yes, we can try and change things, but it's not like oh Jack, look at Django, aren't they doing it terribly wrong? No, that's rubbish. So I just want to finish with well, what can we do? Um I'm going to finish by glossing over a few related strategies that I think are key. These aren't the only things that we could do, but I didn't have time for everything. It's only 25-minute talk. I'm just going to gloss over them because I could talk about each one of these things for an hour. Really could. So I'm just going to fly past them and then you know if you like any of them, we'll talk about them later The real power of Django is it's is the vast and growing selection of third-party packages.

Speaker 1: Two scoops of Django from 2013. 2013. That's still true today. I think the first thing we can do is to boost the existing third-party ecosystem. I uh I if I use Django because it's super stable, a super stable foundation for my apps, the giant ecosystem is probably the second thing. For almost any idea I have, there's either a package I can use directly or prior art that shows the way. That's enormously valuable. But for any should I add this to Django, one simple solution can be to just not bother. Put it into a third-party package and be done with it I do this anyway. If I want something new, and if it has to be in Django itself, even if I you know, even if I've somehow got it instantly, which Sarah showed us likely isn't likely, 300 days

Speaker 1: average for a pull request to be merged, right? Even if I get it into Django instantly, it's not going to be available until the next rate major release. Well the next major release isn't till Christmas. So even if I get it in straight away, I can't use it for the rest of a year. If I'm updating from LTS to LTS like the vast a big chunk of our user base do, then I'm not I'm gonna have to wait two years for that new feature to become available in Django Whereas if I put it in a third-party package, I can have it now. So that's what I always do. The question of whether it should go into Django comes later, like much later, and if at all. Our problem here has always been that that we keep the has been that we keep the ecosystem almost a secret. You go onto the website until recently you'd struggle to even find it at all.

Speaker 1: Historically we've not mentioned it. Not either on the website or or on the docs. The steering council are working on ways to make this better, but the key is that we have this amazing resource that we're just not making use of. We should put it front and centre, promote it, let the users know about it more. I think if we can change that, and then we can remove or reduce at least the tendency to think that everything has to be in Django Core itself. Now nothing I say here is just is the third party package story isn't perfect, right? Maybe we haven't got the right hooks. Maybe we could do with a better, I don't know, um, template on how to produce per um third-party packages. Maybe we could do with a better plug-in system. I d I don't know. But my focus is on the third-party package system initially because I think it's something that we can do w immediately without really changing something

Speaker 1: Uh without really changing anything at all. It's we've already got this ecosystem. Let's just promote it. That's a neat that's a quick win, I would say Next, I think we have we should have, we need to have, not should, we need to have a conversation as a community about what's appropriate for the scope of Django itself. What does batteries included mean in 2025? There was a thread on the forum about this recently. What batteries should be included? It was really interesting, but it soon grew to be pretty much a wish list of everything you could ever want because You know, the comments pile on. What we need to have is that same conversation, but with with with Sarah's talk from yesterday in mind, holding in mind about what we what we really have capacity to deliver. When without that capacity to live aside of it, that conversation just

Speaker 1: it it's not helpful, right? Just adding new wish lists doesn't isn't the solution. Now I think that conversation could go either of two ways. Either we think the scope of Django should change, and we can plan for how we're going to do that, and then we could all get behind it. Totally happy with that. Or we could conclude that no, actually, the Django the scope of Django should stay more or less as it is with third-party packages taking up the Slack and whatever other solutions we can come up with. And then we could all get behind that Now I don't mind which of those two ways we choose to go as a community, but I think at the moment we've got this tension where we haven't had that conversation in I don't know a decade or more, and there's a a tension where we're not all behind the same story So even if we even if we just decide, yeah, the status quo is actually what we want, having the conversation would be a

Speaker 1: healthy process. Okay, so uh it's about what we want our web framework to be. That's the question we've got to answer. And then finally, um somehow, somehow, we need to modularize. Over the medium term, I think we need to some find some way of breaking Django up a little bit to make it more maintainable. It doesn't matter how many fellows we might be able to imagine into existence, right? Two, three, four. It can't be a sustainable solution to keep pushing ever ever more through the same single net bo bottleneck of the Django Django repo. I see two possible ways here. What you m if we can't be batteries included, well maybe we can have something like battery packs. Django Tasks is a good example here. We hope to get the core interface of Django Task, which is the depth of adding background workers.

Speaker 1: We want to get the core interface and the dummy backend into Django in this in this next release cycle. But the database backend, well that's a different question. Absolutely guaranteed the database backend is going to need fixes and extra features and it's going to have all sorts of problems. No way can it or should it be tied to Django's slow release cycle and stability policy. Like the last thing we need is a you know a no-breaking change on a on the wrong API. But we want to make it easy to use. So can we can we do it as an add-on? What about this? A pip extra maybe? Sorry for the backslash there. I couldn't get it on one line at that font. Anyway, maybe this would be Battery packs. Could we do other things?

Speaker 1: One example came up recently, a new and more exciting, more fun um CLI command. Well could we do it as an extra? Could we do it as something to wrap Django? A more production ready setup. I'm constantly hearing you know people, oh we know the default templates too beginner friendly. It's not production ready. Well pip install Django production and get something there. You want auth add-on see for our auth or something, I don't know. Well, okay, pip install extra auth. Pip install The Postgres extensions you want, pip install the cache extensions. Can we do something there? I don't know. The point is that we don't necessarily have to limit ourselves to just pip install Django What the user sees as Django, the application, once they've downloaded it, doesn't have to map one-to-one to how it's developed back on GitHub.

Speaker 1: Other frameworks do this. Fast API, pip install fast API standard is the default, is the default option, right? Maybe we could do it too. And then well maybe we could break up the core. I wasn't sure about putting this up because you're gonna say Carlton said take out the admin. I'm not saying that at all, but I was pondering a while back if this would be the end of the world What would happen if the admin was separated from the core and packaged separately? Again, I'm not suggesting this. I think but I think to think about what would be necessary for this to be the case, I think it's an interesting experiment. Makes you ponder about well okay how do we structure Django?

Speaker 1: I sometimes think the admin could benefit from no I'm not suggesting So we have to modulize. I don't know. These are just thoughts, right? We have to modulize somehow. Let me come back then. Let me just finish. I'll come back to this one. Community is trust. If we can modulize somehow, then I think a few things can follow. Maybe we can parallel parallel uh too many L 's. Maybe we can do more than one thing at once. If we can do that, then potentially we can go faster. But more, we potentially find a way back to smaller working groups. If we can ha if we can bring back bring back the space for trust, trust, just to remind you, that my concerns were at least properly considered.

Speaker 1: Even if I don't agree, even if it wasn't my solution My concerns were properly considered. If we can get that trust back, then we re-enable consensus. It's not a mystery, it's just we're trying to do it with too many people. The smaller space is one where we continue we where we can continue to welcome, mentor, mentor, and bring on new members of our community that are its future. Know exactly how we do these things, I don't know. I'm not sure, but that's where I'd like to see us headed. Anyway, that's it. Thanks

Speaker 2: We'll start with uh questions from the remote audience. Uh we have three already People are piling up for questions. First one. This talk is about contributing to Django, but do you have any experience applying this community-based philosophy while working in regular teams in regular companies? And if so, what have been the results?

Speaker 1: The crossover is about team size. Um I think a a small team of uh three, four, five, maybe six. Stick starts to get big, ten is too many. I think the Teams are slightly different because teams are normally command-driven. There's normally somebody who's in charge and it's their job to make the decision, be that you know, head of a product owner or whatever Which is slightly different to the consensus model we use in in Django. But the I think the thing that is the same is the team size. Small teams work better. I think companies that try and, you know, ever been in a meeting with 30 people in it? What was the point of that? That's yeah, that would be my answer. Yeah.

Speaker 2: So next question. Uh can we have the page on the Django site with best third party stuff, auth tests, Django Guardian, etc.

Speaker 1: Yes, we can. The steering council are working on it currently. Emma's going to give a talk about that later today. I'm not going to spoil it, but yes, we can. We want exactly that.

Speaker 2: So last question from the remote audience. Uh on the topic of this talk and service from yesterday, do you think it's a possibility to encourage companies that use Django as their chosen framework? to dedicate a short amount of their developer time to give back, as it were, to the framework? Or do you need the volunteering aspect of it to maintain the consistency rather than someone popping in every now and then because they are required to do so?

Speaker 1: I am going to say that if companies can give skilled engineer time to Django, that would be valuable. The coordination problems we have are addressable. More engineering time would help there. If skilled engineers could do reviews, that would be amazing. But if skilled engineers could work a lot of problems we have is that um PRs might be from new contributors who don't necessarily have um as much technical knowledge and those obviously take more work to guide because you you have to train the contributor as you're as the as you're working on the PR. Whereas if you get you know a senior engineer to do a PR, often they're very good and mergeable with much less work. So yes, absolutely. Um I think if we could modularize somehow and make get back to the smaller teams, there'd be more space for those contributions to be absorbed

Speaker 1: more easily, is the new matter.

Speaker 2: Thank you. Now for the on-site questions.

Speaker 3: Thank you for the talk, Carlton. And I found that the most um the blocker are 30 part packages. We have uh premium packages like CangoTebug Toolbar, DRFO, similar one, and they are other packages that people just install it and they are unmained for years. So when you suggest to promote more using third um part packages uh have you thought about having some standard we can define as Django to say this packages maybe test against the main version of Django have a proper update on the version of Python because otherwise we are suggesting people to use

Speaker 3: very bad packages.

Speaker 1: Yes, absolutely pal. That's a really good point. Like what Someone picks up Django, they learn about the third-party package system, they go around Django packages, they go, I'll have that one, that one, that one, that one, that one, that one. Pip install 30 packages. uh get it working somehow and then they can't upgrade ever because those half of those packages are abandoned and uh who knows what Absolutely, I think we can do something in there. Two scoops of Django 2013 was it? The the the the advice there was be careful which packages you pick. Right? Because you can I look at abandoned packages all the time. There'll be one for some I know a custom field. And somebody's got an implementation of it. And I'll go and no way am I piping stalling that in my project, but I'll go and see what they did

Speaker 1: prior art versus reliable packages which I, you know I'm happy to put in my requirements file. Helping users learn to draw that distinction is something we can also do with improving the story here. But again, I think that's that's That that an easy and quick win. That's something we could do, right? It's a few blog posts, it's a few, it maybe a how-to guide on the on the uh in the docs about choosing a third-party package might be a decent addition there to help guide people. I don't think it's a problem we can fix like packages will become unmaintained. Just use my ones and Adam's ones. That's fine.

Speaker 4: Thank you, Carlton. Um to add on to Paolo's comment, so Django Packages. org, which is unofficial, official that Jeff Triplet maintains, he's working on trying to show not just the packages, but some sort of history of How maintained and even some sort of recommendation engine combining. How do you know that something has been around for a while and has been active? Of course you can't predict the future. Um but you can help newcomers see which packages have been around for a long time and have a community behind them.

Speaker 1: So we can just have a little star at the bottom in really small print that says Uh past trends are not indicative of future.

Speaker 4: But I would add, I mean, this isn't new, but curation is very, very difficult. So for example, there's an awesome Django repo that I maintain with Jeff, and we do curation, but It's hard to not have things blowed out to the point where they become unusable and it's hard to take things away and so I I see the Challenge.

Speaker 1: Let me just talk to the curation point momentarily. So one of the stock there's a re there are good reasons why Django doesn't have lists of random third-party packages in the docs because they would not would need to be updated. And historically it's been like, well who's updating this? Who's curating this? So the steering council have made the decision that the what the guide that we're going to add will be the steering council's responsibility to keep it periodically maintained. Because we can't have Sprinkled around the docks bad advice about oh you know that package that was good in twenty fourteen has been dead for six years. Um

Speaker 5: maybe kind of a provocative question, but uh

Speaker 1: that's what you're here for.

Speaker 5: No. Um you mentioned a very um small whistlebled user base. And Does it or what gives us the confidence that the backwards compatibility policy is right if we don't know the rest of the user base and shouldn't we um Develop for the user base we know and work from there.

Speaker 1: Okay. Um good question. I think we have a dual response. So I I'm an innovator early adopter. I'm at the front I want to push forward. I I like changes, but I also have a duty to that that minety-nine point nine percent of Django u roughly j Django users which aren't on that I and I think I honestly think the stability policy has proven to work very well and the deprecation policy. I remember as f so as fellow, you hear a you fight, you do get to see some of these people because what happens is when we drop the old LTS They start upgrading and then they turn up on track really angry that you know URLs, Django. conf. urls move to Django.

Speaker 1: Why did that move? Why couldn't we have just kept the back with the shim there forever? My PS PTSD tells asks me. They they they turn up occasionally really cross that we've broken stuff on them. But it's It's innovators and early adopters job to niggle and push and complain and demand more. But what we can't do is take that demanding and think it's representative of the whole user base. It's a really small percentage that are doing that. So yes, there are complaints. Yes, there are things we need to fix, but let's not sabotage ourselves by thinking that the story that we hear on the blogs is the whole of the Django user base. Does that answer the question? I maybe sidestepped it slightly onto a little soapbox that I wanted to make.

Speaker 6: Thanks, Carlton. Very interesting as usual. Much of your discussion and the questions now have been about compatibility and guarantees of the future and so on. One question that I'm interested in is the developer

Speaker 1: experience If you don't hold it by the bottom, Daniele, I found that doesn't happen.

Speaker 6: The developer experience we have within Django at the moment is Fantastic. There's one voice more or less throughout the whole documentation. Every single component links to the other things that it needs to. You know where you are. Everything's in one place. And it fits together beautifully, so the developer experience is is smashing. For if say, worst case, admin were to be spun out into another package.

Speaker 1: I didn't recommend that.

Speaker 6: No, I never. Um how could we guarantee that same quality of experience with these third-party packages? Because I think that that seems to be something really important.

Speaker 1: I absolutely agree, Daniel. Uh I don't know is the sh is the short answer. When you pip in the package that gets installed when you pip install Django, it it doesn't ne behind the scenes it doesn't necessarily have to be developed as a single maybe we can have code owners for folders in bits. Maybe the ORM is is I take to be the core, right? The the core the the HTTP handlers and the ORM. I think that's kind of the bit of Django you couldn't break off if you if you took those apart well what is Django left then the forms they're they're a useful thing the admin comes in okay those those could possibly be split out I think of those the admin could really do with a faster risk release cycle It's

Speaker 1: there's lots of fixes that we could make. There's lots of experiments that we could make, but because it's bound into Django, it's really hard to make them. When you pip install Django 5. 2, that could have a pinned version. So we we have dependencies. As Giref is a dependency of Django. And each time we but we release Django, a major version of Django, we we changed the the in the the py project. toml file, we change the version of um ASGIREF that it pins to so that we can say we know that that but that's the tested version, that's the one you'll get, you should be safe. Those it's like distributed like building a distributed system. You suddenly tur train change a complexity problem in the fact your project's too big for a network problem.

Speaker 1: Well which of those is harder? Well it depends. I don't know is the short answer. It's not an easy question. I the the the bit that motivates me is that kind of mathematical problem about the single Q You've got this single bottleneck of Django Django and everybody looking at the same bottlenecks are too many voices, too many eyes, too many things going through one place. If we can find a way of making those Multiple pipelines, multiple tubes for the for the co contributions to go through, I think we can smooth the process. I don't know how that works. Maybe we can't fix it. Maybe this is just a problem that we have. But if we're going to go faster, meaningfully go faster, we can't just keep adding fellows. I just don't think that scales. So what does scale? Multiple cues?

Speaker 1: Maybe.

Speaker 2: Yeah, that finishes the questions. We are running a bit late, so thank you for the talk.