Keynote - The Fellowship of the Pony with Natalia Bidart
Published December 6, 2024
This video features Natalia Bidart at DjangoCon US 2026 in Chicago, Illinois, USA.
In this conversation from DjangoCon US 2025, Natalia Bidart, a Django Fellow, shares her journey into the Django community and the work involved in maintaining one of the world's most widely used open-source web frameworks.
Natalia discusses the role of the Django Fellowship, maintaining and improving Django, supporting contributors, strengthening documentation, and fostering a welcoming and sustainable open-source community.
Whether you're an experienced Django developer or just beginning your journey, this conversation offers valuable insights into the people and processes that help keep the Django ecosystem thriving.
Recorded at DjangoCon US 2025 in Chicago.
Learn more about DjangoCon US:
https://2026.djangocon.us
Automatically transcribed, so expect mistakes in names and technical terms.
Speaker 1: Hello, my name is Velda Chiara. I am a Jengue Events Foundation of America board member. DEFNA is what runs DjangoCon US and with me today is Natalia.
Speaker 2: Hello.
Speaker 1: She's a Django Fellow and we're currently at DjangoCon US 2025 in Chicago So Natalia, how are you today?
Speaker 2: I'm good, thank you.
Speaker 1: Are you tired? How how's the energy like?
Speaker 2: Uh well not so much as tired, but more like uh these days are very intense So you get to talk to a lot of people and there is a lot of conversation and you put a lot of energy in understanding the the the person that you're talking to and also trying to be understood as well.
Speaker 1: Yeah.
Speaker 2: So there is a little bit of energy drain but but it's very enjoyable.
Speaker 1: Yeah. It kinda like recharges you in a way as well.
Speaker 2: Yeah, because I I mean yes It does. So on one hand I'm thinking all the things fellow related that I'm not doing that panel for next week But on the other hand I try to make the most of this experience because it's a long trip for me. Uh it's uh money investment for the DSF to to send me here. So I'm trying to get to know as many people as I can and to try to provide the most value as a fellow and as a person uh for the conference.
Speaker 1: That's exciting to hear. And I met you as a Django Fellow. So would you tell me more about what you did before the fellowship and how you ended up being in the fellowship?
Speaker 2: Okay, yes. So before being a fellow I had a sabbatical of six months because I quit my previous job and I was very burnt out.
Speaker 1: Yeah.
Speaker 2: I worked for thirteen years at Canonical, the company behind Ubuntu. Yeah. I had an amazing initial run of seven, eight years working with amazing people, very smart engineers That people is very much responsible in in a huge part of the engineer that I am today. They helped me grow a lot, they taught me a lot. The final five years were a little bit more uh complicated. I got um to to be m closer to the upper management and it wasn't a a blessing experience. So uh at some point I decided that I needed to quit in order to reduce the level of stress and and and frustration.
Speaker 1: Yeah.
Speaker 2: So yeah. I I took a sabbatical in order to uh recover.
Speaker 1: Yeah.
Speaker 2: And then for you know these things of the destiny I ended up talking to Jeff and Frank from Revsis.
Speaker 1: Yeah.
Speaker 2: So I started doing some contracting work for them.
Speaker 1: Yeah.
Speaker 2: Python and Django, which is the thing that I love. And at some point, uh remember it was a February, there was this call for applicants for the Yango Fellow. I had no idea what it was I'm a little bit embarrassed to say that I wasn't contributing to the angle back then. I thought I didn't even know what it meant to contribute to the angle.
Speaker 1: Yeah.
Speaker 2: Uh but I saw the call for applicants in the list of things that a younger fellow will do felt very uh close to what I like to do. They were all around housekeeping , of tickets, of PRs, security issues. respond to things, to not miss anything and to not leave any um package loose, you know, package drop around there. So I'm like I'm very good at doing this. In my last position I was um team architect. I was a tech lead So I was I I had this, you know, um desire to have this high level view of something. Yeah, you know, having this uh picturing where each piece go and how the pieces relate to each other.
Speaker 2: Um so I said I can do that. So I I asked Jeff, do you think I can do this? Because I'm not really sure what he means. He said like yes you should go for it.
Speaker 1: Yeah.
Speaker 2: And I applied and I got it. Well congratulations. Thank you. And I tell you I was like, yeah, this is not that crazy.
Speaker 1: Yeah. When
Speaker 2: I started I realized that
Speaker 1: it was crazy as you got it.
Speaker 2: Yes. Yeah. For a few months I was uh like Why did I apply for the process?
Speaker 1: Really?
Speaker 2: Yeah. Uh I don't want to get into too deep into that because I'm sure you have other questions. But that's basically how I became a fellow
Speaker 1: Yeah, and speaking of your past experience, how did that tie up to now what you do every day as a fellow? Because you mentioned you were in a kinda like team league position and now being also like the frontier person of like working on the framework every day.
Speaker 2: Yeah. That's a good question.
Speaker 1: Yeah.
Speaker 2: So when I said I was a team architect, I so at some point I had some of like a more uh people related position manager I I was a manager for three months. I hated it. So I switched to the technical track, you know. Yeah. career uh path. Yeah. And I was a technical lead and then uh what do you call a snap architect because the the the This company was doing a package store, so I was like the architect of of this software, not the people. So I will be involved in all the conversations about roadmap, about design decisions, about service architecture, technology choices. So uh while when you do that you start um
Speaker 2: learning or paying attention to more things outside the technology that might include people and might also include I don't know constraints regarding environment, hardware, data center request per second and a few depits. So you start seeing things a little bit more from the outside. So that's what it's usually called tending to be a generalist
Speaker 1: Yeah.
Speaker 2: So you know you might not know like the uh a topic in depth, but you start knowing a little bit of everything and you start to see how things connect each other So I think that helped me a lot in the fellow position because right now, and this is something that I have mentioned in in uh when when I presented the fellowship, uh what it is, the fellowship program, what it is and What do we do? I describe the fellows as an orchestrator. This is how I see us. We might not do like a branch from zero to completion. Yeah. Or we might not focus like in a given part of the angle. Yeah. Uh and most of us are not experts on a given part of the angle. We might like a a part a little bit more than another.
Speaker 2: Yeah. But as a fellow you need to have the ability to see the framework as a whole. Yeah see how all the pieces fit together and try to have an idea of what makes sense in the set and not as a as a single set. Yeah So for example, I'm very scared of the ORM even I mean to this day the RM for me is like wow black magic or or sorry like complex Complex uh complex stuff. Yeah. But still we have experts that um provide advice to us and we also seek advice and seek help with something when when we see ourselves that this is too much for us. We actively seek people to also help with reviews or opinions or in design decisions.
Speaker 2: So we can make sure that the thing as a whole is coherent and it makes sense. So that's sort of the relationship. And also, you know, dealing with people also helps a little bit. Uh when I was so canonical I I I was involved a little bit in community uh discussions, in community posts. Um so that was definitely helpful. Understanding also my previous position we were um well canonical still is a global company.
Speaker 1: Yeah.
Speaker 2: So you have fully remote people all over the world working. So you have different time zones, different languages, different cultures.
Speaker 1: Yeah.
Speaker 2: And that definitely helped into into being a fellow because right now that's the situation with Yango.
Speaker 1: Yeah Because it has contributors all over the world.
Speaker 2: Very different cultures. Yeah. Very different uh ways of approaching a problem, approaching a request. Approaching how you deal with a no or with a yes or with a change request.
Speaker 1: Yeah, and how it's to handle also the different difficult conversations may be in an issue that Yeah. There is misunderstandings and that's where you need to step in and try to make things clear for people.
Speaker 2: And I mean I I say this very calmly, but it's very difficult and very challenging. Yeah. And I make a lot of mistakes. Along the way.
Speaker 1: It's perfect. And as long as you're fixing it as you go, I think that's fair.
Speaker 2: feedback.
Speaker 1: Yeah.
Speaker 2: And if there is something that needs still work, I try to do that.
Speaker 1: Yeah. And speaking of fellowship, how is a typical day for you as a fellow
Speaker 2: Okay, so um my partner and I we both work from home. We w we both work with Python and Django and we know tech. And we sort of have our desk next to each other. Yeah. And we have a six-year-old. So the first thing that we do is take care of the child. And sending her to school and then we prepare matter.
Speaker 1: Yeah.
Speaker 2: Which is a drink that we love and it's very common in Argentina and in Europe. Yeah. We will sit at the computer and the first thing that I do is I check so I try to go uh over my task in a priority order. And the priority order is dealing with security issues. But in order to know whether you have or have not dealt with security issues you need to inspect your audio communication channel. So I check email, I have a lot of filters in my inbox Yeah. And I try so I I can see clearly flag the security reports or the security issues or the pending stuff.
Speaker 1: Yeah
Speaker 2: So I go over those and then the second priority that the fellows have is to handle release blockers because we are in charge of trying our best to ensure timely releases. So in order to have timely release we need to deal with the release blockers which are bugs around releases whether a release that is already out and something is fixed or a release that is about to be to go out. So we need to fix those before the release. So we try not to miss a release date.
Speaker 1: Yeah.
Speaker 2: So a lot of filtering on emails and then inspection of the ticket system that Yango uses.
Speaker 1: Yeah
Speaker 2: Um so in order to know whether there are release blockers that are out there that needs to be fixing, we have some filters, but I also need to see the tickets. the new tickets that have been created and still are yet to be tried.
Speaker 1: Yeah.
Speaker 2: So once that sort of handle um I try to focus on well I may have a few meetings or I may have PRs uh to review depending on the time of a release cycle. Yeah. We might focus on features or in bug fixes or in is documentation changes because at some point we have a string freeze. when we do a release candidate of a feature release. So that's basically my day and trying to juggle and and make decisions around what to tackle next. because the list is huge. So we're making decisions all the time how to prioritize and try to provide the best ratio of attention and value. Stupendant stuff.
Speaker 1: Yeah. I like that you brought up the topic about Django releases. Could you walk us through like from an idea of or how tickets are made or how uh issues or ideas are actually implemented towards the release, like from an idea stage to maybe people voting or people trying to see if this is an this is a good feature to have and till the release how does the whole process work?
Speaker 2: Okay, yeah. So uh I need to dig a little bit into the history. Yeah. Around that. So originally there were a few people that would make the decisions around what is done next, what goes in. At some point these people stepped down so they decided that Django should be a community-driven project.
Speaker 1: Yeah.
Speaker 2: That's a little bit vague, but it's also very uh appealing because you can involve all the people willing to contribute to the angle, yeah, have a say in into what goes into the next virtual So for a period there was um this documented process where before requesting or before Creating a ticket for a new feature, you should have some sort of community consensus for that new feature. So because right now what we have in the track ticket system is things that are actionable. So if someone was to the track ticket system and they they see an an open ticket, that is something that in in general will something that you can action on. You can do a backfix or you can implement a feature.
Speaker 2: So that means that there has been some previous discussion around We want that. We want this fix or we want this new feature. So for uh for for many years the process if someone will create a ticket with a new feature request. If there wasn't a community conversation and agreement for that, we might need to ask that person to go back to the forum, which is where the conversation takes place, to gather some formal consensus and and back that up so we could accept such a new feeling. Right now the process has been changed a little bit by the new steering console, I think in a positive way. We have instead of having conversation in the forum, which had some disadvantages, like
Speaker 2: conversation might fed up, might die slowly. What when considered something had a consensus is very difficult because consensus wasn't that well defined.
Speaker 1: Yeah
Speaker 2: So now there is a new uh GitHub uh project board which is called the New Features Reaper.
Speaker 1: Yeah.
Speaker 2: That someone can there is a more structured process where someone can go there, present their idea for a new feature There will be a process where community can wait in, can provide opinions, but there is like a more formal view on formal stages. from moving an um a new feature from an idea stage to an accepted stage. And one the once the new feature is accepted and there is a group of people that is willing to support that and and provide uh an implementation for it.
Speaker 1: Yeah.
Speaker 2: That can go into track and be a new feature ticket and that will be accepted. And from there it's up to people um evolving that, proposing one of many PRs for it who will try to review as fast as we can. For example, right now we are close to the 600 feature phrase.
Speaker 1: Yeah.
Speaker 2: Which is September 17th.
Speaker 1: Wow.
Speaker 2: So since two or three months we have been trying to prioritize new feature PRs. Of course we've been dealing with security reports and release blockers.
Speaker 1: Yeah.
Speaker 2: But our priority has been new features PRs. So how we have been working on
Speaker 1: Awesome. Now that you mentioned there are new features coming up in 6. 0, is there s what are some of the ideas of features you're more interested in? or excited about.
Speaker 2: Yeah, so we already have uh few things already merged into the Angle Main which will make the cuts for 600.
Speaker 1: Yeah
Speaker 2: Uh the hottest one I will say the people that is talking about the hallways template partials.
Speaker 1: I know. Yeah that's good.
Speaker 2: Yeah, so that was uh still use a third party package created by Carlton Gibson.
Speaker 1: Yeah.
Speaker 2: And he has a mentor, a student in Google Summer of Code.
Speaker 1: That's exciting.
Speaker 2: Farhan, who has made an amazing job.
Speaker 1: Shout out to him.
Speaker 2: Yes. Pulling uh pieces or most of temple partials and to adapting it to fit the angle core.
Speaker 1: Yeah.
Speaker 2: The PR is out there, it's already matched. 188 comments
Speaker 1: back and forth.
Speaker 2: So that's already main has had a few follow-up PRs with very very small fixes. So that's available. The other big thing that we have already in Maine for 600 is um content security policy. That's a way of uh ensuring that your project if you enable this secure content security policies, you can ensure that your project when it comes to serving media the browsers will honor a given set of headers so you will ensure that all the things that are loaded when it comes to uh JavaScript, CSS styles and and a few other resources are loaded from SafeSpace that you define within your policies. So that really helps your services to be
Speaker 2: uh more secure when it comes to click hijacking attacks or a few other related things.
Speaker 1: Yeah. And speaking of a new release is are you having a feature freeze anytime soon because it's like a couple of of days or weeks towards the 6. 0 release and would you talk about that a little bit?
Speaker 2: Yeah, so the feature freeze is in less than ten days. It's next Wednesday. So no tomorrow the Wednesday after that.
Speaker 1: Yeah.
Speaker 2: And that's when we're going to cut the 600 stable branch. And that's where no more new features can go into six oh zero. We can keep landing stuff and that will make the cut for the next release
Speaker 1: Okay.
Speaker 2: So the final release for 600 is going to be in December. So since uh next week until December we'll have a period of beta release Um so uh we're going to have an alpha release, a beta release, a release candidate release, and the final release.
Speaker 1: in the freezing part is there like are there defined rules of like this is this is something we can't accept even if it's last minute or is it like once the date is there it's like we're not adding anything.
Speaker 2: Right, it's most like like like the latter. Okay. Uh once did uh on on on September seventeenth.
Speaker 1: Yeah.
Speaker 2: uh except that there is an emergency or like an illness or something, I have to cut the stable branch. Yeah. And once I branch main into the stable slash C 600. x.
Speaker 1: Yeah, that's it.
Speaker 2: That's it. Nothing else. The other thing that the other feature that we 're going to be well We are very confident we're going to be landed before then is Yango Tasks.
Speaker 1: Wow.
Speaker 2: This is the work from Jane Howard. So he's uh currently part of the security team and the Wagchile team.
Speaker 1: Yeah
Speaker 2: And he has made an amazing job. He had um did the Angle Task third party package. Yeah. So he has brought in an initial set of uh features to DMCORS so that has gone through a lot of reviews already. It already has two approvals from fellows, Sarah and Jacob, and I will take a quick look next week and we want that in for 600. But when the time comes, I cut I branch main and that's it. Nothing else gets merged in.
Speaker 1: Uh that's that's I mean that's exciting to have a new release and get people excited about what to look forward to and how to even start testing it up beta And if you had a magic wand and you wanted a quick win that is both like in regards to the community and also in the technical aspect, what thing would you add?
Speaker 2: Uh I'm not sure about adding more like maybe tweaking.
Speaker 1: Okay.
Speaker 2: I think right now there is a considerable amount of friction in the contributing process.
Speaker 1: Okay.
Speaker 2: On both sides for the contributors and for the fellows, or the people trying to uh progress those contributions. I think that the tooling that we have might be um not necessarily outdated though it is a little bit outdated. I don't think that's the core issue. I think that The process is a little bit convoluted. You need to go to a few different systems and do a set of manual steps in order for your work to show up in the right places, for people to look at it There is also a documented proceduring how you need to do something which usually involves a track ticket. But you can also do things without a track ticket for very specific small things. And those things that do not that are not associated with a track ticket might get lost
Speaker 2: if you don't pay attention to that. So for me as a fellow I try to keep, you know, an o an eye on these things that might fail and might not might go unnoticed. because that's that a a person put energy and time to do. So that's something that stresses me out. So you know, I would really like to have The whole contributed process more streamlined. to have check in the in in the right places, have a better visibility of what needs to be reviewed and in what stages things are in. I think that will help Contributors reviewing stuff, contributing, proposing stuff, and knowing their status of the things that they have just
Speaker 2: contributing. And we fellows knowing exactly the uh the pile of things that needs to be taken care of, having a clear view of that. I would really, really like that. And a little bit more of automation when it comes to these things and also Releases, yeah. They are very very manual.
Speaker 1: Yeah.
Speaker 2: For a reason there are security aspects But you know, everything that you do manually it has a factor of the human being involved and so they are more error prone. So I shake every time that I do a release. I would really like some uh automation around that
Speaker 1: That sounds like we could also get the community involved. So how can the community help?
Speaker 2: Uh well We have been trying to raise awareness around this. Yeah. Uh maybe through blog no blog post, sorry, forum post I'll try to speak uh around this and you know in these sort of uh spaces.
Speaker 1: Yeah.
Speaker 2: I'll talk a little bit around this in my fellowship program talk that I gave last year. Uh it's tricky because you need a level of understanding where it's going on. Uh we need to have a l uh a high level of trust in anyone contributing to these automations because you might get access to either sensitive stuff or be involved uh in in sensitive processes, you know, when we put uh the angle release out there that means that That is something that a lot of people is going to get into their system and use. So we might be, you know, we have the the responsibility of having a safe release out there
Speaker 1: Yeah.
Speaker 2: So it's you know being involved in the forum, listen to be you know con um subscribing to the right channels uh around contributing to the angle and help to help there. That would be a huge uh first step.
Speaker 1: Yeah, and we will try to get involved.
Speaker 2: Okay.
Speaker 1: Yeah, and the other thing is that the question that I get frequently is how do fellows work with the DSF and the Django steering console? Like how does all that tie into the framework?
Speaker 2: So, okay, that's a good question. The the bulk of the production of code is done by the community. The fellows I will describe them as the orchestrators of that of that uh work and you know putting a little bit of order some housekeeping some gatekeeping
Speaker 1: yeah
Speaker 2: the Syrian council will provide uh advice uh a lot of advice you know in and and um and the dsf board will provide some structure to work with you you know giving us structuring the tooling or or in what we can do and to which extent support also like uh um um support when it comes to the weight that a role has. So we have like the two size it all complements each other.
Speaker 1: Yeah Does that help? It it does. It really does because then it tells me how all these groups work because sometimes when you're coming into the community you're like Oh there's D S F and oh there's like the steering console and I don't understand how all these troops work. And now there's also the Django Events Foundation of America that is heavily on Django Con US but they we not only do like Jenga Con US but we also try to support other communities financially as well. So getting that perspective of how all these things tie together is really helpful. And being a fellow, you you do a lot of work for the community. And I wanted to thank you for your contribution personally because when I was coming in in my first year economy US, which was in 2023, I remember we had this conversation about documentation
Speaker 1: and I hadn't really contributed to like Django documentation and really helped the perspective And then when I was reading your report, you were like, oh yeah, this and this people were involved. And I was like, Natalia remembered that I was involved. I was really excited and that you were So uh humble and down to earth that I could ask you questions off the bat and you'll be like, Yes, this is what you could do. These are some of the ideas you could work on, and I think That also moves the framework forward. So thank you so much for your service. You are a valued person of the community, in case you doubt that for a second, but we value you. And is there anything else you'd like to tell the community? to do more of or less of?
Speaker 2: Um well you know sticking around trying to uh join working groups and be active uh and above all following through to what they commit to. Sometimes you know we get some people that commit to do things and because life happens. Yeah. So sometimes they fade out. That's a little bit uh challenging to deal with, but you know being there trying to join other people and trying to commit to what they can do but follow through, that's very appreciated
Speaker 1: Awesome. Thank you so much for your time, Natalia. Thank you for being a fellow and thank you for even showing up for this.
Speaker 2: Thank you.
Speaker 1: Thank you.
Fellows first check and handle security issues, then prioritize release blockers so releases can stay on schedule. They also review pull requests, inspect new tickets, and shift focus among features, bug fixes, and documentation depending on the release cycle.
Discussed at 9:35A proposal goes through the community’s New Features board for discussion and a decision; once accepted and supported by people willing to implement it, it can become a ticket. Contributors then submit pull requests, which are reviewed and must land before the feature freeze for the target release.
Discussed at 12:35At the freeze, the stable branch is cut and no more new features are merged into that release; work can continue on the main branch for a later release. Django then goes through alpha, beta, and release-candidate stages before the final release—in this case, planned for December.
Discussed at 17:44Natalia would like a more streamlined contribution process, with clearer visibility into what needs review and what stage each contribution is in, plus more automation. Releases are still very manual, though some steps involve sensitive security responsibilities.
Discussed at 20:18The community does most of the coding, while Fellows help orchestrate the work through coordination and housekeeping. The Steering Council advises on the framework, and the DSF provides organizational structure, tooling, and support for the Fellows’ role.
Discussed at 24:07Note: We understand that names change, people change, and bodies change. We respect each individual's journey and privacy. If you have any concerns about a video or need us to remove content, please don't hesitate to contact us. We will handle your request with care and promptly address any issues.
Published July 15, 2026
Published July 15, 2026
Published July 15, 2026
Published July 15, 2026
Published July 15, 2026
Published July 14, 2026