Transcript: Django Fellows - Natalia Bidart & Sarah Boyce

This episode of Django Chat is sponsored by TalkPython and their new HGMX courses.

The link's in the show notes and we'll tell you more about them later.

Hi, welcome to another episode of Django Chat, a fortnightly podcast on the Django Web Promo.

I'm Carlton Gibson, joined as ever by Will Vincent. Hello, Will.

Hi, Carlton.

Hello, Will. And today we've got with us two special guests, two Django fellows,

Natalia Bedard and Sarah Boyce. Hello, fellows. How are you?

thank you for joining us hello hello yeah very well thank you yeah right exactly that's more

that's that's more like it right no air silence please come on um i don't know will that's it

i've done the intro you have to ask a question now okay well so this is our fall season and what

better than to start with our fellows since 5.1 just came out you're already working on 5.2 and

i know thinking about 6.0 so maybe i'll start with a question 5.1 is there one feature that

each of you was most excited to ship, because it's always a race at the end to see if something

gets in.

Okay, so, well, I'm Natalia, I was the release manager of 5.1, so I don't remember from the

top of my head what we were running against, because it feels like we were running with

everything.

There is always, you know, all these branches that we want to push forward to the final line.

Because, I mean, at least to me, it's very important to have the contributors feel like what they do is eventually seen and used by other people.

So that means having that merge into the angle.

But from the things that were released, I love the query string template tag, the new template tag that was merged.

I have been implementing that by hand for many years, so I have been starting switching my projects to using it.

And then there is also some work that Sarah picked up, which is the Postgres connection pool.

so maybe sarah you can tell us a little bit more how was that like yes i mean uh i would say it's

more florian's work that i helped near the end with but uh yes now that was a a feature we uh

that had been worked on for some time and we managed to get that into uh 5.1 so yeah very

exciting so could i ask a question on that because i i'm quite excited about that i'm going but i

haven't really back or tested it to know can i can i in theory can i get rid of pg bouncer now

because i've got pg bouncer everywhere and maybe one less thing maybe maybe

uh yeah i mean definitely try and uh yeah um it's it's quite nice to see the 5.1 go out because

uh it just means that we change the flavor of our release blockers so i would like to learn what's

uh what's working and what's not working so the more that people use it now uh the more we will

know how well it's working for people so okay and we'll find out over the next two or three releases

yes things come in and it's like oh do you know what this needs fixing that needs fixing okay

yeah um can i just yeah and also i sorry i happen to know that jeff might be trying connection pool

pool as well so you might want to reach out to him okay and encourage each other well we're

sort of connection pool support group yeah yes yeah okay that's fine i was in a get context data

today and i was looking at some logic and i was like what's this doing and it was building a query

string so in my view and i too am quite excited about the query string template tag because all

that can just be like moved over to the template and one line of django versus a horrible mess

tom did a great job there and it's super useful and actually for 5.2 we are well a contributor

is extending a little bit to make it a little bit more flexible and being able to pass a name

parameters to it in order to uh do things a little bit more fancier um and then going back to 5.1 we

We also have, well, the login required middleware, which is something that you can enable in

order to have, by default, login required on every view.

With that, we shipped a new decorator to not require login on a given view.

So you can, you know, have a few views, particularly for login, and not to require authentication.

And then there is this huge push regarding accessibility that has been happening from

before 5.1, but you can see the most noticeable, well, I think the most noticeable consequences

of that push in 5.1 and there will be more in 5.2 about assorted fixes regarding accessibility

in the admin in particular, but also at some widget level

which will help your application even though outside the admin

and to do the right thing in most cases

for when defining the different HTML attributes for accessibility.

And I would like to call out for that the accessibility team.

I think that this wouldn't be happening if it weren't for them.

They have been working a lot since more than three, five years now.

And they have been not only doing work, but also inviting more people to join the team

and training them and helping them becoming accessibility experts as the original group.

And we are seeing more and more efforts being proposed and fixes being proposed by the community,

but not only by the initial team, but also from new contributors.

And I think that's great.

And I think that's going to help the accessibility part of Django a lot.

And you said a key word there.

You said training.

Because for years, I've sort of known accessibility is important.

I've known the basics, you know, use your headers in the right structure, use labels and forms.

But there's a step beyond that where I'm a bit like, whoa, big chasm of knowledge I don't have.

And so how are we or how are the accessibility team pushing that forward?

The forms just do it for you, Carlton.

just the default forms handle it well there's that yeah there's that yeah yeah i think it's

super important these kind of uh specialized groups i would love to have a similar one for

the orm in fact sarah and and i have been starting some conversations around that

i think that it's at least i'm trying to embrace the notion that there is there are a lot of things

that I do not know

and that I'm training on

and asking for that,

it's okay.

It's not like I should know

and I should try to hide in secret

and learn by myself.

It's okay to ask

and it's okay to share

and that learning,

I think,

is much, much richer

than doing this on your own.

I also think

Thibaut,

in collaboration

with the accessibility team,

he's been working

on some contributor guidelines

that he's uh wanting to add into Django which will uh hopefully at least give people an

appreciation of the different elements uh involved in having uh an accessible web page uh the

different kind of um tools that people are using to uh uh when they experience the web's different

screen readers that are popular and so forth um and i know with the uh part of the

reason they wanted to increase the team is ideally they also wanted users and testers of

uh of this uh software so that they can uh you know with real life experience say whether it's

working for them or not um so uh yeah no i think and in the process i think we all are learning

when when we're reviewing these uh pull requests and i've had the the the joy and the pain of a

screen reader experience and uh it's yeah it's really interesting and you learn bits along the

way yeah i think that having that kind of guide is amazing i mean it's that why why do open source

one thing it's a massive learning opportunity right and just as i don't know when you start

and you go to the django docs and there's all this how to write unit tests and how to run the

test suite and you can take all of that stuff and you can apply it to third-party packages and you

can apply it in your work your work and you could do oh look i know all about testing why because i

help contribute to django well the same here right you can learn the accessibility tools

apply them on Django take them to your third-party packages take them to your work that's that's a

lovely reward that as individual contributors we can get from doing you know learning these new

skills so I know you alternate being release managers um so Sarah you're up for five two

or sorry Carlton do you have a question before I ask yes yeah just before you go to five two

so um Natalia you said you were the 5.1 release man you still are until the end of life

yes yes yes i i know i know i know i'm also well i was also the 5.0 release manager and i just

finished that on august 7th and then once you're done being a fellow then you have to help the new

fellows be release managers right carlton is that how it goes you never really i don't know i know

you go off on hold then you never could you never put a word yeah who's carlton yeah there's a sort

dusty patch where there was some what let me sarah before you go in so natalia how how different was

it the second time versus the first time i know we we had interviewed you and especially the first

time right it's like oh my god it all relies on me is the feeling that i hear fellows say

well the second time was so the first time i had no idea what i was doing the second time

I had like 20% of idea of what I was doing and so I guess I felt less panic and I sort of knew

what was coming so I think that made a huge difference for me in terms of being able to

prepare a little bit more for some things also I tried to one of the things that were more

the word that I'm thinking is invasive

but that doesn't necessarily apply

for the final release you need to fetch

all the translations from TransEffects

into the bundle that you're releasing

and that process

it's extremely

cumbersome

and tiresome and it's very

time consuming as well

so between 5.0 and 5.1

I tried to propose a

small improvement towards that

in order to choose a little bit the TransEffects API

in order to fetch the translation a little bit more smartly

in that using some days in order to fetch what is really needed.

So that helped considerably.

And so, yeah, overall, it was a slightly smoother process.

Well, the first one or two releases are in some ways the best to change things

because you're still coming at it with this new newness.

And then I imagine after a while, you sort of just accept certain things.

But when you're new, you're like, well, that doesn't make sense.

Let me fix that, right?

Just like when you join a code base for the first time, I feel like six to 18 months is

kind of your sweet spot where you fix stuff.

And then after 18 months, sort of the technical debt just like wears you down.

You embrace it.

In my experience.

Yes, yes.

You embrace it.

You embrace it, yes, yes.

Absolutely agree, yes.

sorry so sarah um what is the what is the what is the what is the training process like for

being a future release manager oh gosh um uh so natalia is very helpful um i have had

some unsuccessful and some slightly more successful monthly releases so uh at least some

um uh okay so for those who don't know uh we generally will have a release every month these

are the um the final the 5.1.2 for example those will happen monthly pretty much partly

they don't necessarily happen uh they are uh they happen if there are release blockers that

we uh backported fixes for or there were security fixes that we um did a release for

uh uh but in my experience it happens every month in theory it can skip um so we

you take it roughly in turns to do this in theory um so i've had at least an experience of releasing

a a new version of django um with the feature release itself um i've seen some things that

have been happening in the background uh but until you're doing it uh i wouldn't say it's um

uh yeah it will it will come there are docs and there's also uh current current fellows and former

fellows and and people to support but um yeah we'll see how it goes well the timeline i think

because it doesn't it's april right it's every eight months or so but that feels like a long

way off but really sort of the next couple months is when what's going to be in it is really decided

I wonder if either of you could speak to what is the internal timeline for these releases, right?

Because on the outside, we just see every eight months it appears, but I know that's not how it works.

So I think the alpha freeze deadline, I think that's January 15th.

So that will be then that there is like another month or so where book fixes can still be back put.

So at that point, we make the cut.

Then the branch for 5.2 exists.

Right now, we just have main, and then we have stable slash 5.1.x, and then so forth.

So on January 15th, I will create a new branch called stable slash 5.2.x.

And then there will be no more new features and no more API changes in that.

so there will be no new deprecations, nothing will be removed.

At this point, it's pretty much stable in that you should be able to try it out

and try everything out at that point.

There is then a bug fix freeze, a beta release that we will do.

So at that point, we will stop backporting some of the bug fixes that are going into main, which are kind of unrelated to 5.2.

But then after that point, we still backport stuff in, but they will only be related to the new stuff.

So anything that was changed or added in the 5.2 that has an issue, that's going to continue to be backported.

And then even after the final, we still back put those into the monthlies.

So I'm not sure if that makes sense.

But roughly January 15th, no more new stuff.

And then just fixes going forward.

I mean, that aligns with what I've heard, but I've talked to Carlton and Tim and stuff.

So hopefully for listeners, that gives a little more sense of the magic.

I hope so.

I think it's worth saying about the stability policy at this point, right?

So what is it that gets backported to a supported version of Django?

Well, say it's an old one like 4.2 or 5.0 will be or 5.0 now.

What gets backported there is just a data loss bug or a crash,

something really serious and nothing else because you can't be backporting

changes to something which is deployed on loads of installations

that are out there running in the wild because you're going to break

some of those installations and so they don't get backported what gets backported is just for that

mainstream before that first eight months after the release bugs in the new features it when we

added i don't know the the postgres connection pool and it turns out that it's got a memory leak

well yes of course we'll backport a fix to that but not you know some fix that was released two

versions ago because people have worked around that by that time and you break their work around

if you fix it in a point release.

Absolutely.

And I think it's part of the reason why

I would encourage everybody

not to do the release from LTS to LTS

because if you went from 4.2 to 5.2

and you tell us about a couple of things

that were changed back in a 5.0 or 5.1

that have now caused issues

because you've only just started to test these,

It's kind of too late and we're going to be like, oh, what a shame.

And then you will only get those fixes, hopefully, if someone does them by 6.2.

Because if you're only going to upgrade them, then that's when you'll get it.

But it won't go into a monthly, it won't be backported.

So, yeah, big benefits of staying up to date.

Yeah, and if you're going LTS to LTS, it's going to be, so if you find a bug that was introduced after 4.2 and you find that in 5.2, you're not going to get it till 6.

exactly that's kind of painful i wonder if i could ask about the the jango knot program which

sarah you were very instrumental in setting up and still being involved with just in terms of

your life as fellows because i see on the jango news uh newsletter we have uh jango knots who

come in and talk about the uh releases sarah you started this trend but it's double digit every

week so what is that i guess what is that has there been an uptick in quantity or is it just

quality or um i i mean i just looking at the numbers see a change in contributions based on

that program does that align with your experience um it's really hard to tell because in terms of

uh the the what what what we mention in um the django news updates is the points

where things get merged right and that the the merging has a massive bottleneck in that there

are only a couple of people who have merged rights and they will always do uh they will

always do another review even if there is a review um and so in terms of like the number of

uh pull requests that are getting raised and that require reviews and that in theory could be

merged it actually um unless those things were really simple things uh which we can merge very

quickly it doesn't often massively impact like what we get through in a week-by-week basis

um but i would say that it means that there are uh like people that are engaged um in the the

process itself and trying to uh you know have new voices in into discussions that have been

been going on for a while. Um, and that, that I feel like I can see, uh, more so, um, than

necessarily, uh, the, the number of commits. Uh, but yeah, I mean, I think it's been a really

great way to, uh, encourage more people and to give them like a, a routine that they perhaps

didn't didn't see themselves doing before or at least if you're the kind of person who's just like

yeah i'll do it one day and this will actually give you the the um reason to to dedicate some

time and to get involved um but i'm curious what natalia thinks because obviously i'm very biased

well actually uh from what you just said which i agree uh but there is also in these programs

Not only Diagonal Space, also Google Summer of Code, there are mentors, whichever name

we use for them, which are experienced Diagonal contributors and will guide their mentees

towards ideally a successful PR being merged.

And that process alone helped the mergers, us, the reviewers, a lot in that we get PRs which have a high quality that are not, I mean, despite sometimes being complex or being non-trivial, we don't have any numbers.

but I will say that the review iterations that those require to be merged

might be less than if we will just get a raw PR from someone that hasn't been mentored.

So not only do they have the support in order to start to be involved with the community

in the various communication channels that we have,

but also they start with, I will say, a quality of their proposal

that is great and that help us a lot.

And regarding that, there is also, I mean,

Google Summer of Code and 5.2,

which perhaps, Sarah, you would like to mention a little bit

because it's all a little bit entangled,

what we have and the different features

and how these mentoring programs are keys

to the new features that are being developed.

right now yeah so uh this google summer of codes uh period we had three accepted projects

so we had um automatic uh importings of models to the shell uh which was a project that salvo's

been working on i'm pretty sure that we'll get in for 5.2 uh no more django extensions and run

server plus then well i mean extensions has other great things but that's for me that's always been

like the the big reason i put it in just it's such a pain to deal with the shell and your models so

that's awesome yeah it's really cool um and uh yeah i'm i'm pretty confident that one's coming

in that was mentored by um buffnash and adam johnson uh then there is a project by ben which

he's been working on which is like the oldest open ticket on in jang right it's like 373 or

something like that it's yes i have no idea if he knew what he was getting himself into

that one really is that one is this is pretty pretty intense i mean it's it's intense um

but he's been doing a really fantastic job uh and like the amount of progress that's been

happening in this topic you know compared to the past few years is is amazing so um

I think it's unlikely that we will see that feature in 5.2 but I'm optimistic for 6.0

but we'll see um there is then there is um a project by Shifa um which has been mentored by

sage uh which is also quite a nice thing so say sage originally added to jacross and jason field

in a google summer of code two three both four versions and i don't know this project um so

well but i think this is jason key transformations or something like this um and uh yeah we'll see

that will be a 5.2 6.0 candidate I'm sure um but yes so fantastic I'm not sure how many

projects we've had in the past but it feels like a lot and then there is actually there's a fourth

project um there is adding async support to Django Deep October which is mentored by Tim Schilling

and that project I believe is being done by Iman Pandey and from what I hear it might already be

done and released so yeah congratulations they're amazing this episode of django chat is sponsored

by talk python are you serious about getting better at python than web development they have

over 250 hours of courses including their new hdmx plus django course whether it's django core python

or tooling you want to learn you can save 10 and get a great course at talk python.fm forward slash

django chat listeners with hyphens level up your python and support the show with the talk python

course. The link's in your podcast player show notes now. Well, I want to ask about, so DjangoCon

US is coming up and I think all four of us are giving talks. Sarah, your talk is about what

hidden features in Django 5.x. Are there any that we missed that you're going to be highlighting?

Well, actually, I mean, when I say hidden, I mean, there's, I mean, I don't want to give too

much away. Yeah, sorry. Maybe that's too leading a question. But there's a lot of stuff that we

don't actually um add to the release notes at all um

So I want to actually give some of that work a stage.

So that's the idea.

And then, Natalia, I'll just mention you're giving a keynote.

What is the topic this year?

The Django Fellowship is the topic.

So when I – also, I don't want to give a lot away,

But when I got the position, actually, when I heard about the call for applicants for the Django Fellow, I had absolutely no idea what that was about.

And I read the call for applicants, and I made this assumption in my head around what was it about.

And I don't think it was that accurate.

And also people, I mean, in my environment, my friends and my family will ask me, what is that?

And there wasn't any clarity of what it is.

So I would like to present what the Diango Fellowship is and also its value and then some personal view and reflections around the fellowship and things that can happen around that.

Great. Yeah. I mean, I know from just being on the board that the role of the fellows is really hidden from most people.

So shining a light on that is important.

And I have to say, your talk last year, Natalia, was my favorite talk of the whole conference, the Inside Out.

That was an amazing talk.

So I'm looking forward to your keynote.

Thank you.

I was so nervous and had some technical difficulties.

I'm looking forward to having the opportunity to give it again in some other context because I think I will enjoy it a little bit more.

So at DjangoCon, Carlton and I are also giving talks.

My talk is on the Django user model, and I want to tee that up as a question to you fellows.

How do big decisions get made?

Because one thing Carlton and I have been advocating for is making a change that goes beyond a Google Summer of Code, beyond what a Django knot could do.

And so what is your perspective on that?

Because I think it was 2016 when there was a Kickstarter for Postgres.

Features were added, but it's been a while.

So could you share where you sit on these big decisions?

Like, let's change something.

Natalia, shall I go?

All right.

So just so people know, the fellows are not necessarily directing the future changes of Django.

We're not, you know, there with a whiteboard and deciding what Django should look like for 6.x, for example.

We're very much in the day-to-day maintenance of things and, you know, ensuring that the changes that go into Django are, you know, well-tested, well-documented and following the processes as they should be.

and it often means that when people come with suggestions to track and people often do they

raise a ticket when they've got some new feature suggestion or they want to change something

it's not uncommon that we say oh actually this requires a wider discussion with the with the

community and part of the reason is we are just two voices right we we have some thoughts we have

some opinions of course um but we don't necessarily know what's what's best or or how everyone is

using django in the different um ways that they're using it uh so in terms of when you want to make

your changes uh one of the advantages that you have is that and i believe his name is jake howard

or real orange one, has been working on...

He's just had a dep accepted to hopefully have

this background worker inbuilt solution in Django Core.

And I think that also had some momentum

also from a DjangoCon talk.

I'm not sure if that was just in DjangoCon Europe recently

or in one before.

And then he was working on a DEP, which, you know, that got like quite a lot of input and discussion around that.

At some point, once that feels ready, you can propose this gets voted on by the steering council.

And if the steering council votes to approve that, then that DEP becomes accepted.

And then you can now essentially work on implementing the API changes or the design changes that you had detailed in that document.

I mean, this is the idea of the larger decisions which require quite extensive reasoning and thought as to why we want to do these kind of changes.

because generally Django doesn't want to break things.

So it needs to be really justified when we do this.

And I would say, you're right, it doesn't happen so often.

And in a way, because of Google Summer of Code has,

they also write like a project document.

In a way, they've been doing a similar kind of justification

and research and stuff when they apply to perhaps add in,

you know uh composite primary keys as an example um but yes in theory we should be doing depths for

for all of these changes and that gets the the review from uh the community but it's not entirely

defined like what is the boundary of of when it's depth worthy and when it's not it's a little bit

gray but um but but like all like all natural boundaries every division in the world there

are cases that are clearly one side in cases clearly the other and a sort of middle in a bit

where we're not quite sure right that's totally normal i think what happens is we can't get an

agreement it's not just like normally 95 of ideas are either yes or no and everyone's on board and

then sometimes it's a bit more hang on this is a bit more you know and if you're at work and you

say can we implement this new feature it's not unreasonable for them to say can you spec it up

first yes right which is kind of what a deck writing the depths that spec it up first bit

i think we make it a little bit too formal if anything but the idea is right and particularly

regarding your question well uh one of the things that jake did that i think is super helpful for

something to get traction is to provide whatever feature or idea you are proposing as a third-party

package.

So currently, the Angle task is a package that exists that you can install and that

is getting updates and features and pull requests.

And it will also, at some point, when the Angle task gets merged into the Angle main,

it will serve as a transition package for all the versions of Django to adopt it

and then be able to keep upgrading Django and keep using the same interface for the background workers.

So having something like that for whatever you're planning,

which I'm very curious to know about, would be a good way, a good path forward.

I would say that it's more, I'm trying to be the cheerleader here.

I mean, Carlton has a third-party package, for example, Django unique user email.

Yeah.

I mean, so, yeah, the idea there is just to enable login by email by making the email field unique.

And I always felt that if you just want login by email, custom user models are a big, quite sledgehammer to crack that little particular nut.

And the reason why we didn't migrate auth.user back in the day was it was felt it was impossible.

But, well, hang on, you can just have this little bolt-on option

and there's your unique email.

And the same with the profile fields that I want to, you know,

I'm working on proof of concept there.

If you want to hide those from the model layer, you can, and so forth.

I think there is a route forward for auth.user,

which doesn't require every project already out there

to do a painful set of migrations.

There are more subtle ways that we could go about it.

And I think that just in the authorization end of it.

So when we had, a while back, Thibaut ran a roadmap workshop.

And the number one thing everyone said was, let's update contrib.auth.

Let's make auth in Django a better thing.

Well, okay, we need a way, we need a roadmap forward.

So what I'm working on at the moment is proofs of concept of, well, you know, we could perhaps go this way.

We could perhaps go that way.

And then I'm hoping that we can get the community and the very clever people in the community to help me think through the harder problems about, well, okay, if we're realistically going to do that, what about this case and that case and this case?

Because, you know, my proof of concept is something I knock up in an afternoon or a week, and that's not quite the same thing.

Well, because it feels like if I waved a wand, auth is one of the areas where Django is not as forward-looking as it should be, right?

I mean, for historical reasons, the model user models from 2003 or so, but not having

two factor auth, not having social auth, not having, you know, working with pass keys.

I mean, the current status is personally, I rely on Django all auth, which Raymond

Penner's has worked on for forever.

And I know he just got a grant that to me, that's kind of been a kludge that papers over

some of these problems.

But, you know, newcomers come in and say, this is way too much confusion around authentication, essentially.

So that would be the overall goal.

But my talk is going to be a lot more about the past and the present and then kind of leading up to the future.

But again, all this was in 2012, like all this happened.

You can see the discussions.

Things got heated and that led to custom user models.

And I think the argument that Carlton and I would make is that that doesn't really solve the problem.

but in practice, and I'm sure you'd agree, most people, separate from the logging in and out,

how you deal with information about the user, you either use a user profile model or you use a

custom user model, and that's fine to have a split, but that's deeply confusing to people I'm trying

to teach or people who come in, or it would be better if there was one way, which I know is hard

for the Django community to align around. So there's the model itself, and then there's how

do you attach information to it and there is a third one if you ask me which is splitting

authentication from authorization yeah so what would you do where's your wand what would you

natalia take off your fellow hat how would you fix everything i'm not entirely sure i haven't

given this like a serious thought but in my experience when working with the user

and a decent-sized service

might usually need to authenticate every so often,

but might need to authorize a user very often.

So the need to fulfill those different types of requests

is a little bit different.

So to me, the first gut reaction

is that we need to split those out,

being able to authenticate from being able to authorize a user to do certain actions

in a way that we can then, in production, deploy that with different abilities

and different constraints or different scalability features

because your authorization service will have usually a higher rate of requests

than the authentication service.

So my first instinct is to split those two in a way that I can scale them differently.

Yeah, no, I agree.

The other thing I'd really want to do is be able to like have kind of levels of authentication.

So, you know, you might log in with just a form and you get your accession cookie and

that's fine for browsing around.

But if I suddenly want to go into the settings and update my email, maybe change my account

email, well, maybe I need to re-authenticate.

Maybe I need to use my two-factor in order to do that because that's a kind of more high

risk activity and i to have grades of you know grades of who are you would be nice um so there's

lots we could do um there's lots we could do well so that's that's that's my hope that there's

momentum and agreement coming out of jingo con us that this is worthy of not just worthy of focus

but can have those discussions around okay what is what is the path is it you know can we you know

write it out on a napkin in the hallway on like what what might a depth look like what might a

third-party package look like to address some of these things?

The issue is that it's a lot of work.

It's a lot of work.

work. So it's, that's kind of the other piece where maybe the Django Software Foundation and

others come in is, it feels to me like something that might require some funding, which Django

itself hasn't historically done, but I'm not on the board anymore. So I feel like Django could

and should, you know, periodically find funding for major, major projects that the community gets

behind um but that's i guess that's another piece on the puzzle here but i feel i feel like that's

in some ways the easiest like if there was consensus and okay we could find someone who

could we could find someone qualified if there was agreement and we could find a way to raise

the money um for three months whatever the time period is to pay them to do that carlton yes

anything you want to add i get slightly well you know i just get cold slightly cold shivers hearing

you talk that because the battle scars of too many django decisions that didn't get yeah well

i'm i'm newer than you carlton and the fellows are newer than i am so on on this type of thing so

in django and you're daniele asked me a question off in after my talk about whether we dodged

sometimes dodged a bullet like django is very much like and not what was it about i can't remember

what it was about in bringing in um drf into core so five six seven eight years ago the idea was

yeah let's just merge DRF into Django core and now all this time later it didn't happen and

actually you look around you think the API space is so exciting and you know let's not just take

one thing and crown it let's let the the thousand flowers bloom and let's see how they all grow

and so Django's in a way in that sense Django's really slow and really painful decision process

actually saved us from doing something which would perhaps look too good at the time but would

have then limited us going forward and i don't know i think sometimes the slowness is good but

it is really hard to get these changes i don't know i mean you're you're you're there dealing

with it both of you all the time i mean it was what it's one of the hardest things of the fellow

yes i i for me the hardest is the lack of clarity on that because i i know now but i don't think

that we as as everyone is clear about how hard it is and how perhaps intentionally undefined is

and that to me is very frustrating and i feel that for contributors is also quite frustrating

because i think there are mixed expectations uh around that um that is something that i would

like to see more clear not necessarily more more streamlined or make changes more easy no but being

able to clearly state what would be the process and what it entails even though uh that says it's

very difficult to change tiago i know jacob cabla moss had some ideas on this a while back he's a

there's a thread on the forum about it and i'm hoping he's going to pick that up and push that

just to the next level at some point.

So if you see him, you should say, Natalia.

I might see him at DjangoCon.

I might say it to him myself.

I want to add in terms of dodging bullets,

I mean, templates, I think, has borne out.

So Django's approach of not embracing

a more full-bloated Django templating system

has now led to the fact that HCMX smoothly slides in

and we don't have our version of React

or something that we have to deal with.

So that's another example of staying small,

And there was certainly momentum, momentum, maybe 10 years ago around Django templating should do more. But the fact that we didn't, and it's minimal, and as painful, I mean, this is sort of like the, my startup, one of my startups experience was at this company called Quizlet, which is education flashcards. And it's grown and grown and grown, which has been great. But on the inside, it's grown in part because we couldn't ship new features, which was incredibly frustrating, and people left over it internally.

But it turned out long term that was best for the business just to like keep it going and not not change too much.

But when you're fighting, when you're in the day to day, you want to you want to do things right.

And so that you need somewhere to put that frustration.

It's a universal thing, I guess, even though maybe long term it's best for a project.

It's not best for the people keeping it going.

i mean the the uh it's the i think people don't appreciate that it's not like the issue is is that

we need to get 20 people in a room and just talk about it because that's usually what will happen

in a in a company is that you've got you have a limited number of developers in theory you could

do you mean even with a very big team you could do some kind of like off-site event and you talk

about it and blah blah blah and you get everybody on board and fine that's what you're doing now

and that kind of breaking changes is something that you are willing to do and that you will

be able to do that but with Django in reality actually the number of people who discuss a lot

of the changes in quite a lot of depth is a relatively smallish group who are regularly

adding their voices into the discussions I mean it's not unusual that we'll get new people with

new ideas but they're not necessarily adding their voices to other such open discussions and

and I think with the stability element of it even little really little things as to like how we've

named it and that someone wants to change that in theory we would deprecate it to add a a better

better name and so it's not really a place for experimentation that we can just you know yeah

let's just throw it out there and see what people say necessarily because you know it'll take eight

months or longer for deprecations to really come into business and um yeah so anyway it's it's

definitely a lot more um complicated than what people are perhaps used to in their in their day

jobs and if we you know cycle back to janga not space i would say that's one of the main things

is for me is really this kind of expectation management and just kind of talking to people

about um you know what what is kind of normal in with django contributing but perhaps this is is

normal in in many open source contributing spaces around you know how long things take how long you

should expect before you you ping someone for a reply or you know the discussions about you know

whether you've you've actually because two people thought that was a good idea does that mean it's

a good idea and all this kind of stuff and yeah anyway it's it's definitely it's it's tough

and i don't know how to make it easier um but yeah it's definitely tough there's a online um

guide to running an open sales project by the curl maintainer um and it's called everything

curl and in there and he talks about running the project and he's been doing it i know

30 years or something something obscene amount of time now but he's got a whole chapter on people

and he's absolutely clear that the people's side of it is the hardest problem is the hardest bit

it it just is like this technical problem yeah we can bash our way around that but

negotiating the different requirements and the different needs that's that's the work that's

I mean, I think this is relevant, too, because yesterday it was announced that Laravel, which is the PHP framework, which is probably one of the ones most similar to Django, raised $57 million from Excel to do cloud hosting and stuff.

And so there are inevitably the questions about, well, why can't Django do things like that?

And it's important to say, well, Laravel is one person, this guy Taylor.

I mean, there's open source, but it's his thing.

He can decide what he can do.

And part of that is monetize and do all these other things.

And while it's easy to sort of look and say, oh, I wish we could move fast, there's, I mean, I worked with this project called MeteorJS for a couple of years that was a VC-funded framework that was trying to make money off hosting, and it's gone, gone, right?

So when you raise money and you go fast, you end up often not working in the long term, right?

The fact that Django's, what, 18, 20 years old is because of this slowness.

19 years.

And also, I think also it's important to mention the fact that because Django doesn't rely on one person, it can have longevity, right?

At some point, all this stuff eats away at you or your life changes and you don't want to do it, but Django can persist.

I mean, look at Jacob Kaplan Moss, right?

He's a good example, I think, right?

One of the creators, deeply, deeply involved.

And he's always been around, but he was a little bit less involved for a number of years.

And now he's back on the board and doing things, but it's not, you know, it's not, it's not the Jacob show and he wouldn't want that. So I guess that perspective is important to keep in mind as easy as it is to see the shining lights. Like that's kind of why we're, we're still here and yeah, things, but, but there is a, there is a cost to the, the internal side of, especially being a fellow, right? Like, you know, how does it, is it something that people can only do for five years? You know, it's five years too long, right?

Maybe there's ways that DSF, the community, can do to not have it bubble up and feel overwhelming at a certain point.

I don't know.

Maybe that's a hallway track discussion.

We'll see.

So I think we're coming near the end.

Are there any topics for either Sarah, you, or Natalia that we haven't mentioned that you'd like to raise?

Sarah, why don't you go first?

Well, we already talked about Jaggernaut space, but I will just reiterate it that we're coming towards our third session of the year.

I think by the time this goes out, the applications for Jaggernauts will be closed.

However, hopefully there will be sessions next year.

And really, as with everything, it's more gaining the mentors,

gaining the volunteers to help run these sessions.

That is the bottleneck.

So if you want to, if you have capacity

and this is something you'd be interested in doing,

please do reach out to the organisers

and I'm sure we'll do something next year with you.

Okay. And for me, on a similar topic, something that I have seen and I'm now extremely convinced

is that Tiango is progressing and it is what it is because of the contribution of all the

community and the people that tries to help and make the framework remains current and

grow. And there is, how things are right now, I don't see a way for the fellows to keep

it progressing, and fellows on the run to keep it progressing and being stable and something

that gains future.

We desperately need the community to be involved to help in whatever way that you can, either

be writing code, documentation, mentoring, or doing reviews, doing back triage, attending

to conference and talking to us and bringing ideas i think that's key key to the point that

it's the difference between the angle remaining and not remaining so um that is also something

that i want to touch in my talk how i think that's fundamental and we i think that if

i could ask for any more resources to be put somewhere that would be one thing that i i think

we should prioritize carlton do you have any as a fellow alum comments yeah no like that's

absolutely true i always described it as being the janitor right you keep the floor clean like but

django is progressed by its contributors and the the purpose of the fellows is not to push the

framework forward the purpose of the fellows is to give the space for the contributors to

get on and do the things they want to do rather than i don't know trying to merge four patches

onto four security patches onto five branches just to get them all out on a security race.

No, that's the fellow's job. That's not, you know, the contributor's job.

Yeah. So I absolutely agree with that. I, you know, we swept the floor, right?

Thank you both for coming on. I hope this becomes a regular thing because one of the goals

of this podcast is to shine a light on the community. And I've, I felt like the fellows

kind of operated in the dark historically. Um, so now that people, if they, yeah,

Yeah. If they didn't already, they know who you are, but they also understand how the role fits

into the community and things everyone can do to make it more maintainable. So with all that,

we'll have links to everything. We are at DjangoChat.com. And again, thank you both for

coming on. Thank you for having me. Thank you very much. Thank you so much. All right. We'll

see everyone next time. Bye-bye. Bye-bye. This episode was brought to you by TalkPython

and their new HTMX plus Django courses.