Transcript: Django Fellows - Natalia Bidart & Sarah Boyce

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

Hi, welcome to another episode of Django Chat, Fortnite podcast on the Django web framework from Carlton Gibson.

Joining us every by Will Vinson.

Hello, Will.

Hi, Carlton.

And today we've got with us two special guests, two Django fellows, Natalia Baylard and Sarah Boyce.

Hello.

How are you?

Thank you for joining us.

Hello.

Yeah.

I'm very well.

That's more, that's that's more like it.

Right, no way of silence, please.

Go on.

Um, I don't know.

Will, that's it.

I've done the intro.

You have to ask a question now.

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.

I was the release manager of 5.1.

So um I don't remember from the top of my head what we were running against because it feels like we were running with everything.

Uh there is always, you know, all the all these uh branches uh 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 uh is is is eventually seen and used by other people.

So that means uh having that merge into the angle.

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

Um I have been implemented that by hand for many years, so I haven't started switching my projects to using it.

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

So maybe Sarah, you can tell us a little bit more how was that like?

But uh yes, no, that was a uh a feature we uh that I've been worked on for some time and we managed to get that into uh 5.1.

So yeah, very exciting.

Because I I'm quite excited about that.

I'm quite but I haven't really battle 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.

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 uh know how well it's working for people.

Oh, do you know what this needs fixing?

That needs fixing, okay.

Yeah.

Um can I just go?

Yeah, yes, yeah, okay, that's fine.

And it was building a query string.

So in in my view, and I too am quite excited about the query string template tag because all of that can just be like moved over to the template and one line of Django versus a horrible mess that I've written.

And actually, for 5.2, we are well, a contributor is uh extending it a little bit to make it a little bit more flexible and being able to pass name parameters to it in order to uh do things a little bit more fancier.

Um and then going back to 5.1, we also have well, the login required middleware, which is uh something that you can enable in order to have by default login required on every view.

Uh with that, we shipped uh new decorator to not require login on a given view.

So you can you know uh 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 I think the most noticeable um um consequences of that push in 5.1, and there will be more in 5.2, um about uh sorted fixes regarding accessibility in the admin uh in particular, but also uh some widget level will help your app

lication, even though outside the admin, uh, and to do the right thing in most cases for when defining the different uh HTM attributes uh for accessibility.

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

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

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

Um and they have been uh not only doing work but also uh inviting more people to join the team and training them and helping them become accessibility experts as the original group.

And we are seeing more and more efforts being um 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 Liango a lot.

Um 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?

Just the default forums handle it.

Well, there's that, yeah.

I would love to have a similar one for the ORM.

In fact, uh Sarah 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 and and that I need training on.

And in asking for that, it's okay.

It's not like I should know and 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.

that people are using to uh uh when they experience the webs, 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.

I mean it it's that why why do open source?

Well, 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 can do, oh look, I know all about testing.

Why?

Because I helped 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.

Um, so Sarah, you're up for 5.2.

Or sorry, Carlton, do you have a question before I ask?

So um, Natalia, you said you were the 5.1 release manager.

You still are

until it turn the five.

I uh 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.

Is that how it goes?

You never really I don't know.

You never could you never put a word in.

Yeah.

Yeah.

There's a sort of dusty patch where there was someone who wants to.

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.

The second time I had like 20% of idea of what was doing.

And so uh I guess I felt less panic.

And I I sort of knew what was coming.

Uh so I think that made a huge difference for me in terms of uh being able to prepare a little bit more for something.

Also, I tried to one of the things that were more uh the word that I don't think is invasive, but that's that is very uh for the final release you need to create all the translations of the trance effects and for the bundle that you're releasing and data process or between the comparison and and Titon and it's a very uh time as well.

So between 5.3 and 5.1, I tried to propose a small improvement over that in order to use a little bit the transaffects API for in order to fetch the translation a little bit more um smartly in that using some dates in order to fetch what is really needed.

So that helped considerably.

And so yeah, overall it was uh a slightly smoother process of

Let me let me fix that, right?

Just like when you join a code base for the first time.

I feel like six to eighteen months is kind of your your sweet spot where you fix stuff, and then after 18 months, sort of the the technical debt just like wears you down.

You embrace

Yes, yes you embrace it.

You embrace it,

Yes.

Oh gosh.

Um I have had some unsuccessful and some slightly more successful monthly releases.

So uh at least some 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 take it roughly in turns to do this in theory.

Um so I've had at least an experience of releasing uh uh 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 curr current fellows and former fellows and and and people to support.

But um, yeah, we'll see how it goes.

It's every eight months or so, but that feels like a long way off.

But really, sort of the next couple of 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 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.

Um, so that will be then that there is like uh another month or so where um bug fixes can still be back put.

So at that point we make the cut.

We then the branch for 5.2 exists.

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

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

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

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

It's it's at this point, it's pretty much stable in that uh you should be able to try it out and try everything out um at that point.

Uh we will there is then a uh a bug fix freeze, uh beta release that we will do.

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

Uh 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 gonna continue to be backported, and then even after the uh the final, it we still backport 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.

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

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

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

What gets backported is just a data loss bug or a crasher, something really serious and nothing else, because you can't be you can't be backporting changes to something which is deployed on loads of 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.

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 minor release, in a point release.

what a shame.

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

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

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

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

Yeah, yeah, yeah.

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?

another review even if there is a 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 it unless those things were really simple things uh which we can merge very quickly uh it it doesn't often massively impact like what we uh get th

rough on a in a week by week basis um but I would say that it 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 necessar

ily 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 uh get involved um but I'm curious what Natalia thinks because obviously I'm very biased

mentees uh towards ideally a successful um PR being merged and that process alone helped the mergers us the reviewers a lot in that we get uh PRs which have uh high quality that are not I mean despite sometimes being complex or being uh non-trivial it's it's it's I we haven't we haven't had uh we don't have any numb

ers but I will say that the review iterations that those requires 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 they have this 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 um a a quality of of of of their their their proposal that is uh um great and that help us uh 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 you know uh features and how these mentoring programs are keys to the the the new features that are being developed right now.

It's yes I I have no idea if he knew what he was getting himself into.

That one really is

ll see um there is then there is um a project by uh Shaefe um which has been mentored by Sage uh which is also quite a nice thing as

or or something like this um and uh yeah we'll see um that will be a 5.260 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 uh adding async support to Django D Book toolbar which is mentored by Tim Schilling and that project I believe is being done by Iman P

andy and from what I hear it might already be done and released so yeah congratulations there amazing

se the links in your podcast players show notes now.

t think it was that accurate and lots of people I mean in my in my environment in my friends or my family will ask me what is that and um there wasn't any clarity uh of what it is.

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

Yeah.

I mean it 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 amazing talk.

Um so I'm looking forward to your keynote.

I had I was so nervous and have some technical difficulties.

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

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 summary of code, beyond what a Django Knot could do.

And so what is your perspective on that?

Because I think it was 2016 when the last there was a Kickstarter for Postgres um features were added.

But it's it's been a while.

So could you share where you sit on these big decisions like let's let's change something?

All right.

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

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

And it often means that when people come with suggestions to uh track, and and people often do, they raise a ticket when they've got some new feature suggestion or they want to change something.

Um 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 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 uh working on he's just had a depth accepted to uh hopefully have this background worker inbuilt solution in Django Core.

And I think that was also uh had some momentum also from a DjangoCon talk.

I'm not sure if that was in the just in DjangoCon Europe recently or in one before.

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

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

And if the steering council uh votes to approve that, then that depth becomes accepted, and then you can now essentially work on implementing the uh essentially the API changes or the design changes that you had uh detailed in that document.

I mean this this is the idea of the like the larger decisions which require um you know quite extensive reasoning and thought as to uh why we want to do these kind of changes, because um generally Django doesn't want to break things, so it needs to be really justified when we when we do this.

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

And uh in a way, because of Google Summer of Code has uh 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 uh 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 it that gets the the review from uh the community, but it's not entirely defined, like what is the boundary of when it's depth worthy and when it's not, it's a little bit grey.

But um but

Every division in the world, there are cases that are clearly one side and cases are clearly the other, and are 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 uh normally 95% of ideas are either yes or no, and everyone's on board, and then sometimes it's a bit, well, hang on, this is a bit more, you know.

And if you're at work and you 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.

So currently uh the angle data package that it is that you can install and that is getting uh updates and features and pull requests.

And um also at some point uh when the angle data gets into the angle main, you will package for older versions of the angle to adopt it and then be able to keep upgrading the angle and keep using the same interface for the background workers.

So uh having something like that for whatever you're planning, which I'm very curious to know about, uh, would be a good uh way uh a good path path forward.

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

Um that Yeah.

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

And so it's 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 uh, you know, I'm working on proof of concept there.

Well, if you don't if you want to hide those from the model A, you can, and so forth.

Um, 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 that just in the auth.

In the the authorization end of it, that cut that so when we had the um a while back, Tebow ran a work roadmap workshop, and the number one issue the number one thing everyone said was let's update contrib.auth, right?

Let's 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, or and that's not quite the same thing, right?

I mean, for historical reasons, with the model, user models from 2003 or so, but not having two-factor auth, not having social auth, not having, you know, working with past keys, I mean, the current status is personally, I rely on Django all auth, which Raymond Penners 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 um you know, newcomers come in and say this is way too much confusion around authentication, essentially.

So that would be that would be the overall goal.

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

But again, it all this was in 2012, like all this happened, you can see the discussions, um, 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.

Um but in practice, and I'm 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.

Yeah.

Where's your one?

What would you, Natalia?

Take off your fellow hat.

How would you fix everything?

I haven't given these like a sensitive use of thought.

But in my experience of when working with user, um uh uh uh an a decent size of service ma uh might usually need to authenticate every so often, but I need to authorized uh authorized sorry a user very often, right.

So the the means that we feel those different type of requests is a little bit different.

So to me the third that we have is that we need to split data out and being able to authenticate and being able to authorize a user to do authority in a way that we can then in production uh deploy that uh with different uh abilities and different constraints or different uh scalability features because your authorization services will have usually a higher rate of request uh

than the authentication service.

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

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 session 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 2F factor auth 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.

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 like a third party package look like um to address some of these things?

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

It's a lot of work.

So it's that's kind of the other piece where maybe the D the Django Software Foundation and others come in is it feels to me like something that might require some funding, um, 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 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, do you have anything you want to add?

Like Django is very much like an what was it about?

I can't remember what it was about in bringing in um uh 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, 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 looked 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 the you're there dealing with it, both of you, all the time.

I mean, it was what it's one of the hardest things to the fellow.

pectations uh around that.

Um that is something that I would like to see more clear, not necessarily more more uh 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 Tjango.

He's uh there's a thread on the forum about it, and I'm hoping he's gonna 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 Django Conor, I might say it to him myself.

So that's another example of staying small.

Um and there was certainly moment uh 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 uh 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 it in the day-to-day, you wanna you wanna do things, right?

And so that fr you need somewhere to put that frustration.

So, anyways, 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.

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 uh 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 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 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 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 Django Not space, I would say that's one of the main things you 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 it's it's definitely it's it's tough.

And I I don't know how to make it easier, um, but yeah, it's definitely tough.

But it he's got a whole chapter on people, and he's absolutely clear that the people side of it is the hardest problem, is the hardest bit, right?

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 the labor.

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 Meteor.js for a couple years that was a VC funded framework that was trying to make money off hosting, and it's gone, gone.

Right?

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

The fact that Django's um what, eight eighteen, twenty years old is because of this slowness.

And and also I think also it's important to mention the fact that it we 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 let's 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 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 of being a fellow, right?

Like, you know, how does it is it something that people can only do for five years?

You know, is 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.

That's maybe that's a hallway track discussion.

We'll see.

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?

I think by the time this goes out, the um applications for Django Knots will be closed.

However, uh hopefully there will be sessions next year.

Um and really, as with everything, it's more um gaining the the mentors, gaining the the volunteers to help run these sessions that that is the uh bottleneck.

So uh if you want to uh if you have capacity and this is something you'd be interested in doing, uh please do reach out to the organizers and I'm sure we'll do something next year with you.

And that is how things are right now.

I don't see a way for uh the fellows to keep it uh progressing and the fellows on the run to keep it progressing and being stable and uh something like that is a feature.

We desperately need the community to be involved to help in whatever way uh that you can either be uh writing code documentation and mentoring or doing reviews or doing back triad, attending to conference and talking to us and uh bringing ideas.

I think that's key due to the point that it it is the difference between the younger Romanian and non-Romanian.

So um that is also something that I want to touch on in my talk.

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 that we should prioritize.

I 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 release.

No, that's the fellows' job, that's not you know the contributors' job.

Yeah, so I absolutely agree with that.

I I you know we swept the floor, right?

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've felt like the fellows kind of operated in the dark historically.

Um, so now that people 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.

Bye bye.

Bye bye.