Keynote: Django needs you! (to do code review)

Speaker 1: So hello. Hello, hello Dublin, hello DjangoCon Europe My name is Sarah Boyce. I'm a Django Fellow. I've been a fellow for about a year. That means I'm one of the paid contractors who helps to maintain the Django framework. I really like to play badminton. I'm in a local league. So if anyone is a competitive badminton player, we can always maybe challenge me one time. I'm British, but I'm based in Germany, so if anyone's in the Cologne region at any time, you can come to the monthly Cologne meetup and I will probably be there I'm not sure if you can see that picture particularly well, but

Speaker 1: I want you to try and think what this might be a picture of just for a second I mean it certainly looks like a I mean it looks like a bunch of rubbish but Actually, these are unsolicited donations that were sent after the 2010 Haiti earthquake. And there were so many of these donations that they started to get into the way of uh critical relief supplies. Yeah, which is not ideal. And it's also not a unique occurrence

Speaker 1: after almost every major natural disaster. There is then this wave of donations that come from all these well-meaning people, and it's been called the second disaster because they received so many and they need to deal with it all And unfortunately, sixty percent of these items will be waste. They they don't get used And it really varies because some of it is truly useless, like ladies' belts or winter clothing for a tropical island or Things that they really don't need, but even useful stuff or things that seem to be useful, if that's not what they're after, it it it still will go to waste.

Speaker 1: And I will go on to why I'm talking about that at some stage. But Django needs you. Django is a community-run project It fundamentally doesn't work without its volunteers. It's volunteers who brought this conference today And this is not a new message. Carlton Gibson gave a talk that your web framework needs you back in uh twenty eighteen. And he did it again in 2019 and I'm doing it again in 2025. It's still true that Django needs its community. It won't work without the efforts of volunteers. But usually when I say yes, okay, Django needs its volunteers, it really needs individuals to step up and to help out.

Speaker 1: Most of the time people say, sure, I can I can pick up a ticket. And then they find a ticket, they work on that ticket, they create a PR. And then they they literally can't go any further without the help of someone else because Nobody can get work into Django on their own. At this stage, they need someone else to review their work, to give them feedback, and to, you know, help it get over the line. As an individual, this is as far as you can go And actually, I would say almost every volunteer action within the um the code contributing area of Django

Speaker 1: is probably one of two things. You're either Requesting feedback or you're giving feedback? And things that are requesting feedback are like creating tickets, creating PRs, creating forum posts. Everything you do in that area, you're doing it for another person to look at it and to give their opinion, right? Or you're giving feedback, you're reviewing the PRs, you're triaging the tickets, you're uh responding to the forum posts. And the thing is, is each of those things are either requesting attention or they're giving attention. And attention is finite. We only have a limited number of people who are actually giving out attention to other people's

Speaker 1: work, essentially. And especially when those are volunteers and you can see that there's, you know, only so much time there is to give. And the problem is, is all of these requests for attention, these these requests for feedback, they they build up. And there's a lot of waste that happens in the project as a result of this, because For those who are who are trying to respond to these requests, there's a feeling of overwhelm when you see that they they're gathering up and and you can see that there isn't enough attention to go around. But also for the those who are doing the pull requests and stuff, there's a lot of frustration, a lot of feeling of wasted work, a lot of long waiting times.

Speaker 1: And yeah, not really a great experience all round. So Django needs you. But really I want you to do code review. That would really help. Oops. Because right now we have about 300 odd open PR uh PRs or pull requests In our review queue, I checked this morning, we had fifty-one tickets that are waiting for a review. And it takes on average 319 days to get a review in the Jenga repository for your PR. So under a year. And you might think, okay, well the solution here is we should just merge more stuff.

Speaker 1: We need to merge these these pull requests. But Django doesn't break things. Django is like part of the reason a lot of people like Django is that it's got this strong stability. It's got um You know, and that it's not gonna break on you when you go through the releases. So it's it's not that easy And another thing is it's not getting easier. It's perhaps not so easy to to see this picture, but year on year we add more code to the code base. It grows pretty much Every year, and so every year it gets bigger and more complicated, more feature-rich, and it's harder and harder for there to be a few individuals who

Speaker 1: who know it all. There's only been two exceptions to this rule. So back in 2012 there were a few Django Contrib apps that got removed. And in 2015 there was also a contraband that got removed. And in those cases, we did actually remove more code than we added in that year. But otherwise, continuous growth. And we're definitely Soon going to have a million lines of code that we're maintaining. Another issue is people don't stick around. After one year, we lose ninety-eight percent of our contributors. So

Speaker 1: even though you might invest some time giving people feedback and they learn about the process of of how to contribute effectively to to Django and all this kind of stuff, uh that they they they might not stick around. Some of those it's because obviously they were waiting a long time and all that kind of stuff. Um but the other issue with that is uh Django's release cycle takes eight months. So People will realistically start to use that new feature, that bug fix, probably in a year's time when they upgrade after that, you know, that upgrade. And those individuals who created those features or did those bug fixes, they're not around to

Speaker 1: fix any issues that that they might have implemented in those pull requests and that puts a lot of um responsibility on the people to uh review it and merge it etc that we need to make sure that it's really really really good And so this is hard. This is really hard. But you can help. I feel like there's a lot of people in this room who are very capable of doing Reviews that would really help our community right now. And I'm going to give you a bit of a guide on how you could perhaps approach a review. But it's not going to be the only way that you can review a pull request, so please don't take it that way.

Speaker 1: But before I go into it, I think it's important to explain a little bit of the process So it is similar to I would say most processes that you you work on your code. And at some point you decide it needs a review and you do something to indicate that. You might just open a pull request or you might request a review or something. And then it will get a review and then either you need to work on it again or it will, you know, it's now ready to merge and then it gets merged, right? And that's the same in Django. Oops. But you also do some things that are perhaps a bit unique to Django's process around how you indicate that it's ready for

Speaker 1: review and how you indicate that Um, you know, it it needs more work. So in Django we have we use track, which is a ticket system. And you will uh in order to show that you want a review, you will go into track On your ticket that you're assigned to, you open your pull request, and then you also put has patch yes to say that you have a solution to this ticket. And then you put patch needs improvement, no, needs tests, no, needs docs, no. And once you've done that, it's now in our review queue that I mentioned before. And then when someone comes along and they decide actually you you need to do more work to this, they will go back to that ticket after they've reviewed your pull request and then they will put

Speaker 1: patch needs improvement, yes, needs tests, yes, or something like that. And then if if actually they're approving the PR, what they would then do is approve the PR, and then they might change the uh triage state to ready for check-in. Which is important because in Django we have another person which is called a merger. So only limited people have the ability to merge code into Django. So if you're panicking thinking, oh gosh, what if I approve it and then it gets merged and then I've implemented a I've let a bug get in or something. You won't be the only person who reviews it. A merger will also check through it themselves.

Speaker 1: And they if they thought there was some stuff missing, they would give that feedback and then they would, you know, update those ticket flags and all that kind of stuff. Or they will merge it. One or the other. Okay, so back to my quick start guide. The first step is pick up PR, right? Doesn't seem too difficult. And you can do that by going to the review queue. So the easiest way to find that, in my opinion, is you go to track, which is code. jjangoproject. com And then at the top there are these tabs, and you can click on reports, and then that will have a bunch of links, and then you can click on the link that says patches that need

Speaker 1: review. But all it is is it's a saved uh filter with those those ticket flags I mentioned before. So has patch yes, needs docs, no, needs tests, no, needs improvement, no, and triage stage accepted. So you can pick one of those. Another option is we also have a few pull requests that don't actually have a ticket. Those have recently got labels saying no tickets, so you can filter for them. Those are supposed to be really small changes, and if they're not really small changes, you can say perhaps this needs a ticket. So it should be things like spelling errors and stuff in the docs or

Speaker 1: things that are considered so trivial that that it's just a quick win and you can check through those. My other advice is try and specialize in one area of Django because If you don't, you will kind of get this whiplash where you're going to all these different areas of the code base. And you won't necessarily have the experience where your knowledge is building on top of each other in terms of um what you're reviewing because uh certain areas will have like the tests in a particular place and it will have um a similar style and all this kind of stuff. So If you can filter by a particular component of Django, so

Speaker 1: perhaps the admin or the ORM or Forms or something. then that will give you the experience that you you build on top of you know your knowledge will build on top of it itself and and you will do better reviews going forward. Okay, the next step is you need to pull the branch. If you think that you can do an in-depth review Just looking at it on GitHub, it's it's just not going to work because I like to think of it as If you are going to buy a house and in terms of we're we're gonna merge the code and and this is quite a big deal because we're now

Speaker 1: uh kind of agreeing to maintain that feature potentially forever. So it's almost like we're acquiring this asset. This this code is going to be a new asset that we're getting If you're gonna buy a house, you wouldn't just look at the pictures and buy it. You would probably go to the house and look around and Check if the walls are actually solid and different things that you might not be able to appreciate just looking at those pictures. So definitely pull the branch. We also have a git alias that's in our in our contributing docs, which will make it easier for you to do this if you're, especially if you're doing this on a regular basis.

Speaker 1: Alright, next I would say check the tests. So there definitely should be tests if they're making any code changes. There should be a proper regression test. So if they're fixing a bug, the test should be uh failing before those code changes. So you can check it was actually failing before And that with those changes it's now passing, which might not be the case. They might be testing something different. You want to check the coverage. You wanna uh you can also run the tests with coverage and see which lines are getting tested. You can also play around with uh checking if you remove some code, whether the tests will pass or whether you know that they now fail.

Speaker 1: So check that they've covered all of the different um logic paths that exist in that code. And then the next one would be to test in real life. So have a local test project or any other Django project that you have. install Django from that branch that you've pulled locally and see whether, you know, especially if it's a feature or especially if it's something in the admin, you can check the the UI and stuff, that the padding is alright and and that also, you know, how you feel the feature and does it feel intuitive and is it working when you you know you try and break it.

Speaker 1: And then you can look at the docs. So you've you've done some testing, you know that it's it's got good coverage, you know that you know you feel like the the code works, but Like docs or it didn't happen, right? Docs are really important to Django. And I'm not a technical writer. It's difficult to to do docs really well, but you can definitely do some uh You are a user of the docs. If you uh read through it and you think that those docs, you know, you could you understand what they're trying to say. It reads reasonably well And it's consistent, so I always think it's worth taking a step back and then looking at the full uh page, which is also a good reason to

Speaker 1: and not just look at the uh git diff So if everything was worded in a particular way, except this new function has a very different sentence structure or something, then it doesn't feel consistent on that page. And there's things like that that you can give feedback on that to make it flow better in the in the documentation itself. And then the last bit I would say is, you know, are you are you happy? And which has all of the squishy stuff. So You know, do you feel like the approach is is makes sense to you? Is there another way that you could approach this? I feel like at the end of the review you want to get to the

Speaker 1: point where you feel you wouldn't have done it differently. Like you feel like this is the best way to solve this problem. Is it scoped well? So you might find that um it's a bug in I don't know the MySQL code base or something. But We're changing a lot of different files that are not related to that and and perhaps that's not the best way to do it. Is it following Django's coding style? So within our contributing docs, we do have a bunch of guidelines on what our coding style is like, and you can give feedback that. Okay, actually uh it should this this should be like that or

Speaker 1: etc. And naming, I hate naming. But if you have an opinion on what would be a better name for a um a function, uh attribute, anything, then it's a really good time to to add that. Uh because once it's It's there, we we we will not really rename things because it that we'd have to deprecate and that's that's a lot of work. So if you think a certain name is more appropriate, then it's really important to uh give that feedback. And then just general concerns. So there might be some things which you're you're worried about that you feel like, okay, it would be great if we test this scenario and perhaps you haven't tested it, but you feel like

Speaker 1: we should look into this or uh there might be some things that you're you're just generally a little bit worried about and you want to start to get looked into. So Adding those in just so the author can consider it and see if they've got responses and all that kind of stuff will will really help the process. And then you give feedback and you you know you add all of those comments on on the pull request And then you go to the ticket and you update those those ticket flags like I mentioned before. So those were uh Patch needs improvement, yes. Needs docs, yes, needs tests, yes. If you update any of those to

Speaker 1: yes, then it's no longer in the review queue. And it should be very clear to the author of the pull request what they're supposed to do next in order to re-request a review. Or you're happy, you approve it, and you put that the triage stage is ready for check-in And once you do that, then one of the mergers will be able to see that this ticket is, you know, in your opinion ready, and then they will know that they can now do like a final level of review and check that they agree. So in summary, pick a PR, pull the branch, check the tests, test in real life, check the docs, and then general

Speaker 1: happiness things. So there is also in the documentation itself, there is a um patch review or checklist or contribution checklist. That has uh again a list of kind of questions for different types of um contributions and to check that certain things are done in a certain way. That's also a good thing to go through yourself. We we tell the it's in the advice for a um uh the the author of the PR to have gone through this, but it's also good for you to go through it because people are not very good at checking their own work and uh that will definitely be able to

Speaker 1: show to you if they've um you know if there's stuff that's been missed And really what I think the the main theme that I want people to think about when they contribute to open source projects is to think about your or reflect on your attention footprint. So I think some people are aware of their carbon footprint a little bit, but I think ideally if you can try and give as much attention as you request. Then that would make such a huge difference to the project. Because we certainly have a lot of people who request attention without ever giving attention back to other people.

Speaker 1: And yeah, no, if you're a giver, that's amazing. But just uh, you know, if you were to create a pull request, and I'm not saying that I don't want pull requests, I do. uh to give a review to someone else's just to share the love would be really great And that's that's the main message of this talk, so thank you very much. And then if you can't give your time, you can always give money. Um so feel free to donate to the DSF.

Speaker 1: By donating that enables the DSF to pay people like myself to dedicate time to the project so that we give out this attention to all the different contributors who are available. But I'm uh happy to take questions. Um

Speaker 2: thank you very much, Sarah. Uh you started out by talking about some of the patterns that you've observed in in people's engagement with pull requests and issues and so on. Have you seen those change over time and do you have a sense of what causes them to change, to move in either positive or negative directions? Um

Speaker 1: I I think I think it's interesting what motivates a person to contribute to the project. Um I think some people uh It's really nice when um some people observe a lot before they m make contributions. I think this is a really nice sustainable way because they've taken some time to appreciate how the process works and that they're kind of working with the community to to make their contribution. Uh when people are doing it for slightly more selfish reasons that they particularly need this change

Speaker 1: or Perhaps, and I don't mean this in a bad way, but like we might get a flurry before Google Summer of Code that some people just want to kind of demonstrate that they've done some stuff or I think in those cases it's it's a little bit shallow the the reasons they're doing it and it might not be so uh easy to work with these people. But yeah, I I I don't know. I think that's a really tough question.

Speaker 3: Okay, thanks for the talk. Really cool. Question I heard that the guys from Django CMS over there um that they are uh trying to meditate the the attention problem as you stated it with using LLMs for kind of the first initial review Um apparently like having not enough attention for reviews is a problem. Are you thinking in this direction as the DSF?

Speaker 1: Um I wouldn't say we're currently actively thinking of this. Um I think it's certainly, especially if it's working well with other projects and we can see how that's working. It it it could be something we should investigate. Um and I think it's nice that it might give people um Like an initial thing to look into because the waiting time can be quite long. So the uh there are some tickets in the review queue for months It will we will always then need a person at some stage so it doesn't entirely uh remove the problem

Speaker 1: but Yeah, yeah, it it might be able to buy us a little bit more time um in that in between. But I think that we that in my opinion we we need more reviewers is still still the same. But it's certainly something we can we can play around with and see if it it works for us or or not.

Speaker 4: Thanks, Sarah. So I've put three or four very, very small PRs into Django, and I've sometimes looked at reviewing and triaging And it's always the same people as you are well aware. And maybe it's a bit of a self fulfilling prophecy, because I didn't think that I could review or triage. So is there Is can you clarify? I mean I kinda know the answer, but there 's no requirement for any status or anything like this? No.

Speaker 1: Anyone can triage a ticket, so uh and for those who don't know that means when a ticket is opened, it's opened in the unreviewed state. And it needs a person to uh either accept it or basically close it for that it's perhaps it's invalid or that they can't replicate it, this this bug or issue or something. Um but anyone in the community can do that. Uh 'cause also people you could we can also see what's been changing uh in track and you know if we disagree we can always reopen it and or or or put another comment and us etc. So Those decisions are not necessarily final. And similar with reviewing,

Speaker 1: uh only certain people can merge a pull request, but to uh uh give feedback on on what could be improved, etc. that can be done by any member of the community and Uh it it's not like uh it doesn't count and so it will get ignored. The only thing I don't uh I really appreciate if a person has kind of said what they've checked because to what I wouldn't want is for everybody to just approve every PR without really looking just to be like yay. Um so yeah if someone spent some time to to go through that and has said like okay yeah I've checked those tests etc then

Speaker 1: Uh yeah, it's really helpful. Thank you.

Speaker 5: Thank you for your talk. My question is twofold. First, currently how many full-time Django fellows there are? And the second question is In an ideal scenario, how many full-time Django fellows do you feel it would take for you to be at ease? And to be at ease, I know it's subjective, but it in order to feel that Django is okay, it's safe, is going to be developed for years to come. And basically this is my question. Thank you.

Speaker 1: So we have one and a half uh fellows. One and half only. One and a half only, yeah. So that is me full-time and that's uh Natalia Bidart who who works part-time. I mean I would like more. Um I don't know. I mean ten would be nice, who knows? Uh there is There's plenty more that can be done. So um I think at the minute we and I don't want to panic people, like it's stable, we we do the important things, we prioritize the the releases are happening on time. We The other thing that fellows are are involved in is they're also in the security team, so whenever those reports in those are handled, that actually also impacts the the review queue itself

Speaker 1: because Because of our support policy, actually the new stuff is perhaps the least important stuff because we want to make sure the existing stuff um you know that we recently released is is working and that you know the security fixes are are going out. So Uh I think we could easily have um double what we have, so three, but the more that we have it, it would open up the possibilities of us doing more of the interesting things in terms of more proactively um encouraging those new features in terms of like a a big hitting feature for Django um or us actually

Speaker 1: doing any code for Django because uh it's not that we're not allowed to do it, but um It feels really it feels quite selfish to do right now because there's there's so many other people who are who want their code to be reviewed and it just like adds another thing to the backlog. Um so Yeah, I I would love us to have um you know, if we if we could try and add one in a year a a year at a time and then see what's what what feels comfortable would would be really nice. So maybe I think four fellows would be would be pleasant.

Speaker 6: I have one question about making it more attractive to be a reviewer, for example. Do you know of any other projects that either have like a expert reviewer program like the IPCC or or anything like where you have to have to review something before you get to have the bragging rights of having your code inside a project. Because it seems like there are lots of carrots. That you could put in front of the I I got to have my code in the project thing which might make this part more interesting. And it feels like if that's the bottleneck Then maybe that's the where where with the conversations need to be to say, well let's make the make being a reviewer much much more re appreciated and recognized and like I don't know have more bragging rights associated with it.

Speaker 1: I I do think it's a really interesting topic to go on on onto the motivation of it because it's uh In my opinion, it's it's quite a selfless thing to do because uh when you're the author of the code, you know, you you you get the uh you know it was your commit that did it and it's it sounds better to say oh yes I made such and such rather than oh yeah I I was pretty critical in in helping getting that in. Um so I I don't know what other projects are doing and to be honest that's it well it at least for me personally it it um I don't have enough experience of of of other open source projects and how they're managing things to

Speaker 1: really learn from others there. We could certainly do little things like making sure that that a review a reviewer is a uh a co-author of every commit maybe if that was appealing. It's hard to know what motivates people. So yeah if anyone Has ideas of what could be uh appealing, that would be good. We do have um a review and triage team or triage and review team. Um so There are a list of people who are contributing on a regular basis and they then are on our website as as uh you know, members of that team

Speaker 1: uh and they get um there's maybe a benefit or two so they have some more uh editing rights and track or something like this. But um uh and at least their name is visible and and stuff like that. Um but yeah certainly I think Motivation is is an area that that we could experiment with doing different things to make it more appealing. Thank you. Thank you.

Speaker 7: As a new user of the product, it's often a lot easier to see a problem and ask How can this be fixed? Which is is going back to your demanding attention part of things. Is there anything you can suggest in terms of ways to help support people, to make them feel confident, to be able to say, oh actually I can give my attention, I can contribute to this? Because some of the issues might be you know quite deep in the code base and things that you you need a bit of expertise to really feel like you can get on top of.

Speaker 1: It's a great question. Because for example, I didn't really triage tickets or review pull requests until I was a fellow. There's no magical training that they give you when you become a fellow that now you feel more comfortable doing it. You're just like um it's now your job, so you should start doing it. Um so actually there's probably a lot of people uh The only thing that gives you is it gives you the explicit permission that you should now be doing this. And I think knowing that uh That is something that is appreciated by the project. And you can um

Speaker 1: I mean we we have some If you want feedback on the way that you're doing it on stuff like that, we we do have a Discord chat, for example, which has like a contributing getting started and a contribution discussion that might not something like that uh channels which you can also ask some opinions from other people Um there is no um uh we don't have any qualifications or uh certificates or something that we give out to like, I don't know, maybe make you feel more comfortable. But I think especially if you've done or you've tried to do a contribution yourself

Speaker 1: and you've had the experience of the review from the other side then I think that makes you feel more comfortable giving the reviews to other people. Because there will be there are common things that people miss. Every time and especially you can see who's in uh doing that pull request for the first time because uh On the pull request, there's this like automatic welcome message saying like, hey, da-da-da. When it's their first pull request And so especially for for new individuals, uh, you can you might have like uh you know some of those tips that you can go through. And And even though people do read the or some people read the contributing guidelines ,

Speaker 1: I thought I had read them when I had first contributed, and it's amazing how much you miss. So, you know, having just another person to have gone through that, it it you you will be able to add a lot of value even if, you know, you don't feel like you've got so much experience in in the in the project

Speaker 8: Thank you, Sarah. I've wondered if the if if it would you think it would make any difference if we made the pool of mergers wider? If we were slightly more liberal about who could click the green button to actually resolve the PR in the end. Or if you think that's not the bottom up

Speaker 1: I don't know. It's an interesting thought. Um It's possible because I think uh there's an element of um I guess similar to the the whole motivation thing that got that gossip before, that if you feel like you uh you've been granted that extra rights, perhaps you you take that very seriously and uh you then feel like you you want to do that and there's an element of like um joint ownership like the the feeling that this is that Django is our project and that you feel responsible for the the code in it and that you want it to succeed

Speaker 1: And maybe having that green button will will help you feel that. But I also don't know whether people appreciate the the the safety net that you know they know another person's gonna look at it. Um so It's I don't see why we can't open it up to a few more people and see if that helps. Um and then if not then we can try something else.

Speaker 7: With the uprise of AI generated content, which is already somewhat um coming to Django as well, um, in pull request descriptions. Which to me at least personally seems an um insult on my time when reviewing something, because there is like three pages of pull request description for three lines of code change. Um how do you propose to handle those? Um shut them down early or encourage to uh put more time into it or What to do about it and how to weed them out.

Speaker 1: Yeah, great question. Uh good questions. Um It's definitely a problem. Uh I think we we also got some uh Google Summer of Code projects uh proposals recently that were It seemed very AI generated. I imagine a number of the people f organizing a conference perhaps got that with their talk proposals and things. I don't know. I I think there are um we have some challenges in terms of um uh moderating the behavior of uh people on on pull requests uh because I think there are a number of uh

Speaker 1: things that people do that are detrimental, like random people commenting. what's the progress on this and stuff like that, which I hate. Um and I think there might be um We could certainly have uh template responses to certain actions to say that this is going against our whether this is a code of conduct or something that, you know, that that they should um uh respect the the volunteer time of this community and that, you know, this this is this behavior's not appreciated. I think It's a bit tough sometimes because you uh kind of want to then encourage the right behavior. Um

Speaker 1: So I don't know, but uh the thing with Django right now is there's so many pull requests that you could just choose not to review that one and you review other ones which you feel um are slightly more um in the direction that that you would like to see or the behavior that you'd like to see and in a way it semi-encourages those people to continue to contribute rather than uh some individuals that that are perhaps uh not not doing it so well. Um but I don't know. Maybe in future we can detect these things and uh have an automatic message or who knows. I don't know

Speaker 8: I think it's fair to say that Django Not Space has been a big success in enabling code contributions over the past few years. Do you think there's a space for Django Not Space or a similar project to tackle the review side of things?

Speaker 1: I would love Django Not Space to do a review-oriented one, which just takes some people who want to uh either improve their current reviews or to to get started in into reviewing uh pull requests because it's it's like a slightly different skill and it's also intimidating. Um and I think I would also appreciate seeing certain individuals I know when they review a PR to try and get an insight on how they think. So yeah, I definitely think it would be Uh something worth doing. It uh the main thing is I don't know whether it's gonna be um horribly unpopular

Speaker 1: That uh perhaps only two people want to do this or something. Uh whereas we get the the demand for for getting some support to get you know a contribution to Django is is quite high Uh but I don't see why we can't trial it and see whether actually w we've got all of these conference members who want to do that. So um yeah, I think it's a good idea.

Speaker 7: Hi, thank you. Um

Speaker 8: I'm wondering if you have any advice

Speaker 7: if anyone took up this, take a review, and pulled up,

Speaker 8: started looking at a pull request and maybe came to the conclusion that this is at the wrong level. you really sh it should be fixed at a different layer. You talked about the My

Speaker 7: SQL thing.

Speaker 8: Like I have a feeling I might be like, oh I'm just gonna pretend I didn't look at it. I don't wanna I don't want to open a can of worms and kinda like

Speaker 1: squash someone who's trying to be helpful.

Speaker 8: Do you have any advice on how to how to handle that kind of thing? And related to that, I'm curious if you have any um Maybe you could say anything about how many pull requests ultimately get merged versus

Speaker 7: I don't know what the process was for closing something that it takes the wrong approach, stuff like that. How does it how do you have any feedback on how that works

Speaker 1: Okay, so in terms of giving feedback on uh please please do give that feedback. Um I guess yeah because it's uh It really helps other people also who who who will approach it. It's interesting with some tickets because they have like um some are open for years. So it might not be that individual who eventually finishes that ticket, but the Um because you can see that all the previous uh pull requests that were associated with that ticket, having that history of what people have tried and and then what someone else suggested and it it it's kind of a It's a marathon, not a sprint, and it helps us eventually get to the uh solution that we want. I think maybe the feedback that you could give

Speaker 1: if in that case because This is a logic change. It should have some tests. And perhaps those tests are good or appropriate, etc. That there might be some positive things within the pull request that you can say that, like, oh, okay, I like. like this, this I checked it's a regression test, it definitely uh passes. I can see that that uh this this would fix the issue, but I have uh this and this concern and and we just want to tweak these things. And and especially if you had a An idea of what you think is more appropriate. I think people are really, in my experience, people are really open to that kind of feedback and uh it gives them an something to look into.

Speaker 1: Uh yeah. Oh and you asked something else. Oh the number that gets merged or something. Yes, whatever it is. Okay, so um we would only close a pull request uh ourselves if it was uh spam for example um we sometimes get pull requests for there's a there's a tutorial contribution tutorial things and they're not supposed to create pull requests but sometimes they do um And then we also uh closed pull requests which uh were given a review and they're supposed to uh do some things. Or they said they're gonna do some things and uh it's been

Speaker 1: some months and there's been no uh And or someone asks, you know, are you still working on this after those months and and you know it's another month and and they haven't done something. In that case, we might also close it because it helps other people know that it's n it's available to be picked up But otherwise we wouldn't we do have no plans of just going, okay, let's do a clean slate or something like this, or or we'd will we have some kind of automated closing mechanism um in terms of the ratio that gets merged versus not I haven't checked. We do merge stuff pretty regularly. It's it's almost every day that something will get merged.

Speaker 1: Um but you know, it it's the biggest bottleneck of the project. There's only t to three, four people who have merge rights and um You know, and then the number of stuff that gets through, so um I don't know what the ratio is, but but not super high.

Speaker 4: Yeah, thank you also from me. Um when you explained the process of opening a merge request, getting it uh getting it reviewed, setting the labels on track and and so on And with frequent discussions with replacing track or all this, do you feel or do you think there would be value in improving that interface between GitHub's pull request and tracks issues by heck I don't know maybe adding the labels in GitHub and then they get automatically set in Uh in track? I don't know if that's possible even possible, but like something like that?

Speaker 1: So we're we're getting there's there's certainly some things we can try. So we now have like a very basic uh read-only API for track, we could make it write. I definitely think we should um Have clear logic of uh where it should be updated. Um the I don't know if adding the labels. I'm not sure if I'd add every single label because it would be a bit intense. Uh but we could have a label that's just like letting them know it's in the queue or or or it's not. And then that could be like a quicker way from GitHub that someone could filter for that.

Speaker 1: I think that's feasible. Uh and then in a way I think that's kind of what the experiment with this no-ticket label is, because It kind of lets them know that they might think there's a ticket, but because of the formatting of their PR title, that ticket isn't linked. This is the idea. I don't know if people put two and two together. But then hopefully they know that okay the the something's not quite right here because I have a ticket or something. So hopefully We could have something that says that it's in the review queue and then if they don't have that label, they know that they haven't updated the flags correctly or something.

Speaker 1: Um it's possible. Uh Ideally, I I don't know if it's um just a education thing or um because I do like that that it's uh more I like that it's a human that's triggering it, that you're saying actually I feel like I've done everything and that I want a review Um and I like that you're doing it without uh requesting a specific person to re-review it because it 's for the whole community and and and it's not necessary to at Simon or somebody to say please review my PR again.

Speaker 1: So yeah, but I I'm I'm definitely open to some ideas of of how we could perhaps make the integration a little bit more. sophisticated to to make people aware of the process better and and give uh m yeah more ways that we uh Can encourage people.

Speaker 6: Thanks for this. I appreciated how you described the role of code review as active fundamentally. Get your hands in the clay, delete some code, did the test still pass? Things like that. The reason I mention this is because, you know, you've described becoming more knowledgeable, developing an area of expertise, builds confidence and for people who learn by doing.

Speaker 7: They might think I need to contribute first to build the confidence to be a reviewer. So that occurred to me, you've given people a way to sort of flip that script, you know, that I can start contributing by reviewing and I was curious if you have any other advice to people for whom that might be the blocker um to getting involved like this because they feel like they learn by doing. Anything else that you've noticed sort of greases the wheels of these kinds of first-time code reviewers. Tips for first-time code reviewers in that way.

Speaker 1: Yeah, lovely summary. Uh you could have done the presentation. Yeah, so I do think also having done a contribution yourself Would uh I do think that's also another angle that you can uh get that kind of experience to also see it from the other side. Um I think Also, you can observe other reviews. So you can look at the PRs that did get merged, for example, and filter for them and look at a couple of of those You might see that some of them are done by a couple of different people and see how they approach it. In terms of the uh getting started and feeling that experience, I do think using the contributors checklist or the kind of steps that I said, especially around, you know, just check the tests, check the docs, etc.

Speaker 1: to do it in an almost systematic way so that you feel like You know where to start to look at it will give you some confidence because there will be people who who did just didn't write, they haven't updated the docs, for example. There will be some ones, uh some pull requests which have um quite obvious, well not obvious, but like um there are things that are definitely missing here. And and giving that feedback saying, okay, actually this isn't ready because you you need to you still need to do this thing and this thing and this thing is still uh helpful. And and I do think As I mentioned before, it's more likely to happen with certain people who are new to contributing to Django

Speaker 1: because they don't know the process so well. So it might be more challenging if And I I if you watch the project for a while, there'll be certain names that perhaps pop up again and again. And certain of the more experienced contributors, it might be a little bit harder to to spot certain things because they would probably they've covered the basics. Um so it is really some of the the people who are more new in the community that that perhaps are uh missing some stuff that that are that's also available in the contributing uh checklist. And you can link to the checklist and say, you know, you can have all the all those nice links and say, oh, you know, as per blah blah blah, you still need to do this and this and And I think that's also gives you a way to uh build some confidence.

Speaker 1: Um but yeah, especially if you if you want to do this long term, I do think having some uh choosing an area that you want to uh specialize in, maybe doing a ticket in that area, but also looking at the other PRs for that area and looking at You know, and and the history is really nice. So going through yeah, the the previous pull requests that got reviewed or closed or whatever in that area will also give you some um Experience on that and and stuff, so yeah.