Django's Triage and Review Team

Speaker 1: Hello everyone, thank you for joining. So we are really, really glad to welcome you all today and especially have The guest speaker with us, David Smith, who has been within within the Django community since years, has contributed massively to Django Crispy Farms, Django Bench and whatnot. He's been helping folks around. He has been a member of Django's Triagan Review Team. and he'd be light uh helping us today with how the contributing process looks like around that bench. So we're really glad to have you David. The floor is all yours. Please enlighten us with your insights.

Speaker 2: Thank you very much, Briya, for a wonderful introduction. It's very kind of you. So yeah, we're going to talk about the triage and review team today There we go. So just a little bit of an introduction about me to start with So yeah, I'm David Smith, I'm based in the UK. Maintain CRISPRs and all the associated template packages. So Beach Trap 5, 4, 3, and the Talwind package as well. I've contributed to Django itself since 2020

Speaker 2: and have been a member of the triage review team for um For a number of years and I stood down from that team earlier this year. And there's a couple of contact details if you want to reach out to me as well So today I just wanted to talk about the background to the triage and review team, um, how it came to be. how the team works and a little bit of a an example of what you'll see the team team doing. Then I guess what you won't see on the the website, kind of what's in it for for for you as a member of that team. And then

Speaker 2: a little bit looking forward about the future and then um the question answers at the end. So let's jump in. So first a little bit of a backstory. So deck 10 , which Mm some of you might have heard about was the new governance regime that came in in twenty twenty And this introduced a couple of new roles, so mergers and releasers kind of does what it says on the tin. And these roles were held by the fellows originally as part of the governance regime that the fellows became the first mergers and releasers.

Speaker 2: And really this put into the governance structure of what was really happening at that point in time. The fellows process had been running for a number of years and they had done most of the review and release work at that time. It also introduced the um what we will now call the the steering council, what was called the technical committee at that time. And it also retired the previous Django core title. So that was the previous title where people would have the commit bit access Uh so yes that came in um in twenty twenty.

Speaker 2: Um And then I guess a couple of questions started to be asked as we started to work by those new rules. So the first one is what happens when a merger proposes their own patch? So a merger is somebody who can merge something, can a merger propose a patch and merge it? And the answer to that is no. it needs another merger to approve it to be able to merge it. So here's a screenshot from that sort of period where Mariush, who was a fellow, would propose a patch. Over the weekend, other people would review it. In this case,

Speaker 2: a couple of active contributors, one of them is Tim Gray, a previous fellow. But Mariush wouldn't be able to merge that ticket and merge that all request. until Carlton came in the next week to approve it. So it was just slowing down some of the the um the activity. And this was like a one-line change to some tests, so it wasn't particularly controversial. And the second part of it was about recognition of active contributors. So there's a um all of active contributors to Django, it evolves over time. I guess with that

Speaker 2: retirement of the Django core title, what's the um way that some recognition could be given to the the active community So the triage and review team was proposed, and this is a team of active contributors who can help request um process pull requests um and help spread the workload just beyond the mergers. So practically what does it mean? So you have um two routes, two two I guess

Speaker 2: abilities as part of being part of the triage and review team The first is that you can approve a merger 's PR. So in that example we saw earlier, if a member of the triage and review team was to have approved Marish 's request, he could go on and merge it straight away. And the second is you get granted access to GitHub's triage permission, which allows members to close PRs. on GitHub. Um most of the time that will be closing um spam PRs with there's quite a number of thers, but also if somebody picks up a

Speaker 2: an old PR and updates it and tries to progress it, somebody from the triage and review team can come along and say, here's the new PR and then close the old one. And then it also has that second objective has some recognition for people in that team. So there's the page on the website where all the team members are listed. So that was what the team has written us to do. And then what will you see in the team that the team do? So as a volunteer role, it's um the level of responsibility is quite low,

Speaker 2: which I think is right for a um a volunteer role um and therefore there's no specific tasks that um that person is required to undertake it's um Completely up to you how much you would like to put in or not. And the type of work that you'll see people doing is triaging tickets on track. um and all the work that goes on beside that. So um setting um The correct flags and categorizing issues and triangling issues. That's work that this team will do. I would say the bulk of it is in code review. uh alongside probably proposing their own patches, um

Speaker 2: you'll see most of the team um commenting and reviewing PRs. Um On GitHub, um looking at the implementation, checking for tests, checking for checking for documentation. Um And I think that's where particularly something like the documentation, Django has got a a style of documentation that it has. Because these people in this team have typically been about for a little bit of time, they can usually provide a bit of guidance, say typically we do it like this or um

Speaker 2: Because we've got the topics documentation and the reference documentation maybe it needs referencing in a couple of places And then alongside that you'll probably see some of the team engaging in community sport. So commenting on the forums, maybe the um The new features repo , commenting on what they would like to see added or not, as the case may be. And then yeah, I think that helping contributors bit is just so so

Speaker 2: important. And I'll come on to it, but that's um what I found most most valuable from my my experience in. Uh yeah, so so I guess to to bring that to life to just a little bit of background before I jump in. So um I learned all my Python and Django knowledge by I guess contributing to CRISPR forms and then building up through through Django itself. So all the review and comments that I've had from the community on GitHub is how I've learned and it's just been amazing.

Speaker 2: So um I'll just talk through this example. So this was the change that came in Django 4. 0 that made um the templates be part of the um uh form templates be rendered with the template engine rather than concatenating strings There was a previous PR to this. But I guess to use Sarah's language, took the vulture approach and picked it up and tried to take it to the finish. And I think this was interesting for a for a few reasons. So um

Speaker 2: There's a lot of comments on this PR. There's 182 comments and I've seen it before and I think, oh, that's that's a lot that's possibly a bit overwhelming for for somebody to open a PR and Django for the first time and have hundreds of comments. That's a bit much, but I think in this case I think it actually shows the strength of the the community in the review process that um Yes, there was a lot of comments, but it's all constructive and there's a learning process to to to get the um patch into the state that it needed to be. And we achieved it over quite a short time time frame

Speaker 2: as well. Bearing in mind there was a feature freeze, so it was something that the community kind of um came around let's try and get this patch in ahead of the feature phrase and as part of this Um we discussed software design, so um some of the review comments was you should um Break this out into mixins so there's a renderable interface for both forms and form sets. We spoke about deprecating features and chunking work into separate PRs. Whilst it was the thousand line PR, there was other bits that was merged

Speaker 2: in advance. So some of the testing changes, we could do that first, and then they were ready in place for this PR. Um I think that's a good honor um view of what that team would do. So most of the comments on here would be from people who would be part of the the triage and review team undertaking that that kind of activity. like supporting people, coaching, um and and so on. Um yeah, so this is the list of names that's on the current website.

Speaker 2: Um Just wanted to kind of celebrate and say thank you to the the current um um people in that team. Um And I'm sure you'll um recognise some of the the names. Um so it's quite a wide group of people. Um so um eleven people in that team at the minute. Some of them are on the steering council, some of them are um fairly new members, some of them have been about for a while, some of them are the Django fellows. So quite a wide range of experiences.

Speaker 2: Uh so I guess how do you join the team? How how how how does the the the team management work? So um typically if you're active Um for a little while um the fellows are very good at this. They'll um see people contributing regularly for a little bit of time and then they'll reach out to them directly and say hey do you want to be part of the the the team? Um it's seem to be self-managing so um once in a while um I think it's typically associated with each kind of major release. Do you still want to be a member? Do you want to carry on being a member so people get given the opportunity to step down, which is what I did at the start of the year?

Speaker 2: And then people are always welcome back as well. So just to talk about, I guess, what's in it for me. The first one is just the the people. It it's um So I've been lucky to go to a couple of Django Cons over the last couple of years and I think without that community engagement I would never have gone knowing that there'll be people at a conference that you won't have necessarily have met them face to face, but you'll have spoken to them.

Speaker 2: on the forum on GitHub or whatever. You'll have some kind of relationship with them. And then to go and meet them face to face for the first time is just Amazing. If you get the chance to go to a Django con, I would definitely recommend it. And then having time to chat with these people at the conference and go for dinner with them and and and and so on. Uh so I guess career opportunities um I think being part of the team can help you stand out if somebody's got a long list of CVs. Having that on your CV can

Speaker 2: can help you stand out from the crowd Um and um I guess just to bring that to to life, so look Look at the list. So so um some of these people um um you'll you'll know are active in the community and oh um Tjango Fellows and some of these were Django um part of the triage and review team before they um became a Django FOMO. I think alternatively you might be like a consultant and have clients, I think.

Speaker 2: having that experience of being able to merge tickets, patches, to Django, possibly a little bit more speedily, because you've got that experience of what the qualities requires, got a bit of um community um um engagement being able to um potentially fix um defects in Django itself potentially quite quite quickly could be an opportunity for you. And then community opportunities, so as well as the triage and review team, maybe you want to um

Speaker 2: Become a member of the technical committee or the DSF board or you want to talk at Django conferences or go on podcasts. Having experience of um contributing to Jenga itself I think helps um in all of those. So um For example, at um DjangoCon in Edinburgh a couple of years ago, I gave a talk about the patches that we'd made to the improvements that we'd made to the um all the the forms. And being able to write on my application, I'm a member of the triage and review team. I made these patches to Django, I think puts together a very compelling

Speaker 2: proposition. Um and then I guess just looking forward to the future. So I did this is something I posted on mastered on at the um the weekend. So I haven't been super active lately, but I did decide to review some um patches um more recently and I think it's probably just a couple that I looked at, but they felt very kind of AI generated. And when I commented, a lot of the responses felt like AI. Um responses and I love AI. I I I'm a big fan of Claude, but um I guess I was getting the same feelings from some of the the the comments as I was from Claude.

Speaker 2: What a wonderful insight. That's amazing. And I think that's okay, but then It takes some of that warmth and human interaction away that you need to build a community. So we just need to be a little bit mindful that We're trying to build a community here. So yeah, we need that warmth and compassion and and um um community building spirit because if we want Django to succeed for the long term, we need to build the community for that long-term sustainability.

Speaker 2: I guess I'm not sure what the answer is, but just that we just need to be mindful of it Uh that was it for the talk, I guess. QA

Speaker 1: Yes, thank you so much for this talk, David. This was really insightful. We got to know a lot about how the Try to review up rates and your journey, which is really inspiring. So everyone who's been here, the floor is now open for you to ask questions You can raise your hands if you want to question directly or you can drop it in the chat Yes, Dim. Let's begin with you.

Speaker 3: I thought I was gonna have a second, but yeah. Thank you, David. That was a great talk. I really appreciated getting a lot of like the history and the context of the team that I Personally didn't have. I was hoping it do you have any tips for people um getting started doing code reviews? I think triage is a little bit self-explanatory like repr reproduce the issue um but I think review is probably a little bit for me trying to pick like which PRs to review is always a challenge

Speaker 2: Uh yeah, okay. So um I think If you've got an area or a interest, I would um suggest focusing on that. Um Django 's a big project. Um and I would suggest focusing on a particular um module um would be a good way to start because then you can probably build up a bit of um experience in a certain area. And then there's probably multiple PRs that are open for any particular module.

Speaker 2: So yeah, that's that that's what I would suggest and probably um I guess probably that the ORM is probably the one that's probably always stands out as probably the one of the most complex areas Is

Speaker 3: is

Speaker 2: implementation as is a good place to start as well?

Speaker 3: The the the um the idea of Trying to find PRs in a specific component is the way to do that to go to track and use the component and then find the PRs. Okay.

Speaker 2: Uh yeah. Yeah. So um on track there's the um the dashboard and then from the dashboard it's got predefined filters so you can see um the number of um PRs that are currently in the queue And they're aged and you can see them by component as well.

Speaker 3: Thank you.

Speaker 1: Thanks, Sim. Any more questions?

Speaker 2: Are there some questions in the chat?

Speaker 1: Yes, Ernesto. Please go ahead.

Speaker 4: Uh thank you for your presentation. When I was uh attending one Django co conference in in Europe a long time ago, it was uh the during the sprint that we try to to validate some uh some tickets and reproduce some tickets is how does that fit in the current setup with the with the um mergers and the other people.

Speaker 2: So track is open. Anybody can review um review a ticket. I would say that Probably most of that work is done by the the fellows. Um occasionally um Um, probably Simon. Um We'll comment on a lot of the over um tickets that get that get opened as well Yeah, so so I guess while it's open to everyone, a lot of that workflows and the fellows for triaging the tickets on a on a day-to-day basis.

Speaker 1: So anyone else more questions? Please keep them coming. Yes, Paran.

Speaker 5: Hello.

Speaker 1: Hi.

Speaker 5: Hi. Uh so my question is like if I want to review a PR so like I'm interested in a sp specific component and I'm like trying to review a PR. So like what would should be the like first steps that I should look for? Like running tests, like something like that.

Speaker 2: Yeah, yeah. I think reviewing the ticket would be a good place to start. And can you reproduce the issue that was in the ticket? That'll give you a good understanding of the issue. And then review the um the PR and see if it has tests and does the um the test cover the issue and I guess does the proposed patch fix the fix the test would be the question. And I guess once the patch is um okay and the tests are okay, um

Speaker 2: and you can make sure the documentation is um appropriate as well. Does it need updating? Not all patches need docs updates, but many do. Um if you have a demo project, that's a really good way of of of testing it as well. Um I quite like the um the polls tutorial um that covers a lot of um features so um having a tweak on there to cover the scenario that that that that's being discussed is um is quite helpful as well.

Speaker 1: Thanks. Hope that answers your question, Kuran. Yes, Anisto, were you able to get to know the answer by David? I guess there was some network issue around that corner

Speaker 4: Yes, I I got most of it. Thank you very much. My computer just crushed

Speaker 1: Oh, that's alright. Any more questions? Anyone? We can take one more question. Yes, Lupina, please go ahead.

Speaker 6: Hello. Thanks for the thanks for sharing. That was very insightful. This is a is a follow-up to what I believe team and another of my colleagues asked. Say um you someone uh Of course, you explain how to get started and how to reproduce and understand what the PR is doing. So after you have reviewed and um you have you uh speak with what has been done, what are the next steps from there?

Speaker 2: So the patch has been reviewed and you're happy with it, is that what you're saying? So what 's the next steps once you're happy with it and the person who's proposed it is happy as well

Speaker 6: That is correct.

Speaker 2: Yeah. So the process from there is that typically the fellow would review it. So I would um suggest leaving a comment saying that um you're happy with the patch and that you have reviewed it. Make sure that the flags are set correctly so that it shows up in the in the review queue. Sometimes when patches go through a number of um reviews that the the flags can get um um missed so it's not in the review queue so that's worth um worth checking and then it's um

Speaker 2: It will require a fellow review or a merger review before it gets merged. But making the um the patch as higher quality as you can to ease that that fellow review um would be the aim. For

Speaker 1: the detailed answer, hope Lupyana that answers your question. So thank you so much. Thanks, David, for joining us and doing some interesting conversations and insights around Triage and Review. Thank you everyone for your valuable time and being here. We'll see you next time. Thank you so much