Transcript: Django Fellow - Tim Graham

hi and welcome to another episode of django chat i'm carlton gibson i'm joined here today with

as usual with will hi carlton hi will and we've got a special guest today tim graham

hey guys tim uh tim is uh well 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 finished four years straight as the Django fellow so we're so privileged to have

Tim in and we wanted to talk to Tim and get his take and well hope you enjoy it. So Tim I know

you've spoken about this at Django Under the Hood which we'll link to the video but I was wondering

if you could quickly just talk about your background and how you got involved with Django

initially. Sure so back in college I had an independent study project and somehow I got

involved with Python and then with Django as part of that and 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 it's been a journey since then. So what version of Django was this when you were

back in college? That's a good question. I'm thinking maybe around 1.4 or so. Okay 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 uh i had done a little bit with um java in school and also

php was what i did a couple of small sites with um picked that up in school so that's cool because

i started with php's where everyone seems to go from php into django and python it's like for me

i always describe it as that glass of iced water you know it's like ah what a difference i know

php's why i definitely have the same feeling yeah okay so one thing i wanted to ask about was the

beginnings of the fellowship program and how that came about and you know it's it's origin because

Because Django is kind of dependent upon it.

Yeah, so I worked at Google for a while.

I worked at a startup after I graduated school.

And then we were acquired by Google and worked there a little while.

And then as our software was transitioned over to the Google stack, they didn't need our team anymore.

So I decided I wanted to stick with Django.

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 kick

started the the jango software foundation board to get the program going finally and run a pilot

so when you say you're doing that on a volunteer basis is that you're putting like a lot of hours

there yeah probably part-time um maybe 20 hours a week or so that's a big commitment that's a big

you know that's a big ask for someone to give voluntarily yeah it was just fun for me at the

time but that was a lot that was a lot of tickets ago yeah what was it do you remember the sort of

rough ticket number when you started contributing because we're on about 30 000 now oh i i found it

i have i found the link right i i found the link that you mentioned in your in your talk actually

9,347 so 20 20,000 or something ago that was 10 years ago and so wow so well i'll just jump in

since you were both django fellows 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 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 right so I know

James Bennett and Jacob Kaplan-Moz 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 community 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 and so it'd be like more feature basically like okay a year might go past

and then okay we've got a group of features together and we'll put those out that's my

understanding i wasn't super involved with the process in those days okay and how did the like

so you say the board because of your um activity the board kind of got together and came up with

the fellowship program but was that because they were like yeah we've got to keep this going we've

got to find a role or what do you yeah i think they saw the advantage that having a person

full-time or semi-full-time had and really helped move things along and and then i went to um

something you both are aware of but i only in the last year uh 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 contributors to Django. I was wondering if you could talk about,

yeah, just the community, especially when you started to today, because, you know, you're

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.

Yeah, I really enjoyed those conferences, the Under the Hood in Amsterdam.

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

In fact, there is a proposal floating around to sort of get rid of the core team.

And that's another topic.

My thought on the core team, I think it's like a good thing in that there's all these people who like,

I wish we had a Hall of Fame or something where all the contributors that have made massive contributions in the past are recognized.

But this thought that there's 50 people that are contributing to Django, it's just not the case, right?

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 massive roster of the great and the good.

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

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

Right. That's what I tried to do on the website with the 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.

Yeah. Well, I think, I mean, again, I can speak as being the newest to Django of the group.

I think it's important and kind of mind-blowing to find out who's actually doing the work 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, I mean, Carlton discussed this in his talk at DjangoCon where we first met last fall.

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.

Yeah, it's my...

No disagreement among this group, right?

Well, right.

But it's my one concern about the dissolution of core proposal is that the people who are

doing the work, they've got to be recognized.

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

Thank you.

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

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

Yeah.

well maybe um it'd be great to tim if we could have you just talk about the work of a fellow and

how you've evolved that over time because i think that leads into you've really kind of helped train

carlton who's now training uh another janko i don't know if i'm training i'm wondering

well the evolution of the role maybe and kind of things you've you know how you spent your time

and what you thought about when you started off tim versus you know now as you're handing it off

Sure, so I'll just go through some of the tasks that are listed on the sort of job

description. Each time the fellowship opens up, they put out a post on the Django blog.

One of them is monitoring the security at djangoproject.com mailing list, ensuring security

issues are acknowledged and responded to promptly. 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 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 and nobody really knew

how to solve it so it's i mean it's a real group of people with limitations and yeah you're just

trying to do the best right you don't necessarily know what you know a security issue comes in you're

Like, OK, yeah, I see it's a problem, but how is 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 good solution.

I think, too, as well, Tim, when you started the full-time role, there were a number of just tickets and security things that were kind of languishing, right?

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

Whereas when you're 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 hard work of getting consensus on things, is that right?

Yeah, there's a couple of big contributors who had proposed a number of pull requests, and they just sat there and didn't get any attention.

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

And then the security team, I assume it works in a similar way.

So the way you got involved is you were focusing on documentation and then you were invited.

Is that the same thing?

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

Is that how that works?

Yes, that's right.

And then does it just keep growing in size or at some point people sort of back away?

How does that work?

I have tried to send out mails to the security team and say, you know, like, if you're not involved anymore, maybe you want to remove yourself from the list.

And that's worked reasonably well, I think.

Yeah, I think people are happy to step down.

You know, they know they're not active.

I think some people sometimes people feel bad that they're not active and you shouldn't feel that.

But equally, you know, they can step away.

So beyond security, I know there's some other things as well that the fellow does.

Sure. Fixing release blockers and helping to ensure timely releases.

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

I did a community survey a number of years back, and 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 6, 8, 12 months, something like that.

And I guess we landed on 8 months as 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 are regressions since the previous stable version of Django or bugs in new features.

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

because those ones can't just sit there like you know they need to be fixed timely can you explain

tim about the um long rate long-term 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?

Sure. Let me look that up so I can just talk through it. Starting with Django 2.0, Django

will use a loose form of semantic versioning such that each version following an LTS will

bump to the next .0 lease. So starting with 2.0, 2.1, 2.2 will be the LTS and then following that

it'll be 3.0, 3.1, 3.2 will be the LTS. So the idea there is that in Django 3.0 for example

some deprecated features will be removed so that upgrading from 2.2 to 3.0 may require a little

of work on on your end but you should be able to upgrade from 2.0 to 2.1 and 2.2 without much work

and there was one bit that i really wasn't sure about 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 or have i just picked it up right he's there somewhere

well the django upgrade guide recommends upgrading one version at a time uh that's

what i would suggest at least locally you know yeah 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 and

compatible changes in each version but there should be relatively minor hopefully but in

principle you're meant to be able to jump to the lts or is that not really the case uh well the

idea is you could you can jump without having to make changes for deprecation right okay okay if

your code is running deprecation free on 1.11 then you can jump to 2.2 and be all right in theory

yeah okay carlton sweating because that was the advice he gave us as well yeah in our episode and

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 few at least at least the what I said

last time ties in with what Tim just said that yeah yeah well you said yeah you said similar

things Carlton so okay 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 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 so triaging

involves trying to reproduce bugs 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 that she's still valid on master I try to put the the commit 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 where the issue is fixed and then you can check if an

appropriate test was added along with that okay yeah that's clever um commit um another aspect of

triaging maybe the ticket is a duplicate of some issues 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 track so if

you put site colon code.jangoproject.com into google and then put in a few keywords you can

usually well i can usually find the the ticket that i'm thinking about as as a possible duplicate

yeah and that's where your knowledge of the issue tracker really like just stands out because you

know i'll triage a ticket and i'll be all you know this this this this and then tim's like

ah and this is a duplicate of this one it's like ah thank you tim because there's like 13 you can

also use the there's 1300 open tickets if you use the component filter that can help too and just

quickly look through and see if any keywords

are matching. Yeah, narrows it down a

lot like from 1300 to say 100 or makes it easier and i think that's a good good way for new

contributors to to look at track too is just think about an area you want to work on and focus it

down by by component 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 yeah and what what

do you think um about new contributors because it for me i was maintaining django filter and

framework and django crispy forms outside of django but for a long time i wasn't contributing

to django itself i 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 have

advice for us as the you know how we can make it easier for new contributors or is it just

necessarily how it is yeah i think how you came to it having a problem that you need to solve is a

good way um it seems like a lot of people come along and they don't really have a problem they

just want to get involved yes i think it can be hard there especially if you've never used django

yeah because you don't really know what the real problems are i mean there's tons of open tickets

of small minor inconveniences that aren't really high priority and if they're not a high priority

for anyone then i'm fine leaving the ticket open for as long as it takes so tim i'm wondering what

would you say are the major issues in django in terms of like what are the sort of areas that

you look at and go that's maybe new thought is involved or or some sort of breakthrough or are

there are specific ones that keep coming up i mean you know the admin right that's that's one

that for legacy reasons but i'm curious what else as a fellow kind of i don't have a lot of

complaints uh but on the other hand i don't use django a whole lot these days i know we're

interviewing tim but i've always got an opinion the um the admin like it's great it's super but

there isn't much room i think for having new features and you know because it's so complicated

it 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 yeah no i feel the

exact same way every time there's a new ticket for like oh can we add this new hook to customize it

it's just like we're gonna have so many hooks that it's just gonna be unmaintainable i feel like

So if we had a magic bullet or a million dollars, which I think was the cost estimated to rejig it, how would each of you, if you had unlimited time and money, what would it take to properly redo the admin?

I don't know that it needs to be redone.

Fair enough.

I mean, it's supposed to be for basic scaffolding of a simple admin interface.

You're not supposed to build your user-facing UI in it.

It's not supposed to be pixel perfect.

and i feel like a lot of the requests are just we want to do every single little thing

with the admin and i'm just not sure if that's feasible sometimes it might just be easier to

build a django view i mean if we could we could extend it as 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 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 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's super powerful and yeah well

maybe that's a chance to talk about again you you both are well aware of this but i'm i wasn't

until recently shocked that i think it's the total budget is two hundred thousand dollars a year for

is it the Django Software Foundation of which the Fellows is part of that? Do I have that right?

That's the fundraising goal listed on the website. I'm not too familiar with that.

Okay, that's the goal. But I mean, as we were offline discussing, I mean, that's like an entry

level salary at a FANG company. I guess to me, I think, well, what would be done if, for example,

it was a million dollars a year? Or is it just, you know, so much of it is volunteer anyways that

money isn't really gonna help because you just need super dedicated people who yeah um i'm not

really sure 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 they don't get any vacation so i don't know if how the other fellows are compensated

but at least for based on u.s standards it's quite a bit lower than if you're being employed at a

company but also like you're you're in pennsylvania right i'm in spain um these aren't um maris is in

poland these aren't silicon valley this isn't los angeles san francisco boston new york that was my

question like should the dsf continue that and just take advantage of that geo arbitrage and

hire programmers where the dollar is stronger and where the cost of living is low from an outside

perspective it seems crazy that that's even a question because it should be the best person

but 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 i'm just trying i mean but a i think you

know historically tim's just being the best person um quite simply and i'm not going to talk about

myself i'm you know 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 just super um so i'm not sure that the financial situation means you don't get the

best person like it's just that you know money isn't going to be the reason why someone would

do it but you know they the dsf sponsors django girls they give money towards the django cons they

um you know the the conferences in africa and other places where they're trying to grow the

community so it's not just i mean the fellow fellowship program is the biggest expense but

frank said at django con that you know he's he could raise more if there was specific problem

projects to to fund yeah i think it would be interesting to talk talk to uh maybe the president

or someone on the dsf board and get their take on yeah yeah i did yeah i mean i did want to talk

ask you tim about how you handle the sort of how you don't get burnt out 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

because you're okay as a fellow you're paid but volunteer open source maintainers they suffer

from burnout all the time yeah 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

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 wrote that I don't really have the same excitement for the work as when I started,

and I could just be part of that as just doing the same thing over and over.

It gets kind of monotonous.

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 databases. And so then

And we ended up with someone would commit a patch and say, oh, it's broken on my SQL 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 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.

So there's two parts of it, one that you're stepping down right now.

You finished two days ago officially.

And so one question is, how do you plan to turn off now?

Because presumably you need a period to clear your brain of the responsibility.

And then the other part after that would be, we're going to see you again.

Yeah, so, I mean, I plan to remain sort of involved at least once in a while.

And like yesterday, helping you with the release a little bit and just tidying up loose ends.

I have some other interests.

I coach high school baseball.

So that's going on right now.

So that takes up a fair amount of time, especially in the afternoons, evenings.

Yeah, yeah, cool.

enjoyed vegetable gardening playing clarinet and saxophone and um one of the big things that sort of

increased in the last year or so is caring for my mom who has dementia okay okay so do you think

it's is it django in specific that um you need a break from or do you think it's tech in general

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 uh yeah i think not looking at a computer is definitely

something i'm looking forward to yeah 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 jango because

you know the jango fellow it's easy to think oh that's to the extent anyone really knows jango

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 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 so i'm curious

just 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 yeah so when i worked at the startup company we were using

django as our framework and and i was contributing to documentation and as best i remember i pretty

much did all that without looking at the source code which is kind of nuts in retrospect um the

great dogs you mean so you were you were writing because i think you were writing the documentation

for source code stuff right or maybe well it was mostly about fixing documentation 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 an 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 yeah no entirely i was

so i started off building apis um building apps and 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 it 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 next step up yes i agree so how does that i mean how does that feel for you guys

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 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 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 probably a gradual thing i mean there's still areas where

i'm not really comfortable uh the orm would be being one so that's crazy that you say that but

that's that's that's got to be true for everybody right yeah yeah i mean like if i get a patch for

the orm it's basically unless i see something really obviously wrong it's sort of like do the

test pass and does it could look reasonable and is it covered by tests and if so then it's good

to go but also there are there are there are a number of um contributors regular contributors

who really know the ORM inside out and without those for me it just wouldn't be possible

like it just couldn't do it yeah that's true yeah well that's I mean that's the thing about

programming is we you know I don't think about what I know I think about what I don't know and so

I guess that leads into the you know imposter syndrome 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 do 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 a

immense amount of responsibility you've really had just yourself um yeah i guess i would say it's

it's been somewhat difficult for me to give up control and something that i've shepherded so

closely for a number of years 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 about you carlton what how is it

what was the onboarding kind of process oh super like like you know i so first of all i'm like oh

well where do i begin tim 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 just aspire to you know be to that level of just

proficiency 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 and

i hope more people know who you are because i i didn't know your name until a year ago so maybe

that reinforces the replaceableness 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 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 people and companies behind it because it's such a big group so anyway thank

thanks again for joining us tim it's been wonderful to have you on the show and thank

you for listening everybody we'll see you next time bye