StreamSparkAI

speaker 1: Note yourself self submit a technical talk. Hello, I'm Carlton. This is me carton Gibson. I'm kgibson on GitHub. I' M Foster on now. I've got a website. I've got a blog. There's an rss feed. You can subscribe with that. What else? Got a podcast? Jango. Chat with my friend will who sets there. We have a podcast. It's pretty old school. Thank you. One listener. We have guests from around the community. We chat about Jango. Do check that out if you haven't had a listen, if you don't know me, between 2018 and 2023, I was one of the Jango fellows. The fellows are contracted by the dsf, the Jango Software Foundation, to do the day to day maintenance on Jango. They do ticket triage, pool regress review, releases security fixes the stuff that keeps make sure that Jango keeps coming. I'm still around. I'm on the security team. I maintain a few packages, but in December I was elected to the Jango steering council for the 6.0 cycle, along with some other members. Today's talk, it's a bit of a difficult one. It's about how we make decisions in Jango. 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 Jango'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. These are just my thoughts today. They're not unconsidered. And I don't think there are a million miles from things that other steering council members might agree with, but well, but they're certainly not official store at 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 Jango is hard tickets for new ideas that get opened on Jango's issue track a track, and that's not the right place for them. Jango'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 the people are sent to the forum because they're marked as as one fix pending any decision. We can always reopen them. But 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 the idea gets proposed and either 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 often, tentimes 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, Jango'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. If you've been around Janger for a while, I'm hoping these scenarios kind of sound familiar. Certainly it isn't new. I gave a talk at Jango con Europe in 2:18 when I just started as a Jango. Feli talked about getting patch into Jango and how therebe lots of review, lots of comments. WeWork through it with you, weget your patch ready. Wemake sure everything webe right. And then wego to track and mean market is ready for treking. And then therebe another of you therebe more comments. Getting your code into Jango has always been difficult. There's a quality bar. It's one of the reasons why Jango is so reliable. There's always been pushed back on new features. We can't accept everything, not by a long way. Sara's talk yesterday was essentially about how we can't really do much more than we already are at our current capacity level. Long discussions well, on the forum. They're no different than those that used to happen on the Jango developers mailing list. Not really. So I think these problems aren't new, but rather that maybe they built up slowly as Jango has gotten older. We all know the story right. Once upon in time in Kansas, a small team got together in the basement of the Lawrence Journal world and created the web framethat we would come to know as Jangar. I don't know if you don't know this history off by heart. Frank wiles gave an amazing talk at Jango con us last year. 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 your Python web frameworks. It has 20 million downloads a month, millions of users, countless deployments. Well, what worked for a small team and even a small community online doesn't necessarily work when you scale it up. Jango 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. Jango 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 Jango. We say that Jango is first and foremost, it's a community, and then it's an ecosystem, and only finally it's a web framework, right? So the actual Django bit in Jango 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. 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 it that code or be that organianising a conference like this one or a local meeup, 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 20 first century when we have a, you get to be a part of it. So one thing we can think, one way we can think of the community that can help us think about consensus, too, is to think of the community as trust. In smaller groups, trust is easier. 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 eye 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 it mean? It means well for every proposal for change ends up in the long grass. There are other ways we can think about community. We can think about communities 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 if you were to ask me why Jango like what what's really unique about it, I would ultimately point to its support and api stability policies and things like that. Jango's long term continuity over time. Jango 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 is in five or even ten years time. The value of that over the software development life ecycle 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've 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 one. That would be totally problem free, of course, right? We got the deprecation policy. We use it every single release. Lots of people think we use it too much. Too much change in Jango, but we can't just make radical changes outside that process. So please don't suggest we do. That's a norm, right? That's part of what it is to be in the geomeic Jango community. But new users don't know that. We can think of the community's reciprocity. The community is maintained by what we all put back into it. Take, 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. So whether it's on the GitHub issues or on Django, we have a forum that we get worn out. Here's a quote from Tim shling says, the biggest takeaway for me is that if we want to see change in the number of contributors or people who contribute to Jango, we have to take time to maintain in menship. This is the Janger naught space program 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 that mentorship. And so Janger nothat 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. The other aspect is code. So Daniel steberg, who maintains code, says, once you once merged, you own it, right? This was against one of Sara'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 fast ashore, 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. 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 communities is reciprocity in the end, I see communities is 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 life cycle. This picture is from Wikipedia right here. You have a distribution of users segmented by how quickly they adopt a new change or a new or change technology. At the leading edge, you've got innovators, followed by early adopters, then early majority, late majority in lagards. And the question for us is what's the shape of this curve for Jangar? Is it weighted towards the early or towards the later? Doctors? It's difficult to know exactly. Like 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. Come to Jango cons, theysubscribe to the Jango news newsletter, theylisten to the Jango chat podcast, theyrespond to the annual Jango developers survey, theybe on the forum or the discord or whatever. Theypop up somewhere. Okay, well, Jango is downloaded about 20 million times a month using that figure in some simple heuristics, Jacob Kaplin moss at the last Django con us estimated the Django user base as in the low single millions. So that's a reasonable estimate for the number of Jango users. Well then, it's no secret that the Jango news newsletter has a low single thousands number of subscribers. The Jango chat podcast has a low single thousands number of listeners. And when we do the annual developer survey with jet brains, 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 Jango community is, to an order of magnitude, about 0.1%, a thousandth of the total user base. So even if those figures are way off, if three times the numbers, five times the numbers, ten times the numbers, even, it's clear that the Jango user base is weighted heavily around early majority, late majority in laggards rather than innovators and early adopters. And so even if those people aren't us, even if we want to push forward faster, we need to make sure that their needs are given due weight in our decisions, right? So I think that number seems about right. About 1000 of the user base as early adopters. Whilst I was writing this talk, Tibo, who's the sa president, member of the accessibility team and wagtail core team, put up this graph on masterdon. It shows, sorry tb, I rob this like it was too good. It shows a percentage of downloads from ppi for Django that were of a supported version, one that's in mainstream or extended support. Currently that means Django 5.2, the latest release which is the new lts, Jango 5.1 which is now in extended support, and the Jango 4.2 lts, which goes all the way to 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 Jango 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. 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 point zero release. 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 Jango 4.2 finally goes end of life. And folks decide they're, well, they finally better start upgrading to Jango 5.2. Okay. Note that it's not a quick recovery, right? 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 fluit to recover as people slowly upgrade. Jango has a great upgrade 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 it's not a painless release day upgrade that we all like to toot about on masteroh. Yeah, I'm not 5.2 already. You want 5.958. 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? Well, that was when dango 1:11 finally expired and we dropped support for Python two. Those are those are all those people that are still on Python who early adopters they're not, right? Anecdotally, I posted on mastodon about a month or so before Jango 5.2 release about I had to battle with a pre Jango five form template. We started my current project with Jango 4.2, and then we very quickly moved to Jango 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, I don't want to be here. My point was that Jango can't be going that slowly, really, because there's no way I'd go back to what was then the current lts, right? If Jango was so slow moving, being on the current lts wouldn't be a problem. But it isn't slow moving, I don't think. A friend of mine who's both technical and runs a successful business builder on jgo 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 Jango 4.2 and they're happy there. And they had no intention of even thinking about updating until Jango 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 80 api stability policy? No. Even with deprecations, we can't just adjust apis without a real reason to do so. A braking 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 those drops, in that adoption graph, right? We need to be aware of them and we need to keep those in mind. Community is trust, the trust that users have in jgo. 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 tension is just part of being a successful, large, long lived open source project. It's not something that we're doing wrong in general, gle, it's a symptom of doing things right. So it's not something that we should beat ourselves about. Yes, we can try and change things, but it's not like, Oh, look at Jango. Aren't they doing it terribly well? No, that's rubbish. So I just want to finish with, well, what can we do? 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 and I'm just gonna to gloss over them because I could talk about each one of these things for an out really could. So I'm just gonna to fly past them and then you know, if you like any of them, we'll talk about them later. The real power of Jango is the vast and growing selection of third party packages. Two scoops of Jango from 2:13, 2013. That's still today. I think the first thing we can do is to boost the existing third party ecosystem. 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 Jango itself, even if you know even if I've somehow got it instantly, which Sarah showed us, like isn't likely 300 days or average for a full request to be merged, right? Even if I get it into Jango instantly, it's not going to be available until the next major release. Well, the next rarelease isn't until 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 a big chunk of our userbase do, then I'm I'm gonna to have to wait two years for that new feature to become available in Jango. Whereas if I put it in a third party package, I can have it now because that's what I always do. The question of whether it should go into Jango comes later, like much later, and if at all. Our problem here has always been that has been that we keep the ecosystem almost a secret. You're going onto the website until recently, you've struggle to even find it at all. Historically, we've not mentioned it, not either on the website 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 center to 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 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, template on how to produce third party packages. Maybe we could do with a better plugin system, 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 immediately without really changing something, without really changing anything to we've already got this ecosystem. Let's just promote it. 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 2:25? There was a thread on the forabout 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 can ever want. Because, you know, the comments ple on what we need to have is that same conversation. But with Sara's talk from yesterday in mind, holding in mind about what we really have capacity to deliver when without that capacity to live a side of it, that conversation just it's not helpful, right? Just adding new wish liisn't a solution. Now, I think that conversation could go either of two ways. Either we think the scope of Jango should change and we can plan for how we're gonna to do that, and then we could all get behind it, totally happy with that, or we could conclude that, no, actually the Jango scope of Jango should stay more or less as it is, with third party packches 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 tension where we're not all behind the same story. So even if we just decide, Yeah, the status quo is actually what we want, having the conversation would be a healthy process. Okay. So it's about what we want our web framework to be. That's the question we've got to answer. And then finally, somehow, somehow we need to modularize over the medium term. I think we need to find some way of breaking Jango 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 more through the same single net bottleneck of the Jango Jango reaper. I see two possible ways here. Well, if we can't be batteries included, well, maybe we can have something like battery packs. Jango tasks is a good example. Here we hope to get the core interface of Jango tasks, which is the depth of adding background workers. We want to get the core interface in the dummy backend into Jango in this in this next release cycle. But the database back end, well, that's a different question. Absolutely guaranteed. The database back end is going to need fixes and extra features and it's going to have all sorts of problem. No way can it or should it be tied to Jango's slow release cycle and stability policy. Like last thing we need is you know, no breaking change on the wrong api, but we want to make it easy to you so we can we I do it as an add on. What about this? A pip extra maybe? Sorry for that backstsh there. I couldn't get it on one line at that. Anyway, this would be. Actually pcould, we do other things. One example came up recently, a new and more exciting, more fun cli command. What could we do? It's an extra. Could we do it as something to wrap Jango? A more production ready setup and constantly hearing, you know, people, Oh, we know, default templates to beginner friendly. It's not production really well. People install general gle production and get something there. You want all add ons. Our author, something I don't know. Well, okay, pip install extra off. Pip install the postgress extensions. You want pitpip install the caching 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 Jango, what the user sees as Jango. The application, once they downloaded it, doesn't have to map one to one to how it's developed back on GitHub. Other frameworks do this fast. Api, pip install fast, api standard deis 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 going to say, carton 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. It sort of makes you ponder about, well, okay, how do we structure Janger? I sometimes think the anime could benefit from it. No, I'm not suggesting so. We have to modula. I don't know. These are just thoughts, right? We have to modulze somehow. Let me come back then let me just finish. I'll come back to this one. Community is trust. If we can moduarize somehow, then I think a few things can follow. Maybe we can paralll paralll too many else. 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 bring back the space for trust. Trust, just to remind you that my concerns were at least properly considered, 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 reenable 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 can continue to welcome, mentor, mentor and bring on new members of our community that are its future. Now, 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.
speaker 2: We will start with questions from the remote audience. We have three already. People are piling up for questions. First one, this talk is about contributing to Jango. But do you have any experience applying these 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. I think a small team of three, four, five, maybe six, six starts to get big. Ten is too many. I think 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 a product owner or whatever, which is slightly different to the consensus model we use in janago. But I think the thing that is the same is the team size. Small teams work better. I think companies that try and know, ever been in a meeting with 30 people in it? What was the point of that? That's Yeah that being my answer.
speaker 2: So next question, can we have a page on the Django site with buas third rparty stuff? Sks, Jango, guardian? Yes, we can. The the steering .
speaker 1: councor working on it. Currently, Emma is going to give a talk about that later today. I'm not going to spoil it, but yes, we can. We want exactly that. So last questions from .
speaker 2: the remote audience on the topic of this talk and service from yesterday. Do you think it's a possibility to encourage companies that use Jango 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 .
speaker 1: required to do so? I am going to say that if companies can give skilled engineer time to Jango, 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 prs might be from new contributors who don't necessarily have as much technical knowledge. And those obviously take more work to guide because you have to train the contributor as you're working on the pr. Whereas if you get you know a senior engineer do a pr, often they're very good and mergble with much less work. So yes, absolutely. I think if we could modularize somehow and make it back to the smaller teams, therebe more space for those contributions to be absorbed more easily. Is the mitthank .
speaker 2: you now for the on site questions?
speaker 3: Thank you for your carton. I helped companies and project to upgrade the version of Jango, and I found that most the blocker are two depart packages. We have premium packages like can go dbak tour bar, do similar one. And there are other packages that people just installed and they are maintained for years. So when you suggest to promote more using part packages, have you thought about having some standard we can define as a jangle to say this packages may test against the main version of Jango, have a proper update on the version of Python, because otherwise we are suggesting people to use very bad packages?
speaker 1: Yes, absolutely, Palo, that's a really good point. Like what someone picks up Jango, they learn about the third party package system. They go around Jango packages, they go have that one, that one, that one, that one, that one, that one pip install 30 packages, get it working somehow and then they can't upgrade ever because those parts of those packages are abandoned and who knows what absolutely. I think we can do something in there in but two scoops of Jango 2013 was it they the advice there was be careful which packages you pick, right? You can I look at abandoned packages all the time. Therebe one some I know a custom field and somebody's got an implementation of it and I'll go and no way am I pipping alling that in my project, but I'll go and see what they did prior up versus reliable packages, which I you know I'm happy to put in my requirements afar. Helping users learn to draw that distinction is something we can also do as improving the story here. But again, I think that's an easy and quick win. That's something we could do. It's a few blog posts. It's maybe how to guide 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 dgo. Just use my ones. And Adams one. I .
speaker 4: thank you, Carlton. To add on to Palos comments, 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, has been active? Of course, you can't predict the future, 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 printhat .
speaker 4: says past trends are not indictive of future. But I would add, I mean, this isn't new, but curation is very, very difficult. So for example, there's an awesome Jango repo that I maintain with Jeff, and we do curation, but it's hard to not have things bloat out to the point where they become unusable and it's hard to take things away. And so I see the challenge.
speaker 1: Let me just talk to the curation point momentarily. So one of these there's there are good reasons why Jango 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 creating this? So the steering council have made the decision that 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 docs bad advice about, Oh, you know, that package that was good in 2014 and been dead for six years. Maybe kind of a provocative question, but that's what you're here for now. You mentioned a very small whistleboard user, ace.
speaker 3: Does it or what gives us the confidence that the backqucompatibility policy is right if we don't know the rest of the user base? And shouldn't we develop what a user .
speaker 1: base we know and work from there? Okay, good question. I think we have a dual response. So I'm an innovator, early adopter. I'm the I want to push forward. I like changes, but I also have a duty to that 99.9% of roughly Jango users which aren't on that. And I think I honestly think the stability policy has proven to work very well in the deprecation policy. I remember. So as fellow, you hear, 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, Jango comf urls move to Jango. Why did that move? Why couldn't we have just kept the fact of the shim there forever? My pptsd or asks me, 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 changer user base. Does that answer the question? I maybe siseted slightly onto a little soap box that I wanted to make. 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 development. If you don't hold it by the bottom, Danieli found that doesn't have it. The developer experience we have within Jango 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 experiences is smashing for if, say, worst case admin were to be spun out into another package, I didn't recommend that. 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. I absolutely agree, Daniel. I don't know. It's a short answer. When you pip in the package that gets installed, when you pip installed Jango, it doesn't 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 I take to be the core, right? The court, the http handlers and the orm. I think that's kind of the bit of Jango you couldn't break off if you took those apart of what is Jango left, then the forms, they're a useful thing. The yammin comes in. Okay, those could possibly be split out. I think of those the admin could really do with a faster release cycle. It's there's lots of fixes that we could make. There's lots of experiments to be great, but because it's bound into to Jango, it's really hard to make them. When you pip install Django 5.2, that could have a pinned vert. So we have dependency. Asgiref is a dependency of Jango. And each time, but we release Jango, but a major version of Jango, we changed the the pi project up tommal file. We change the version of 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 like like building a distributed system, you suddenly change a complexity problem. In fact, your project ject's too big for a network problem. Well, which of those is hard, der, it well depends. I don't know. It's a short answer. It's not an easy question. The bit that motivates me is that kind of mathematical problem about the single cue. You've got this single bottleneck of Jango, Jango and everybody looking at the same bottleneck. So 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 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 the 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? Maybe.
speaker 2: Yeah, that finishes the questions. We are running a bit too late. So thank you for the talk.
speaker 1: All, let's get wrong.