Growing with Django's Open Source Community with Clifford Gama

Speaker 1: Welcome everyone. I appreciate everyone here. We're excited. We're going to have a wonderful talk by Clifford. He's ready. We're ready. I'm going to pass it on to you, okay?

Speaker 2: Oh, thank you.

Speaker 1: You're welcome.

Speaker 2: Hello everyone. Thank you for joining the talk. My name is Clifford. And I'm uh going to be presenting my talk titled Growing with the with Django's Open Source Community. So before we start a little bit about me, I've been contributing to Django since August 2024. And I've been on the triage and review team since mid-2025. So uh That was May 2025. I joined some eight to nine months after my first pull request was merged.

Speaker 2: And a bit of background. I'm not a software engineer by training. And this is my GitHub handle and my website and email. So I'm going to so this talk is just uh is going to be I'm going to share how I how I started contributing and how it led me to join the team And uh I think the path that I took is a reproducible one. So anyone I anyone can do that. So I'm going to start with how I learned Django. So I learned

Speaker 2: uh I'd learned Python in university. Uh And I learned Django a few months afterwards. It was during the pandemic and I was looking for ways to use Python. to solve more interesting problems and to move out of the command line, which is where we'd uh got up to in class And I discovered Django and learned with the tutorials. I did the official tutorial and pretty soon I was building hope projects with Django and I enjoyed it very much. But when the pandemic ended and we were no longer in lockdown, we had to when I went back to school and I discovered uh I was spending some more time

Speaker 2: on Django than on my core studies so I had to give it up because uh I considered it as a s as a serious career option but Ultimately I gave it up because of uh the reasons as follows. The first was I'd learned alone and I didn't know anyone else who was who was doing Django development. So it was like uh I was traveling a path for which I had no map and I knew no fellow travelers. So it wasn't clear to me how I would ever reach a level of mastery uh where I could you know make a career out of this and also uh I felt like there was no local demand. uh

Speaker 2: in my local industry and I also had a mistaken belief that uh about how software is built I imagined that uh software's software engineers work uh more or less like novelists in that they perfect their they do everything they have to do everything right and then publish their their work and afterwards I imagine there is n not much work for them to do. So I felt like uh The mountain, the mountain that I had to climb to to get to that first uh publish was like too steep given these other things. So I I gave I gave this up in 2020

Speaker 2: a few months after it started uh after it learned Django. So that's uh 2021 But in 2024 I started a hobby project that I could only do with that I discovered I could only do with Django So for the project I wanted to be analyzing stories and uh stories that meant uh I had uh a genre that I had picked out and for this genre I had certain hypotheses that I wanted to analyze for for each story. So say for example uh if the the genre was adventure. The way I wanted to analyze it was uh

Speaker 2: suppose we have a hypothesis that for every adventure story the adva the protagonist must be their s what must begin the story in a state where their life is in some kind of stasis. Uh I would analyze uh how all store all adventure stories that I knew of uh fit into that hypothesis or fail to do so. And to do that I turned to Django. So I needed to build this fast because uh I'd given up Django and uh I just wanted to to use it as a means to an end here. So uh during this project I I sometimes I decided not to use the documentation because

Speaker 2: uh that that was too far away. I would have to get out of my browser, look up the documentation, try to find the exact thing that I need. So I ended up inspecting the code in my code edit. I discovered I could inspect I could inspect code that I didn't own. And that gave me my first inkling as to what open source means. The open source code was open for for me or anyone to see. I'd almost always imagined that. it's it's packaged in some sort of secretive format. So seeing Django's code was uh very inspiring because uh my own code at that time looked like spaghetti

Speaker 2: and uh I wanted to understand like why that was and how I could improve my my code. About after the time that I had a working application, which by the way was uh in a little over a week, I started making improvements into my application editing features. and stuff like that when I discovered uh what I thought was a bug in Django and I filed a ticket. uh which was accepted as a document clarification. I assigned myself the ticket. Uh the the assign to yourself button, the assign to yourself link was just

Speaker 2: there and I decided to click it. I had no idea how to fix it, but I wanted to learn more about the process, so I assigned myself and uh opened a pull request. So the the the ticket itself, like the fix for for this ticket was uh adding a very small sentence pointing out that uh No best feels if uh an empty string as a default. But uh we had 28 discussions on the pull request. which was f which was which impressed me very much because uh I learned that it couldn't just the it wouldn't just be merged because it was acceptable.

Speaker 2: Uh those 28 discussions were reviewers and myself trying to get at the best possible solution that we could have. And uh well that that was that moved me. Uh I decided uh after I got my first pull request merge, yeah it is, I I decided to keep contributing to be to get more and more involved in the contributing process. So this is how I went about it. So I started with the the process. Given my ex

Speaker 2: my I had limited experience with code, so this was the only thing that uh I knew at the time because I'd uh read the documentation and got a PR merged. So I'd go around uh looking for PRs opened by new contributors and try to guide them to follow the the the the guidelines uh to get their peer the pull requests reviewed as fast as possible. My own PR had been reviewed quickly and it got merged very quickly and I wanted others to to have that experience as well. From there I also started uh contributing to the documentation

Speaker 2: I picked the documentation because to document something you you have to understand fully the context of that documentation, how something functions. Uh sometimes you even have to go and read uh Django's or tests in Django's own tw test suite to Understand what what you're documenting. For example, one ticket I was supposed to document something and I went into the test uh to understand how it works and I discovered there were no tests for that. Uh I also got to add them as well as part of the documentation pull request that I taken.

Speaker 2: And uh the next thing that I started doing is uh reviewing other people's p pull requests. So what happened was uh because the Django is a large community and it is there are a lot of contributors. uh pull requests sometimes uh move off the shelf very quickly. Uh there are always people claiming uh I'm sorry tickets. There are always people claiming tickets. And uh a ticket that you want to work on can be taken by someone else. So uh in those cases, I would still work on the ticket. Uh uh myself but then uh the only way that I could contribute it to Django was by doing the documentation uh

Speaker 2: reviewing the pool the pull requests of that documentation change. Um in addition to that I would review documentation sections in in pull requests that way not specifically documentation fixing documentation tickets because uh that was an easy way to to enter into into those and also During that time I got to watch uh how the community does things, how uh experts think uh which was quite invaluable, it made me want to stay even more. I finally discovered uh I discovered those uh fellow travelers that I was looking for to master this.

Speaker 2: So uh I also started started triaging tickets. This also ties back to reviewing other people's peers because uh The reason I started doing this was for the same reasons. I started reviewing PRs. Uh sometimes there are no tickets to work on. And I think uh often it's better to Like in in in the present, uh in the with the with the current state of things where we have uh I think there's almost a hundred open pull requests waiting for review now. uh if there's a ticket that i wanted to to work on i found it and it was already taken

Speaker 2: i found it more profitable to to review to review that ticket than to go and uh find uh uh t tickets that are several years old And sometimes I found it better to try new bugs, perhaps uh looking for opportunities to to work on tickets that are not claimed. Yeah, to do this, uh we have to you know re-reproduce the reports, confirm, confirm bugs, and it also corrected my previous belief that uh That software must be so that software is perfected from the initial point of the initial point of deployment

Speaker 2: So I learned uh with more bugs that I tried, I learned uh software is never finished. Like there's always room for more, there's always work to be done, which means uh it was a possible career choice And uh I also, you know, from the sometimes I I tried triage the bug and uh Also, because you have when you reproduce it you have to write tests. So uh that's one step closer to fixing it. Uh the next thing is to write uh to write to write the fix and That's how I started writing code. So About nine months after

Speaker 2: starting contributing, I got an invitation to join the Triagent Review team. And oh that was exciting because I I didn't think that was possible. And also I got to join a team with much more experienced contributors than myself. which was which was a great opportunity to continue learning and uh to get recognition for the work that I'd been doing. for purely personal reasons. My reasons being that I wanted to learn as much as possible to master to to master Django. And for for a bit more context, uh during that time my my day job

Speaker 2: had little in the way of intellectual or creative engagement. So storytelling and contributing to Django fixed, you know, provided the intellectual and the creative for me. So uh looking back at what this has given me. Uh The first is I got to I got to have uh a clear path. It became possible for me to to pursue mastery of of the trade. Yeah, because now I had fellow travelers and uh working on Django itself give gives confidence

Speaker 2: When you're building project projects using Django, also I got to learn the best practices from the lead industry leaders, uh the people who build Django itself. And I can also say that I'm parts of the people who build Django which is which is awesome. The second is uh it gives you it give gave me a high standard to aim for. So Whenever you open a pull request or do a review or triage a ticket, uh you're always you always have to do your best work or if you fall short of that, uh someone will come and uh point out will come and help you to you know move it forward uh do it better and

Speaker 2: the commitment to the c that culture of committing to finding the post possible way that we can do something uh is also something that I think is quite valuable, which I appreciate from. is something that I I gained from contributing. Uh I also got uh the technical growth that I'd I had no way of knowing how to get. I learned from every day from I I learned new things every day from looking at pull requests and tickets. And the learning is never stopped. There's always something new to learn. And uh I got friends from the community, people around the world who care for the same things that

Speaker 2: I do Oh, which is awesome. And uh the opportunity the opportunity to to Belonging in the community also provided me opportunities that uh previously I could not have I could not have imagined uh having. So previously when I said why I why I gave up Django. Uh you notice that I say there was no lo there is no local demand for Django but uh belonging in the community uh made made me made me keep m gave me the opportunity to access uh

Speaker 2: to access opportunities uh not just limited to my local industry but also remote work uh and the like which also makes this a which also made this a viable career option for me. And uh recently I started a new job working on the Clearing House project, which is a University of Michigan academic project Yeah, I would never have been able to get that if it wasn't for for this community. And And uh so in sharing this I

Speaker 2: am hoping that uh There's someone in in in the Django notes there that's uh also wanting to contribute, but I think the hard the hardest part is that uh you're already here and Uh that's awesome. Uh the path from having your first pull request merge to being like a core member of a co-contributor or a top contributor or being on the team or you know, wherever you want to take this, it's much shorter than it looks before it happens. And you can always start where you're confident and you have to stay consistent and Do the work, do your best work whenever you are contributing or reviewing tickets or

Speaker 2: whatever way you're contributing. And uh that's all from me. Uh thank you. Any questions?

Speaker 3: I actually have one. Thank you, Clifford. That was really great. Um I really enjoyed that. And it uh my question is, how did you learn to treat code review comments on pull requests uh as feedback on the pull request rather than you as a person? And so like I know me earlier on in my career, and like I've also heard this from other people starting starting out, they sometimes look at pull request feedback as comments on themselves or like judgments on their skills rather than improvements on the code. So like how did you navigate that and like learn to sort that out?

Speaker 2: Okay, so uh I think that in my case maybe it was different because I knew I had like no experience at all. Uh I knew that uh I was I was here to learn and I I assumed that everyone that I met uh knew more than I did. So if they made a comment uh and if if I was I did I think I did uh refute receive some comments that I that I took personal, but Like I had accepted the fact that I don't know and that these people, the community has much more experienced people than I do. So it was easy for me to accept and uh keep coming back, even though

Speaker 2: sometimes the comments were difficult, but But say in general, the people who do reviews and uh comment on tickets and do try, uh they're also very kind. Which makes it easy to to accept. So does that answer your question?

Speaker 3: It does, yes. Thank you very much.

Speaker 2: Okay. Hi

Speaker 1: Clifford, I have a question. Do you are you involved in any other open source projects?

Speaker 2: Uh no, just just Django. Uh but uh so after about I think at the beginning of this year, that's when I decided. I decided sometime last year that starting this year I would switch my career to being a Django developer. So I did look at a few open source projects that were built by that were built with Django instead of uh just working on the framework itself to gain experience on production projects But uh so I I I had uh a few I had uh some pull requests made

Speaker 2: to the free law project and I also have some pull requests made to mess in work in Wegtail. But uh I quickly got the job uh I was looking for for now and that has kept me busy for some time.

Speaker 1: Oh wow, excellent, excellent. I see James has oh I'm sorry James has his hand raised I'm not sure if it's a question

Speaker 4: Yeah But thank you, Kifford, for for the for the talk. And like the big congratulations for all of your shipment. Um my question is But how did you navigate through really large four-based classes, especially if you are very new to the, you know, toxic data

Speaker 2: Okay, so the way that I did this is like I said before, uh when I I said before that I started with the country the documentation. So when I did documentation, I would always read the tests and read the surrounding documentation to familiarize myself with that particular area. When I I moved on to writing code instead of just documentation, I picked uh I picked tickets that were related to to the documentation that I'd done or tickets that seemed uh small or that seemed small in scope that uh I figured I could I could like read uh the tests surrounding code and get some context to, you know, understand them enough to fix them

Speaker 2: well. And in addition, uh I also my my strategy was also to pick several several Different tickets like w I I would move from the ORM the to the con con to the contrib applications uh Like I tried to solve something from a different component of the framework every time. And that led me to getting, you know. to just be familiarizing myself even if the ticket is more scored, like having worked in a specific in say the admin gives you confidence to look at a ticket uh in that particular area next time So I would say small scoped tickets in the components that you want to work for

Speaker 2: and documentation and tests uh those are the things that familiarized myself that not familiarized me with the code base. Don't know if that answers your question.

Speaker 4: Absolutely. Thank you.

Speaker 1: Mar.

Speaker 5: Um yeah, uh great, great talk by the way. Uh it was uh it was good hearing about your your journey. Yeah, inspiring. And uh I wanted to ask uh about being in the triad and review. And how is that different uh from uh from doing it uh outside the team, reviewing and trying PRs? Uh because I keep hearing about this this team but I'm still not not very sure.

Speaker 2: I'm sorry you got muted for that last part.

Speaker 5: Did you hear the I I was muted during the whole uh question or just uh the last part?

Speaker 2: The last part When you were saying you don't have to do that, you can't do that. Okay, thank you. Uh so Uh this is a team of recognized contributors who uh have worked on Django for uh a con who have worked on Django consistently and uh in some cases Like for a a a bit of time. Maybe that could be for me that was less than a year. So I would say a few months of consistent contributing. uh qualifies you to join the team. Uh as for the work that is done in the team, uh it's no different than what I was doing before uh I joined the team.

Speaker 2: But uh I guess what changes is now as as a member of the team, like any member of the team has permission as uh the trash permissions on GitHub to approve a major spool request, which like is the the the new thing that's different from like from when I wasn't on the team. So often we get uh We get review requests from the mergers, which are the people who merge pull requests into the code base. Since they can't merge their the their pull requests by their own approvals, uh the ma the triagent review team a member of the triagent review team approving

Speaker 2: a majors pull requests uh is sufficient for them to match their pull request if it's small scoped. I guess that's the main difference. Ah yeah that's the main difference

Speaker 1: Thank everyone for the questions and thank you, Clifford, for your insightful and inspiring talk.