Transcript: Fall 2024 Podcast Relaunch

We're back after a long summer break.

Now don't get excited.

This isn't a real episode.

So Will, how are you?

I'm good.

I'm happy to be back.

And in the next episode, which will be in two weeks, we have actually no, next week, excuse me, right before DjangoCon, we have the two Django fellows, Sarah Boyce and Natalia Bedart.

So stay tuned for that.

But this is just a special get back into it episode and update everyone because we have been off for the summer.

So, DjangoCon, we're both giving talks.

That's cool.

Um, tell us about your time.

Well, you gave a version of it at DjangoCon Europe.

And I got done with this a couple of years ago and people were just well, I'll just give my same talk that went nicely at Django Europe, and then I was like, oh no, Katie McGulkin's holding up the 10 minutes left.

I'm like, what?

I've got more than 10 minutes left.

So I've got to

So I wonder what's happening.

I have to drop various bits or just you know skip past them quickly and uh when I do it in in Durham.

But yeah, it's so it's this idea about API maybe.

Do you do you need an API?

So I've um started building my new application parts, which is what I'm working on, you know, since um stepping down as a fellow.

And um we've been using Django and HTMX and Django template partials and you know Alpine.js, and a year and a half in, we've got a rich application, it's it's kind of we're coming to maturity now, and we've hardly got an API endpoint inside.

There are one or two just there, but it's it's a whole world different than before I started the fellow where I was working on REST framework, and in those days it was API first or API only, right?

Was via DRM.

So and it's just a matter and and the the talk is essentially about that change between the world of 2018, say when I started fellowing where it was API first, to the world of 2023, 24, where it's API maybe.

Um that's the idea.

I mean you you'd you'd yes, you'd still gonna build the API endpoints for a Swift integration or a um, you know, a Kotlin integration for Android, definitely.

And you've been, I mean, before starting on Paths, your own um button deployment, you you did a bunch of work with Swift.

Yeah, I mean This is not like you've been doing this for a long time.

You were API first recently.

I just never I because my son was ill last year, I missed my window to to get it shipped.

And so it's a bit like okay, when do I now find a chunk of time to take that from works on my machine to product Ized, which is you know that big step.

Um, what's the most realistic way to do that?

And the HTMX Alpine HTML first um approach was literally the only way that with the budget and the time constraints we had, that it could be done.

Because it's literally it's only me on the development side, and so it's not like it was before it was always like you know, you'd have a back back end developers, you'd have a front-end team, and you'd sort of

Um, and you know, we get the we get the clients say, Oh, that's good, oh that's great, oh that's and it's like okay, yeah, that's all doable without this need for these much more elaborate um tool sets, which is which is fantastic, I think.

And I almost always say, if it's just you, no, like you can build to that, but just start with start with ATM HTMX at this point.

Yeah.

Um there's no need to go native unless you have to and unless you have an existing team.

But if you're having to learn two tool sets at the same time, no, no, no, no, no, no, no, no, no, no, no.

No, just not.

There's this idea that full stack, the the the the native app was this glowing this glowing um castle, this Disney-like castle, you know, the princess castle.

And then the full stack is like a sort of shed held together by you know dark.

I mean, it is interesting to try to step take a step back, I don't know, five, ten years.

It used to be that you just couldn't build anything interactive that was any good without going API first, right?

I mean, it's it's sort of I don't know if it's snuck up on people, but I mean HTMX, you know, we we've had Carson on the show.

I mean, that technology has been around for a while.

So I don't know if it's confluence of AlpineJS or just general frustration with what kind of React and Android are doing.

They're becoming, you know, they're almost trying to become full stack frameworks themselves, where there's this, you know, the pendulum has definitely swung around.

So there was this golden age where you just uh sprinkle on some JSQuery and you could build anything you wanted, and it was just like, you know, build my website, sprinkle on some J a few lines of jQuery, and you know,

You it was just it was glorious, and then it just got ever more complex because ever more things wanted to happen, and and and native DOM manipulations were terribly slow, and jumping

And it turns out that the browsers got faster, and DOM manipulations are quicker now than virtual DOM manipulations.

So it it you might as well just do it natively in the browser.

The browser's caught up, and they in fact got what got in front of um the the virtual DOM diffing technique.

Uh and so

But DjangoCon US does have these 45-minute time slots, but I I couldn't apply for one of those.

I couldn't do a 45-minute talk.

That's crazy.

I've done a couple of 45-minute ones.

I think those days are behind me.

I'm also I think we're back to back on Wednesday.

We're both doing twenty-five minutes.

It's not twice the effort to do twice the amount of time.

It's at least four times as much effort because you know, 25 minutes.

I don't know, you sort of introduce it, talk about it, the time's done.

But 40, 45 minutes, you're you're up there for a while.

What is what are you talking about if you're only doing 20 minutes?

I think Django Boston has started up again, and they asked me if I would do an inaugural or re-inaugural talk.

So I said, okay.

Um so this is on Django User Model, which also I feel like has had a lot of movement and momentum just in the zeitgeist.

Um Django's user model, uh, past, present, and future is the discussion.

And I realized that until I did this talk, I didn't really know the full history of user, because I came to Django in 2012.

And actually 2012 was about the time the first there's a whole wiki that um uh Russell Keith McGee put together about all these decisions around we should do something about the user model from back when Django first started.

And so the talk talks about how we got to where we are now, where we can all agree username is a little bit outdated.

Maybe you want email, we have Django all auth.

Well, you know, so I'll go through what I think are the current patterns, user profile, and then I can talk about the future, which is kind of exciting.

You just published this Magnum Opus on Stack report all about your thoughts on user model, and definitely I've been influenced by you over time.

So it's all about user model, kind of how it's developed, where we are now, and give some context for discussions that are happening now around we really probably should do something about simplifying it.

And it basically comes down to custom user models were introduced to solve a problem, but it means that now authentication and um authorization, if you will, or permissions are conflated.

And that has a performance tax, it has a complexity tax, and it's just ick when I'm teaching people that I have to say, here's the user model, and then I have to go, oh, wait a second, you need this custom user model.

What's that?

Oh, and then there's also a custom user or a user profile model.

It's a bit of a mess.

Most web frameworks just give you off and off you go.

And so I think it's a little bit of Django being it's so customizable, which is why we stay with it and love it, but it is off-putting to beginners.

Um, anyways, and you've you've made some moves around in core.

Maybe we can actually do something here around updating user, which I know is is one of the the blasphemies.

Well, it's out of it.

The stock advice is you should have a user custom user model, and you know, and that's just that's just what the docs say.

And I don't agree with it.

I've never really agree with it, I've never used a custom user model, I've never felt the need for it.

And at the beginning it was all about um, for me, it was all about logging by email.

But there are ways around that.

And I I think what we the discussion back in the day went largely, it's not feasible to migrate the user model.

Um, and so we need some other solution, and custom user models are the option.

Now, I think we gave up too early on that.

And by doing that, we created this kind of world of complexity that and and the this world of complexity, particularly for new users, where they come in and they they they they're going along, and either the

But a new person's like, what do I do?

And it's like, well

And it's just no no no, you're totally fine, don't worry.

That's the the projects using auth.user are legion and they don't nothing bad happens to them, right?

Um, but I think we could I I um put out a project earlier in the year called um Django unique user email, which just shows how you can do a kind of bolt-on migration to the user model, and all of a sudden you've got um unique emails, and then you can do login by email.

And I want to do one about the the profile fields, like the first name and last name fields, which are a bit icky, and we should we should try and you we can just uh kind of get rid of those as well.

And you know, if if people wanted to while

I like login by both, but some people just want um email only, and all authors has to do this kind of trick where it populates the username field behind the scenes with a unique identifier, which is fine, but if that field just kind of could kind of be dis could disappear, that would be even better.

But then the idea would be to pull those credentials off of the user model and allow them to say, well, what about GitHub login?

And what about um Microsoft, you know, my Microsoft org login for my work?

And what about um, I don't know, uh Sesame login where I get a unit login code and have different credentials, more different ways, tying in with things like the touch ID on your computer or the face ID on your phone or all these things which nobody even imagined back when Django was born.

And then there, you know, the fact that two-factor auth is a third-party package, which I think people like, but again, that feels like something that should be

It should be some story version back to Roth in Django.

But with batteries included, right?

And that's that's pretty bad.

Right.

Right.

Less magic, more batteries.

So anyway, so the talk will be about that.

Your post is already out there.

That that's great because that gives me something to point to for the future, and and I sort of go into the history and the present a bit more.

This isn't like, oh, we're gonna suddenly because we've got to do it in a backwards compatible way, and we've got to get um consensus.

So that's but it's it's one of these things that when I gave the talk, the one two years ago, which was sort of this in a way my magnum opus of like, here's all of Django, I tried to point out, you know, cover every area, be like, this is one where there's differences of hit of opinion.

And the difference is, you know, sometimes it matters and sometimes it doesn't.

This is one where you know, you just need to pick one and stick with it.

But unfortunately, we have a good half dozen areas around where someone who's new has to just pick something.

Um, and it can be confusing because this one, you know, you can do it both ways right now and and it's fine.

But there's some other decisions you can make that will hurt you in the long term that you you want to get those.

Choose your own adventure.

Yeah.

Um anyway, so I'm looking forward to that, and we're gonna be back to back, I believe, on Wednesday of DjangoCon in the afternoon.

You've got the the book's got an update, right?

You've got the the fifth edition.

So it's 5.0 plus compatible, has a real cover.

I updated, I added a whole nother project, so I dove more into template context, which I I felt like was kind of missing, is a lot more on function-based views.

So I show both function-based, I actually start with function-based views, add in class-based views.

We do some projects with both, and then I go uh purely class-based views for the last the last one.

Um, but I really wanted to get across function-based views because people see that it's important to understand.

I think it's a little easier to teach with it, understand how the request object and the context work together.

So there's so it's expanded, it's updated, I'm happy with it.

Um, I'm still gonna need to update the APIs and professionals' books.

But anyways, that's out.

Um, and the main thing I've been working on is this learnjango.com, where I'm gonna have all my stuff online.

You can get free premium versions.

Um you can sign up for an account right now, actually, if you want.

It doesn't do anything per se, but you're in the system.

Um but reserve.

I can't put a date on it, but certainly by this fall, if not certainly by this fall it will be out with the courses on there, and then I have updates.

I have an e-commerce course that I've been building alongside building my own, um, building this out.

So that's one that will come out.

Oh God, I hope it comes out by the end of the year.

But it has basic payments, how to do subscriptions, how to build a shopping cart with sessions, how to build a store with a database.

So in the way I used to do it progressively, four different projects.

But I've learned a lot just building that because it's doing payments is you know, it's sort of not complicated, but it's also really icky how people do it.

And a lot of times there's a lot of JavaScript which could just be done in a Django form.

And so, anyways, I this is kind of the course I needed to feel comfortable building this out and doing it right in quotes.

And I think it will help a lot of people because there are e-commerce courses out there, but to me, they just go, they're you know, 10 hours long and they go way in the weeds, and there's a lot of personal customization that doesn't need to be there.

So this will be something that covers, you know, builds you up and shows you look, it's just have the product, do the payment, do the webhook, you know, goes into webhooks.

And I uh I'm happy with how the webhooks portion is.

It's not crazy confusing to me anymore, but I think webhooks webhooks sounds very scary at first to people.

It is.

So anyway, so

Like, what's when you say you're happy with it, that means it's gonna be like your absolute usual standard of great canonical reference to right, go back to time and again, yes, this is just how I do it, right?

It's gonna be exactly that.

Right, good, good, good.

So, I mean, if I can understand it, then anyone can.

Um, so yeah, so I have that.

Um plans for other things.

I'm still doing the newsletter, Django News newsletter with Jeff.

That's been good.

Uh and you can sponsor that if you want.

We have some sponsors, but spots.

You know, maybe people notice we had um we had a sponsor um in the spring, Mailtrap, and then we have some sponsors coming up for the fall, and also ways on the website people can reach out.

So, yeah, trying to cover costs a little bit.

And so if it's something Django specific, you want to reach developers or companies.

So I mean if you if

Yes, so that's an option, it's on the website.

Uh what else?

Oh yeah, and then I guess the last things for me, and then we'll let you talk about your stuff.

Um, also I've updated, so I have this awesome Django repo that I do with Jeff Triplet that's still still maintaining, still curating, um, still growing, and then Django X repo, which is a starter project, a basic starter project.

I've updated that to I think I'd update that to 5.1.

Yeah.

Just did that.

Um, so that sort of gets you started.

And we've talked about, you know, there is a pipe dream of everyone thinks their own starter project is like worthy of everyone else to use, but doing so is a requires a lot of steps.

And you know, the ones that are out there, like Corey's Saspegasis, are an immense amount of work.

So we shall see if anything more comes of that.

Because a lot of times, and I say that because people ask for more advanced things on Django X.

And I have my own version of you know what I use, but to take that and then have the docs and everything else required to make it user accessible is is like a book worth of work.

So they need a a core, you know, they need a a project that they just this is our stack our stamp, a rubber stamp.

Here's the beginning project, they're all the same.

We know exactly what I understand all of that.

What if I'm with starter projects in general, not saying yours or boring picking on anyone in particular, but they just end up getting more and more and more things in them so that when you create the starter project, there's so many files, so much to see, so much to do that you can't really navigate it.

Um I

Um and I get that, I mean, in every framework, there's some version of a SaaS starter where someone says, I need to, you know, I have something I want to charge for, and I'll kind of backfill the understanding a little bit.

I I definitely understand that.

Um I guess I've always because I take a teaching first perspective, you know, I did Django X God six, seven years ago because Django Cookie Cutter, which is fantastic, to me was overwhelming.

Um I mean, I think I only now mostly can wrap my head around it, and yet rote beginners use it.

And but you know, that's fine.

They just want to get started and they'll kind of learn that stuff later.

But um, yeah.

Anyway, so Django X is kind of where I where I'm at, and people who want more advanced things, I usually just say, you know, you can fork it and go for it.

Um it's deliberately very minimal, um, but uh but gets you up and going.

Rather than everything you could possibly have, which sometimes is the temptation.

That's that's one of the other

mythical thing where you'll be able to do that.

Okay.

So this is this new newsletter you've you've been doing for a while.

So I decided to just try something slightly different.

And so what it is is the monthly um email.

Um, it's long form.

So it's like, you know, it's it's a bit of an effort to write and it's a bit of an effort to read, but it's you know, it's slightly deeper than just the shorter blog post type type content.

So it's a long form essay on you know everything to do with um software development or Django or whatever, done uh estimating, um, locality behavior, growing your business logic in Django, um, the user model we did did this month, you know, other ones, other topics will will come.

Um I've got ideas for um what it means to be batteries included and where we take take that for Django.

Um I've got oh lots of ideas about what what over engineering means.

There's there's a kind of nice little that we always talk in Django about batteries, um about the using boring technology, right?

This idea about boring technology and the known tech.

And there's a there's a counterpoint to that from some of the you know, let's call them big brains in the community who that they they kind of think of it as a sort of anti-intellectualism almost.

And so there's this this there's this really interesting trade-off between, you know, what we've on the show talked about using boring tech and the money stack and all these things that we like versus well, hang on, but what uh is that is that sort of Ludditism, is that holding back progress or and how you trade those two off?

And I I've got views and I've you know I've obviously got take because I'm constantly experimenting with new things.

But do I wheel them into production first day?

No, I don't.

And this is to me, this is kind of your version of that, right?

This is sitting up and saying, okay, I I have thoughts on these things and let me let me present them in as nuanced a way I can.

Um so anyways, invaluable.

I mean, even for me, who if I need to, I can ping Carlton.

You know, this is him like distilling it, right?

It's like him putting some thought into it and be like, okay, this is my thought on a user model.

So that like I've asked people to um pay either five bucks a month or fifty bucks a year.

You can you know get two apps at two issues free.

And I thought about that because everyone was always like, I'll do GitHub sponsors.

Like and I I kind of, yeah, okay, I like GitHub sponsors, but uh, you don't really get anything for it, and there's no incentive for anyone to do it.

So I'm like, okay, let's call it, it's exactly the same as GitHub sponsors, but you'll get you know my can print condensed thoughts.

And there's two or three um free issues, and I might keep make the odd one free if it's more wider usage, but most of the um issues will be to premium subscribers only.

And it's just a kind of way of saying, you know, if you like the work that I do on my open source on Django and the other open source projects in the Django community, if you want to help support, you know, the me being on the podcast all the time, then you know, take up a subscription to the Stack Report, and that's you know your way of feeding back, and you'll get you know my considered opinions after all these years of software engineering.

So that's that's going well.

Um, not a billion sign-ups by any any measure, but you know, people are signing up and um they're being very um nice about it.

So that's that's good.

Well, and it's material, right?

I mean, at a certain point, it it just helps sometimes to be like, you know what, there is some money coming in when you're sitting there, like, do I take that extra time on the you know, it sort of pushes out the burnout of open source.

And then, of course, it's also a nice impetus for to take the time to really condense your thoughts.

Where, you know, I certainly have this.

I probably over-index on just pumping out a free tutorial when it's like, well, but I really should be uh doing a paid thing, right?

There's a there's a balance there.

So at least having something that's in the paid bucket is important for longevity.

So the I've been literally meaning to write this thing about um about where to put your business logic in Django for for four years or more, you four, five years, however long it was.

And I finally got down to doing it, and it's only because I said, right, okay, I'm gonna make this commitment to write this longer piece once a month, at the end of the month, every month, and you know, allow people to subscribe if they're interested in that.

So that it's I'm really enjoying it.

People are being very um complimentary, they're enjoying, they're saying they're enjoying them, they're the reading it, and so I'm happy.

Um, and that's good.

And then beyond that, what have I been doing?

I've been working on Neapolitan, which is my quick crowd for use of Django.

Um, they've been going very well.

Uh, what can I say?

I'm they've utterly changed the way I write Django.

Um, they've it's not just Neapolitan, it's the combination of Neapolitan with HTMX, with Django template partials, which is the other package I've been working on.

But they've I've hardly used uh a built-in um class um class-based view, one of the generic built Django's built-in generic class-based views.

I've hardly used those at all.

I might use a simple template view, I might um write a view subclass myself, but basically beyond that, it's all Neapolitan, and it's just like, oh, this is what I wanted.

Um and the bottom line is like you write a list view because you want to list your your your your bookmarks, then you write a detail view, and then you write a create view, and then you write an update view, and then you write a delete view, and they're all the they all use the same get query set, they all use the same filtering to the current user, and you end up having to either put that into a mix in or re-duplicate it across all the classes.

Whereas with Neapolitan, you've got that get query set method in one place, and then as you grow, but maybe you think, oh Neo, I'll spin this little bit off into a separate view, or I'll spin that off into a separate view.

But it gives you what I really like about it, it gives me this kind of um workspace where I can just bash stuff out and it can be horrible, it can be really, you know, when you're first writing something, you've got no idea what it's gonna look like.

So just do it all in the view, and then you think, oh no, I can move that into the view, into the form, and that would tidy that up.

Okay, I'll move that into a manager method, but that first pass, I know it's all contained within this this this namespace of the of the crowd view, and it's like brilliant.

I'm gonna keep it all in there until I see the patterns emerge, and that I've just found so powerful and so empowering and so enjoyable.

I mean, it's always really embarrassing showing the first that first pass where it's literally I just

I mean, it's just I think it's okay.

And you know, the business logic post I gave a good example of where you start something in um in the view, and then you move it into the form, and then you move it into a manager method, and then yeah, maybe pull it off your managers because you need a service like because you're that advanced.

I mean, you know.

It's like logic five six ways, which yeah, I still think that's I still need to figure out what to do with that post or make a video, or because if you can, you know, it's like if you can understand that around hello world, then you really understand how views and templates and URLs work together in the same way that if you can move the logic around with some fluidity, it just opens up seeing Django as this defined thing that you can manipulate as opposed to this unknowable blob that it can definitely feel

like for people.

But the bottom line is that the the the actual underlying logic is, you know, mathematical, it's isomorphic.

It's the same logic, right?

It's the same tra it's the same transformations that you've done.

And so the the wrapping you put on it, whether it's wrapped in a function-based view or wrapped in a classroom view, that's should fade away.

That's irrelevant, right?

But how to express that?

I I need more advanced mathematics.

Because I mean it's not even obviously the computer doesn't care, but Django doesn't care.

Like all these many, so many of these constructs are just just for us humans, you know.

Like, why do we have apps?

Like, just because it's a little easier to reason about.

Like, Django doesn't care.

There, I said it.

And then eventually you're like, oh, do you know what I will have a separate app for the CMS, which is nothing to do at all with my business logic.

And you have your Wagtail stuff in a separate app, which is then, if you want to, extractable directly to a separate project, and you can, you know, Wagtail's got tooling for exporting your stuff and from one database and importing into another, and that that's all good.

But this is why I'm excited by the the um for your Django for beginners, where you've brought in the function-based views, because the the web problem is about turning HTTP requests into HTTP responses, and if you can teach that to a beginner, then you can empower them with these more, you know, with the class-based views, which are more powerful that, but they're they're they're more powerful by obscuring some of what's going on underneath.

And if they've got that understanding and bring them with them, then they are a richer developer.

And so you're giving them that.

So say you've got a list of bookmarks and you want to just re-render an individual bookmark.

Well, you can wrap the section of the just the section of that template in a partial, and then you can say, right, I want to I I just want to load that partial, and it's integrated with the template load, and it's been very well received.

And it's again the combination of Neapolitan plus HTMX plus template partials, the three of them together is kind of it's just such a rich uh combination that I I'm just having massive fun with it.

Now, is

So I've got I'm working on the pull request now.

Hopefully, I'll get it in before this autumn so we can get it in for 5.2, but if not, I'll I'll definitely for 6.0.

Um, and it was it's just a template tag basically, but it's the it's the it's not just the template, it's the comp it's the integration with the template loader, so that you just add like a a um you know, like an a text fragment, an identifier, fragment identifier on the end of a um HTM.html hashtag um this header, which is the anchor, let's go to the anchor.

You just do that for the named partial to the template loader, and it goes, it gets fetches the template, and then it goes, oh, that is that partial defined, and if it is, it will give you just that partial back.

And so your view logic just remains unchanged, and it's wonderful, and it's it's

I you know, I go ahead.

You want to just set the template name on the on the self.template name equals this, and then the rest of it needs to be restrained, needs to be the same, and then um a template view will um return a template response, which is delayed rendering and other nice niceties about it.

But if you end up changing your your view logic, you end up changing the response type as well, and it's like that's an awful lot of grief that you had to go into to just use a partial rather than the the full template.

So template partials addresses that.

So time and time again, even I make that mistake of you know, so sites is this it's almost a historical thing at this point.

I don't know how many people actually are running multiple s websites off of Django Project.

Maybe people will come out of the woodwork for that one.

But it's there are these yeah, sites kind of crops up in sometimes interesting ways that you may not think of.

And anyways, all auth.

That's one of the classic mistakes.

If you're getting a funky error, I should probably just do a post on this is the error you're getting because you didn't add sites um for all auth.

Yeah, anyways, I'll do that.

That's a common beginner thing.

Even I, you know, I wrote the all auth tutorial years ago and I was just trying to do it from scratch based on the docs, and I was like, God, what is that error?

And then I was like, oh yeah, that's that's what that is.

Anyways, that's what learning feels like.

But I think um the last thing is mentoring mentors, right?

You have thoughts on this.

So I I was thinking about the steering council elections that are coming up for um not now, but but like after the five after 5.2, so December, the end of the end of the year kind of time.

Uh that's when the 5.2 development cycle will start.

No, that's what that's when it will finish.

So 5.2 will be released.

So April time, there's going to be an election for the for the steering counts, Django Steering Council for 6.x, for the 6.x cycle, 6.0, 6.1, 6.2.

And last time it didn't go well because we didn't advertise it very well.

We just had a big board election where we had like 30 um uh people stand, and that was too many, and everyone was a bit overwhelmed by the number of people, and so we didn't really advertise the steering council election.

Then only four people stand stood, which wasn't enough, and it wasn't five for five spots, and it's like, oh ah, so we it's like, can we beforehand like try and get some excitement about this so we actually get a decent panel of people running?

And it's not just so there's one one aspect is getting more people, the other aspect is trying to get look at diversity.

Um, it's like trying to not just have white men because uh as much as we're all great and whatnot, it it would be nice to if the steering council represented the Django community more widely.

Um, and then I was thinking about okay, so what can we do about that and what can we think about that, and how can we encourage people who aren't the the the usual demographic to stand?

But then I was thinking through maintainers because it'd be nice, it is important.

The steering council has a technical role, right?

So it's important that at least one or two or three members of it are actively involved in the maintenance of Django because they they do have to speak on technical questions.

Now, I don't think all five need to be, because it's good to have people like you know, a commercial interest in Django.

I run a I rang a Django shop or I'm part of a Django shop and we find this, or um, you know, I think people that are involved in the support side, so in the education side, so like you know, like writing books or helping on the forum or helping on the Discord or you know, seeing the problems that come up, that's an important role on the steering council as well.

So it's not just technical, but there is this kind of technical requirement for at least one or two members, you know, say two, I think kind of two at the minimum.

Um, but then put those two thoughts together about diversity and the technical requirement, and you look through the package ecosystem, and it's mostly men doing the main the maintainers.

And we we we have more non-white men contributors through um projects like uh Jenga Nauts, but what we're not seeing is that leading into well, you know, actually, do you know what of the jazz band packages, half of them are maintained by you know women, or half of them, half of the that's just not the case.

We're nowhere near that, and so that's a real failing.

And so I thought, well, okay, maybe we can try and help prospective maintainers.

So just for the the the art for this this next quarter coming up until the end of the year, I'm gonna do an experiment, and if it goes well, I'll carry on into the new year.

I'm gonna put a Thursday afternoons aside and be online and do my own maintenance and but be available in case of um I had to be a support group for other maintainers, but more in mind, if if you've in the Django community and being a maintainer kind of appeals to you, well, maybe be able to give a bit of mentoring, a bit of advice on that.

And most of it is well, you know, maintaining is just contributing but on an ongoing basis, right?

It's but uh just to try and be available and try and see if having a kind of an office hour, a support group for maintainers, a bit of mentoring for prospective maintainers, see if we can move the needle, see if we can help some people make that jump from well, I've contributed to Django, or contributed to packages in the Django ecosystem to oh, do you know what?

I could take this package on.

And as the the the hopefully we could get some people on board.

But the other side of it is that packages are massively under maintained, right?

So if you go through the jazz band packages, yes, they're they're still alive, but they're kind of on, you know, oh, every eight months to do enough to get it updated to the next one, and not too many big bug fixes get merged, not too many things get done.

Lots of projects are in kind of stasis, and that's okay because they're very stable, they're mature, they do their thing, they don't necessarily need to grow.

But if we were to find a way of smoothing the on-wrap for maintainers, I think we could make a big difference to the the sort of um viability of the ecosystem.

Um just with not very much change.

I feel like I've been banging this drum for years, but

Where should they look to be?

I haven't quite decided.

I only decided to do this um over the last few days, and I'm gonna start.

It's only the next week that I'll or this week that I'll start.

You'll put a post out.

Um, I'll probably hang around, say, on the Django Discord in the packages channel because that seems like a good place for it.

But on the forum, but it's gonna it, you know.

I don't expect a billion people to turn up.

If a billion people do turn up, I've got no chance of of of helping that.

But I'll try and be online, I'll try and be available to answer questions, and I'll try and do the odd post about okay, so you want to be a maintainer, what does that mean?

And just flesh out some content I've had, yeah, like thinking about that.

Um we're gonna have Tim Tim Schilling on um this fall, and he's been very involved with with Jazz Band, and also he has this Django Commons where he's making moves around that, around the viability of main maintenance.

But there are it's it's a common problem, it's not a new problem out there.

That would be an obvious and and perhaps good place for it.

Um, like I I I had this workshop that I ran at the Sprints several years um to get started contributing to Django, I need that to become a freestanding thing, and that kind of that can't require me to be at the Sprints to deliver it.

So I need to put that into something which isn't just it's on a GitHub repo that I've got.

But if that was part of the Django community, that somehow either Django Commons or Jazz Band or under the Django umbrella, it would be more like sustainable, more yeah, maintainable.

Like you can't just rely on me because uh yeah, I'm here now and I'll be here for the the the foreseeable future, but it needs it needs some to be something that people can run themselves, and so yeah, I the bottom line is well, it's an experiment.

I don't know if I have the answers to how do we smooth the on-road for maintenance because the bottom line is you're asking people to give labor for free.

Um, and so the the big the big issue there is can you

I mean, there are these other benefits to it, but it is first and foremost, you're donating your time.

And we do have this these cohorts now.

There's two, I think two cohorts, the third one starting up of these Django knots who've been doing things such as well, doing adding to core, but also contributing to the Django news newsletter, like covering that new and Django section.

And so there is this growing group of people who I hope are looking for that next step of ways to contribute to Django, so might might be an on-ramp into these other areas.

But we can ask um Sarah Boyce about that next week.

Is that like what okay?

So what if I wanted to do more, what would I do?

Well, okay, uh, I'm in a position where I can answer that question.

Um so so we'll see.

I don't know how it's gonna go.

But yeah, if you find me on Mastodon or you find me on um the Discord, or you've you know you can send me an email.

I'm not hard to track down.

Um, I don't know exactly, but more or less I'll be online.

Maybe I'll do a video call that we can log it to.

I I know um some people have done a kind of working office hours type working group thing online.

There's a group of a core group of people who show up and it can vary in size, but it's it's more than just Jeff.

Like sometimes sometimes doing these things by yourself can feel lonely, and well, okay.

You know, there's no magic to it necessarily, but you know, if you feel like you're not alone, it can help.

Any anything else?

Or have we

I'm the kids went back to school today finally, so I'm just like oh at last.

Yeah, it's a it's a that's a big transition.

This has been fun.

This is a be a one-off.

We're generally gonna have guests and probably be a little bit tighter and more focused in our discussions, but this is what we've been up to.

I'm excited to get you know, I'm excited for DjangoCon to see everyone.

I'm excited to kind of get back into things.

And with the kids off at school again with a regular schedule, it definitely makes my schedule easier and yours as well.

So look well

We're gonna do it again.

But we have lots of guests lined up and uh I'm looking forward to it.

I've yeah, it helps it you know helps us with the community too, just to I know it helps people who listen, but just for us too to talk to everyone and hear what they've been up to.

And then sometimes you see a package or you see really good work someone's doing, and it's like, well, who's who's that person, right?

What what's what's their story?

So as ever, DjangoChat.com, all the usual places, and we'll see everyone next week.

Bye bye.

Join us next time.

Bye bye.