Transcript: Django Fellow - Tim Graham

I'm Carlton Gibson.

I'm joined here today with um, as usual, with Will.

Hi, Carlton.

And we've got a special guest today, Tim Graham.

Hey guys.

Tim is uh, well, who what can I say about Tim?

He's Django's number one all-time contributor, and he's been the Django contributing to Django for as long as I've been using it, and he's just um finished four years straight as the um Django Fellow.

So we're so privileged to have Tim in, and we wanted to talk to talk to Tim and get his take and um well hope you enjoy it.

So um back in college um I had an independent study project and um somehow I got involved with Python and then with Django as part of that, and um just fell in love with the documentation and the tutorial and seeing how much functionality you could get with a few lines of code for the admin and uh yeah, it's been a journey since then.

Um I'm thinking maybe around 1.4 or so.

So more stable than pre-1.0 for sure.

Yeah.

And then had you how much had you done with other web frameworks and programming before uh Django itself?

Um picked that up in school.

It's like for me, I always describe it as that glass of um iced water, you know.

It's like, ah, what a difference.

I know PHP's not like.

Okay, so one thing I wanted to ask about was the um beginnings of the fellowship program and how that came about and you know it's its origin because Django's kind of dependent upon it.

I worked at a startup after I graduated school, and then we were acquired by Google and uh worked there a little while, and then um as our as our software was transitioned over to the Google stack, uh they didn't need our team anymore, so I decided I wanted to stick with Django and so I took some time off after I left Google and then sort of did the fellowship job on a volunteer basis for a number of months, even though it wasn't a formal thing

Uh and that that kind of kickstarted the the Giango Software Foundation board to get the program going finally and uh run a pilot.

That's a big, you know, that's a big ask for someone to give voluntarily.

Yeah.

Do you remember the sort of um rough ticket number when you started contributing?

Because we're on about 30,000 now.

Oh, I I found it.

I I found the link that you mentioned in your in your talk, actually.

If you could talk about, you know, how how did Django work before there was someone even part-time focusing on the releases and you know, because I think a lot of us are are used to modern Django, which has a regular release cycle, like 2.2 just came out.

What was the process and who was involved before the Django Fellowship program started?

So I know uh James Bennett and Jacob Kaplan Moss were the releasers, and but they weren't necessarily triaging all the new tickets and merging most of the pull requests like the fellows do today.

So it was more sort of like when the commute when there's a consensus on the mailing list or something that a release is ready, then we'll do it.

Um there wasn't a there wasn't a formal eight-month release schedule like we have now.

It was just sort of you know, when things are ready, then we'll release.

I wasn't super involved with the process in those days, but okay.

learned about was sort of Django core things such as the Django Under the Hood conference, which I guess no longer exists but was a gathering in Europe of uh contributors to Django.

I was wondering if we could talk about Yeah, just the community, especially when you started to today, because you know, you're uh best based based in Pennsylvania, it's a global community.

How do you you know that there are these in-person meetings, right?

It's not completely online and digital.

And at that time, I I feel like the last few years the importance of the core team has kind of decreased.

In fact, there there's a proposal floating around to sort of get rid of the core team, and uh that's another topic.

There's there's Simon and Claude and you and you know John and half a dozen, but there's not you know, there's not this this massive roster of the great and the good.

Uh and to get rid of that as a as the governing body, I think is probably a good thing.

What exactly we replace it with, I don't know.

That's what I try to do on the website with the um technical team.

In other words, like these are the people that are actually active, so we can see that as opposed to the core team, which is just you only add people and never remove.

I I think it's important and kind of mind-blowing to find out who's actually doing the work.

Um, because so many people are doing so much work, almost everyone on a volunteer basis, and they're not doing it for pats on the back, but I think it's important for people to know who they are and how much they're contributing because Django seems this amorphous millions of people use it thing.

But then uh I mean Carlton discussed this in his talk at DjangoCon where we first met last fall.

It's it's really just a handful of people doing the majority of the work.

So I think they should be recognized a little bit more.

We've got to say, you know, we've got to put our hands together and say, well done, thank you.

And and and that bit is missing from the proposal as it currently is floating around.

So I that's my one concern with it, is all I can say.

I don't know if I'm training more.

Um so I'll just go through some of the tasks that are listed on the uh sort of job description each time the fellowship opens up.

They put out a post on the Django blog.

Um one of them is monitoring the security at Django Project.com mailing list, ensuring security issues are acknowledged and responded to promptly.

Um so there's a security team of about maybe 10 to 15 people who are active in various capacities.

There's a funny story, one of the guys I worked with, he sent a report to this security list and he he's on the he was on the Django team for a while and he's like, I th I thought there would be like this magic group that would just, you know, take care of my issue, and it turns out it was a lot more complicated than that that and nobody really knew how to solve it.

So it's I mean it's a real group of people with limitations and

You don't necessarily know what you know a security issue comes in.

You're like, well, okay, yeah, I see it's a problem, but how's it to be fixed?

You know, it's not clear that you know I don't know, and people on the list are knowledgeable, and between the group, maybe we can come up with a a a good solution.

Because contributors weren't getting the feedback that they wanted.

Um, whereas when you when you were able to come on part-time, that really sped up development, right?

Because to have someone who could really push these things through and do the the hard work of getting consensus on things, is that right?

So when I started working on them and uh that really kick started those people's uh future involvement with Django.

Is that the same thing?

It's people who are already commu uh contributing to security on Django and then at some point are invited to join the the core team.

Is that how that works?

They you know they know they're not active.

I think some people sometimes um people feel bad that they're not active and you shouldn't feel that, but equally, you know, they can step away.

Uh fixing release blockers and helping to ensure timely releases.

So as we talked about uh previous to the Django Fellow program, releases sort of happen whenever they were ready.

Um I did a community survey a number of years back, and uh based on the feedback of that, we adopted the eight-month release schedule.

So there was some people, I think the choices on the survey were six, eight, twelve months, something like that.

And uh I guess we landed on eight months, the sort of middle ground in terms of having to upgrade too often or there being a big lag between features and bug fixes and when they were actually released.

Release blockers or regressions since the previous stable version of Django or bugs in new features.

So the fellows will work on fixing those issues to help ensure the releases are on schedule.

Like it's you know, they need to be fixed timely.

Can you explain, Tim, about the um long rate long-term re um long-term support versions and how those fit in with the major releases and the version numbers?

Because Will was asking me about this in another episode, and I I sort of bumbled through it, not knowing exactly, but you probably helped you probably created that policy or helped create that policy.

Could you explain about how the version numbers work?

So, starting with Django uh 2.0, Django will use a loose form of semantic versioning, such that each version following an LTS will bump to the next.

So starting with 2.0, 2.1, 2.2 will be the LTS, and then following that it'll be 3.0, 31, 32 will be the LTS.

So the idea there is that um in Django 3.0, for example, some deprecated features will be removed, so that upgrading from 2.2 to 3.0 uh may require a little work on on your end.

But you should be able to upgrade from 2.0 to 2.1 and 2.2 without much work.

Something about you should be able to upgrade from say 1.11 to 2.2, i.e.

from one LTS to the next without having to go through the intermediate versions.

Is that right?

Uh that's what I would suggest, at least locally, you know, install uh if you're on 1.11, install 2.0 and get your test passing there and then go to 2.1 because there can be some backwards incompatible changes in uh each version, but those should be relatively minor, hopefully.

Ah, okay, okay.

Yeah.

Okay.

And I I literally, before walking in here, someone in my co-working space uses Django.

I was like, hey, 2.2 came out, and he's like, Oh yeah, like I'm on the long-term support thing, so I should do that.

And I was like, Oh, you should listen to the podcast.

You should phew.

And so the other big thing for me is the triage work because there's like every morning there'll be, you know, two, three, four, five new tickets opened up, and um so I guess there's there's two aspects.

Can you tell us about that?

And then the follow-up is how do you sort of maintain a rhythm with that?

Because it can sort of this it's a bit incessant.

Yeah.

Uh, a lot of times reports will be against maybe the current stable version, and then maybe the bug has been fixed in master.

So part of that is just making sure the issue's still valid on master.

I try to put the the commit uh hash where I reproduce the issue on the ticket.

That way, if somebody comes along later and says, Oh, this has been fixed since then, then you can easily bisect and find out the commit uh where where the issue was fixed, and then you can check if an appropriate test was added along with that.

Um another aspect of triage and maybe the ticket is a duplicate of some issue, so um looking at tickets for a number of years, you sort of get to know most of the issues, and I usually use Google to search tracks.

So if you put site colon code.jjango project.com into Google and then put in a few keywords, you can usually f well I can usually find the the ticket that I'm thinking about as as a possible duplicate.

It's like, ah, thank you, Tim, because there's like 13

Like maybe you want to do something with migrations, you can look in the migrations component and you'll see maybe 50 tickets instead of a thousand.

Because it it for me I was maintaining Django filter and Django Risk Framework and Django Crispy Forms outside of Django, but for a long time I wasn't contributing to Django itself, and it was a bit like okay, eventually I got there because I had a bug which affected Crispy Forms.

I was like, oh, I need to do this, and actually it wasn't that bad, but you know, I was a you know a maintainer and yet I was still a bit intimidated.

Um what sort of thoughts might you have, advice for us as to you know how we can make it easier for new contributors, or is it just necessarily how it is?

Um it seems like a lot of people come along and they don't really have a problem, they just want to get involved.

I think it can be hard there, especially if you've never used Django.

I mean there's tons of open tickets of small, minor inconveniences that aren't really high priority, and if if they're not a high priority for anyone, then I'm fine leaving the ticket open.

I mean uh you know, the admin, right?

That's that's that's one that for legacy reasons, but I'm curious what else as a fellow kind of

Uh but on the other hand I don't use Django a whole lot these days.

The um the admin, like it's great, it's super, but there isn't much room, I think, for adding new features.

And you know, because it's so complicated already, the API is so big on it, it's like, oh, can we just leave it alone?

Like it's good, it's powerful, but until we've until we tidy it up a bit, I'm a bit scared of oh, let's add on another bit of API, another option on the model admin.

It's like, oh, but there's 50 already.

It's just like we're gonna have so many hooks that it's just gonna be unmaintainable, I feel like.

Um fair enough.

You're not supposed to build your user-facing UI in it, it's not supposed to be pixel perfect.

And I feel like all the requests are just we want to do every single little thing with the admin.

And I just not sure if that's feasible or

I mean, if we could s we could extend it a slightly so you could um root views so that they appeared within the admin interface more easily, that might be quite handy because then people could and there I mean there are third-party packages that do that, but maybe in addition there.

I agree with Tim.

I don't think it needs to be replaced.

I just like some work, you know, if somebody were given three, six months of good effort and they they knew what they were doing to tackle a lot of the bugs and maybe tidy up some of the more messy parts up to small refactorings just to make it clearer, that would probably be enough.

I think it it's super powerful.

Do I have that right?

I'm not too fairly.

But I mean that as we were offline discussing, I mean, that's that's like an entry-level salary at a Fang company.

Um I guess to me, I think, well, what you know, what what what would be done if, for example, it was a million dollars a year?

Or is it just, you know, it's so much of it as volunteer anyways that money isn't really gonna help because you just need super dedicated people who

I can give one data point.

You sort of put in when you apply for the fellowship, you can request your hourly amount.

And um I put in an amount that was not when I think back to it, it's it was roughly one third of my compensation at Google.

Um, and then as a contractor, you don't get any benefits and you don't get any vacation.

So I don't know if how the other fellows are compensated, but at least for based on US standards, it's quite quite a bit lower than if you're being employed at a company.

I'm in Spain.

Um, these aren't um Marius is in Poland, these aren't Silicon Valley, this isn't Los Angeles, San Francisco, Boston.

So that was my question.

But uh of course, given the limited budget, uh that's a legit question.

I mean, I used to live in Silicon Valley, I don't anymore for that reason, but given how much of an influence a Django Fellow has, that seems crazy.

Again, you guys won't disagree with me.

And I'm not gonna talk about myself.

I'm you know, I'm I do the best I can.

But Maris is just I'm so excited about Maris being hired.

I think you know, I was worried when Tim was stepping down.

I'm like, oh my word, Tim's stepping away, he knows so much.

And then they they chose Maris, and I'm like, oh wow, I can't actually think of somebody better.

That's that's just super.

Um so I'm not sure that the the financial situation means you don't get the best person.

Like it's just the you know

So it it's not just the I mean the fellow pro fellowship program is the biggest expense, but Frank said at DjangoCon that you know it he's he he could raise more if there were specific problem projects to to fund.

Yeah, yeah, yeah.

Uh you know, to do the fellow role four years full-time, you know, how you handle that incessant nature of it.

And it's not just from because you're okay, as a fellow you're paid, but volunteer open source maintainers, they suffer from burnout all the time.

Um, I think I did get a little burned out, and I think some ideas about how to avoid that uh if I had to do it over, would be to set up a separate email account uh so that notifications about Django stuff didn't come to my personal email, especially on evenings and weekends, and that maybe would have let me disconnect a little bit more.

Yeah, I I wrote that I don't really have the same excitement for the work as when I started, and that could just be part of that is just doing the same thing over and over.

It gets kind of monotonous, and um but Django development was less structured back then, and it was really fun to set up a continuous integration.

So before I started, we actually didn't have a continuous integration, so the committers would just apply patches and then run the test locally as best they could, maybe not on all the all the databases, and so then we ended up with someone would commit a patch and then say, Oh, it's broken on MySQL or something, and so the build would be broken for a number of days until somebody got around to fix that.

So I set up a Jenkins integration with um with a GitHub pull request so you can see the status of the checks there, and so that really helped.

And at this point, I feel like I've done enough where the development is structured and things can continue to plot along without me.

One that you're stepping down right now, you know, you finished uh two days ago officially, and so for one question is how you how do you tend plan to turn off now?

Because presumably you need a period to clear your brain of this of the responsibility, and then the other the other part after that would be we're gonna see you again.

I have some other interests.

I coach high school baseball, uh so that's going on right now, so that takes up a fair amount of time, especially in the afternoons, evenings.

Cool.

Um enjoy vegetable gardening, playing clarinet and saxophone, and um one of the big things that's sort of increased in the last year or so is caring from my mom who has dementia.

Okay.

Okay.

Because I often sometimes to myself think, is it am I just tired of Django or I just really need to not look at a computer for a while?

I I wonder if you both can speak about, again, because as a little bit of an outsider, what it what is it, what was the process of of mastering Django?

Because you know, the Django fellow, it's easy to think, oh that's to the extent anyone really knows Django, that's someone who does.

What what were the if you can remember the milestones in terms of when things clicked together?

And I guess each of you came from PHP, so you already had a a background in web frameworks, right?

Because for me personally, Django was the first web framework I really worked with.

So a lot of the pain around just how the web works, I assigned to Django.

And it was only when I worked with a couple other web frameworks that I got some perspective on it.

Um so I'm curious, just what sort of what does it feel like to know Django in and out and what was that process like if you can recall all those years back?

Uh maybe not writing new new documentation so much, but Okay.

And I guess I had to look at the source code at least a little bit to do that.

Um but I don't remember having uh intimate knowledge of Django as much as I do now until I actually started diving in and reviewing pull requests for code.

And at that point, yeah, it definitely helped with learning Django.

I was so I started off building APIs, um building apps and a or websites and APIs with Django and Django Rest framework.

And kind of to use Django Rest framework, I kind of read the docs, but got into the source code and then started contributing, and that's how I knew got to know that.

And then it's only doing the fellow role and having to triage this the the bugs that come in.

It's like, oh, okay, I better really open this bit of code right in the middle of Django that I've always avoided that makes me do that.

And so now a year in, I'm like, okay, I you know, I can open up say compiler.py in the middle of the ORM and I'm like kind of comfortable with it now.

But when I started the fellow role, I wasn't there.

You know, it's it's literally the job of triaging and reviewing the patches that teaches has taught me, you know, I use I could use Django, you know, quite happily, very well, as well as anybody.

But that level that working on the source code every day really that's that was the the the next step up.

Yeah, I agree.

Because I've noticed just personally, it's in the last year that I feel like I finally I finally can take a 30,000 foot view of of Django.

Like after what how many years?

Six years of using it, I finally feel like I sort of get a sense of how it all fits together.

And I'm aware of areas where I don't have total depth, but it finally clicks for me.

I'm wondering if did did you guys have that sort of, oh, now I see how the pieces fit together, or was it more of just a gradual thing for each of you working, you know, on all the tickets?

I mean, there's still areas where I'm not really comfortable uh the ORM would be being one, so

Yeah.

Yeah.

And without those, for me, it just wouldn't be possible.

Like it just couldn't do it.

Yeah, that's true.

No matter what level you're at, you're just looking forward, you're not looking, looking back, which makes it fun, but sometimes leads to burnout.

So did we fully discuss the handoff process to Carlton or is there anything, any lessons you have from slowly stepping away?

I mean, that's hard in any position, and here there's such an uh immense amount of responsibility you've really had just yourself.

Um, but ultimately I think we have to remember that we're all replaceable and uh that can be humbling and also a relief.

What how is it what was the onboarding kind of process?

Tim gave me some starting points, and then so I did that for a week or two, and then I'm like, Tim, I need a bit more help, and you know, and then Tim's very good.

Like when I'll do something, if I haven't done it right, you give me a little tip, and you know, a year later I feel okay, I got kind of got the hang of it.

I still like I I just still don't have Tim's amazing eye for the for the you know the really fine details which he catches every time and I miss, but I'm getting better and I'll continue to improve and I I just aspire to you know be uh to that level of just proficiency.

I I I you know Tim's really he has guided the project, he he has taken it from um you know without CI and all these other things too, it's it's really very well structured now, and you know, if anybody is responsible for that, then Tim is.

Um so for the you know, I have to just say thank you from the whole of the Django community for that because we really do owe you and we love you for all the time.

So maybe that reinforces the replacement, but also I think just the the sort of veil of Django just sort of works, and you know, uh it was only for me, it was only really going to Django Con being like, oh, this these are people who wrote the docs.

It just feels intimidating.

And um, a lot of uh what Carlton and I are trying to do this podcast is sort of humanize Django and make it seem less intimidating and um yeah, and the and the people and companies behind it because it's such a big group.

It's been wonderful to have you on the show.

And thank you for listening, everybody.

We'll see you next time.

Bye bye.