 Thank you for coming and my name is Aniket and I'll be talking about strengthening code review culture in any organizations. So first of all, I have been contributing to KDE since 2016 and since then I was very fond of meeting all the KDE contributors back in India as well as abroad and I tried for coming towards random meetings and also I tried to go for Academy 2018 but unfortunately my visa was rejected and sadly I couldn't make it. But then finally I'm here at Academy and so happy that I made it and was able to meet all of you guys. So again, I actually proposed the same talk last year when our goal was majorly focused on streamlined like getting in new contributors. So for the next 30 minutes we'll start, we'll go through a quick open source story of mine and then we'll start on why code review can be toxic and something that I call a requirement for how and why can code review be toxic. So and we'll talk about how we can, if any toxicity actually exists in any kind of organization, how we can actually try to get rid of them and maybe how exactly we can try to do it and yeah. So within a different perspective because I have been a student, I have been a mentor and I have been an org admin and also yeah and something similar. Yeah, so by the end of the day I believe, since this is the last last talk of the day I think all will be fine. So I'm currently doing my bachelor's, my final year's in Amrita University back in India and so basically there is a students community called FOS at Amrita or right now it's called AmFos. So basically yeah. So this is the group of people, students we have back there who, like the most of them here actually contributes to open source, various projects and whatnot. So we as a group of students after classes we spend a lot of time hacking into various projects contributing to open source and stuff related. Also this kind of community grows because the seniors or the past students who are actually part of this community goes on and amends the juniors who actually join the current semesters and that's how this small students community actually coexist and it's been 10 years since this community has been contributing to in various open source organizations and yeah. So from the beginning of my bachelor's I have been a student of this community and after my first year of bachelor's I have been a mentor for few of the students here and luckily I could say that I brought in almost three students from my university to contribute to KDE and and two of them are here. So I'm so and so starting off in my first year of my bachelor's I took me two months to get my first batching and after that I did a KDE SOC with KSTARS and then yeah as I told I was interested to go and meet all the KDE developers I went to KDE India Guwahati and we met there. So after that luckily I was selected as a GSOC student for Krita and moving on again on 2018 I actually did a GSOC with GNU Linux and was an organ main for KDE as well for GCI and yeah I have contributed to few other various projects in open source as well. So our last year's major goal was to have a streamlined onboarding of new contributors. So are we actually done with that or like we actually released new goals and are we actually done with that goal? Like is it completed or is there more work to be done? Right and yesterday's like there was talk from the goalkeepers that like the most of the contributors actually had one patch submitted and after that they were not actually capable of going forward right like most of them dropped out after that or like and couldn't be a consistent contributors to a KDE. Yeah so the number of people who stuck around after that is pretty much less. So what can be the reason for that? Yeah so I personally believe that like most of the contributors and the community people can actually like communicate mostly through code reviews. So if we have a better code reviewing system then I believe that we can actually make a consistent environment for all the new contributors to actually stay in in the community and build a ecosystem which we all love to work on. So basically yeah so let's start with what's code review. So basically maybe let's say I saw a bug or I saw a feature that which I'm like in a project which I'm excited about and I want to fix that or I want to implement that feature. So basically I actually open a ticket I write the code I open a ticket and I send it through. So there will be other community people who actually have been working with the project for quite some time and they will actually review our work. So that's basically code review. Yeah so like let's say the 101 of code review basically if we have an IRC channel or something similar we have a group walkthrough of the bug like let's say if I just post that bug in bug or a feature in our IRC channel and the team actually goes through it and try to see like if that bug actually exists or something similar like yeah and and the contributor actually resolves that bug or gets the feature done and sends in a patch and if there is a like let's say a person who is actually familiar with the project can actually go collaborate with him or maybe the maintainer can actually if he's reviewing the patch set he can they can both do a pair programming as well and that's how most of the time it has done and at the end a pull request is sent and it's merged. So the plus ones of code review. As you all know the knowledge and experience is shared between the new contributor and the people who is actually reviewing the code right and it should invoke a sense of mentorship between the people in the community or let's say the project maintainers or the project team and it should like enrich the student not students I mean the new contributors to actually come in and work well in an ecosystem like this and also there will be a difference of opinion anywhere in any community so it helps to actually foster debates and it helps people to actually understand what others think of the particular issue and how different it is from their views and helping student helping people to have to do debates and communicate well within the community it brings in decision-making skills which is a highly effective quality in any contributor in the community. Yeah and of course the quality of the code is that will be well maintained and yeah so this is the the crux of this whole talk and code review as it is can bring in toxic unsupportive environment if not done right. So this talk I have split into two a code review which is in a helpful scenario and not in an unhelpful scenario as well. So you could see that like this small snippet of a pull request chat so there's an overwhelming with with an avalanche of comments in the first one and in the second one you can see that just one line one line and says that look like you you're checked in some trailing space on several lines of your chain set our style guides specify no trailing white space can you take a look at this. So isn't that better rather than sending a lot of unwanted comments like that and it creates a negative intensity for the contributor as well and it will yeah so they are saying extra space extra space extra space for every yeah yeah basically our idea is to actually foster all this new contributors and actually start helping them so let's say if he's an he or she's an new contributor and you see a quite a bit of potential for him to be a consistent contributor let's say we start by the second way and if you know him better then let's start by the first way so and this is another scenario where we can see that like let's not leave any contributors hanging without a comment as we in our like caddy's students community we have always been saying that commit early and commit often so something similar communicate well and communicate often so it might help each of the students each of the students are contributors to actually get close with the community and start working consistently and I hope it's visible yeah so passing off opinion as a fact might be an unhelpful and for that it's better to back up your claims with the documentation reference or style guide or whatever you have any API documents or whatever share it with them rather than passing off your opinion as a fact because yeah don't make it your review seek review sequence problem that he didn't find good reference and so so basically asking a devs to fix the problem that they haven't caused might be taken a bit negatively so it's always nice to actually like let's say for an example an unhelpful way was I have always hated how this function is structured can you fix it since you are modifying it anyway so it can create a bit of a negative tone for the contributor so let's say like looks good to me we'll create a separate ticket for great clean this file up so it might actually invoke a sense in the new contributor to actually go and fix that ticket as well because he has already worked in it so asking judgmental questions can also be toxic so like let's say if you ask something like why didn't you just do that or do this let's say if you ask like you can do this and that which has the benefit of that and this so that could that could give him more like it's a part of mentorship which gives you more which gives the contributor a bit more opportunity to learn and understand what he's doing and be a consistent player for the whole community and best benefit us as a community as well being sarcastic can obviously be taken offensive and it it it's not always well right thing to do so again for an example if you ask like did you even test this code before you push it or send it over for review again that can create a notion of disrespect for a contributor and it's always perfect to ask that your code breaks during XYZ test or whatever our edge cases can you address those issues so that gives him more advantage over the code he has written as well and get like the contributor gets a better hold of what he's trying to do so always use a question or recommendation to drive a dialogue rather than just passing a strict comment for instance put all these transitions into a constant file it's not I feel it's not right so instead ask a question and maybe something like what would you think about pulling these translations into a constant file there are a lot and that's there's a lot and separate file might make sense so it creates a kind of collaboration between the contributor and the team and it might actually help the community as such to bring a lot of other contributors so there might be a high performance in your team which may be doing some toxic behavior within the team and sometimes you are reluctant to actually talk to them in person and fix what's wrong so high performance is not an excuse and if there is some kind of such toxicity inside your team or inside your community it's always it can always affect the entire team and it's always better to fix what actually is there and move on also this is something of a greater concern that you might itself be a part of this issue so it depends on how you actually address this case and be a better better quality for your community and as I told for example having supporting a toxic high-performance developer can also affect your team and low-grade its morale of your team always your focus should be on creating a supportive environment if for instance if you are a maintainer of your project or you are a team lead it's or even a developer the way you can contribute to a community to keep its morale always high is to always encourage people to have a supportive environment in your in the project so yeah a few of the helpful ways to actually help and hold on to the new contributors is not to micromanage always ask questions and don't just pass off a comment always encourage for a debate a point to resources if they are stuck respect and respond to every comments that's there and yeah so if somebody is taking for help use that opportunity to actually teach them and don't show off so that they will be a consistent contributor and they can move on with the project later on and as I told don't excuse any unhelpful behavior as the way things are and and this might be the most difficult part maybe asking the people who are toxic to be aware of the fact so you haven't you don't have to be afraid of that it's always better to tell them that this is causing a problem in the team and you can actually change and that way the that contributor actually could evolve as a person and help the community in different ways and for admins or a team lead it's always better to listen to your team's concern if such toxicity actually exist and yeah so I'm not pulsing any content or anything like that just asking all to be welcoming and mindful of their tone and it's all just a trivial communication stuff that we can actually take care of and bring a huge change into our community and hold on to the new contributors that actually comes to our community yeah thank you I haven't to be fortunate enough to be a reviewer for an open source project which gets lots of new contributors sending poor requests a few times when a contributor has many many different issues I'm thinking of the extra space issue but think of all comments being completely different stuff I sometimes feel like I prefer to limit myself to commenting at most five issues with the the changes and if there's more just say no only five wait for the the person to fix them and then review again the rest of the thing I'm not sure however if it's better to review all other ones I I fear that if I have too much feedback it may affect the moral of the person what was your song I think the same like for let's say if the contributor is not well versed with your project or he's actually learning to try and contribute to it or maybe the technology stack is really new to him it will yeah the way you do it will be really helpful like a smaller set of reviews and he can work on it and get back to you again and if that's fixed then you can give them a next set of tasks so it's basically I feel like it's kind of a mentoring process like you are giving a particular set of tasks to be completed in a work which is he or she is actually interested and he can complete that and he can come back to you again so I think that's a right way to do a code review yeah my input being a non-coder is if there's something that's but bothering you like extra spaces all the time then instead of criticizing every new contributor about their extra spaces that you write the bot that helps all of the contributors fix all of the extra spaces because you probably have some in your code too you just didn't get so we have something like a lint that check your code syntax whenever there is extra space it gives you a warning inside the code itself yeah any more questions what do you think is the best way to ping people who haven't responded in a while so like if you if you ask for feedback and you haven't gone it was the best way so in whose experience in the project to ask that what whether they're still working on this or if they have something new to offer I'm not sure if I got your question right like are you asking if oh sorry wasn't speaking to the mic yeah sorry oh sorry so like if if if a new contributor creates a pull request with a couple of new features and you request changes but they don't get back to you what's the best way to sort of nudge them or to ask for an update of some sort with it without being coming across as rude or pushy I don't know I always found that very hard on projects to figure out the right timing or so like are you asking if somebody actually sends a patched request like a pull request okay so what should be our response like other new contributors response exactly so what's the best way to sort of try and deal with that do you close the pull request and say we can't do this at the moment the code base you worked on is too different or leave it open or leave a comment or send email I always find that difficult to figure out do you have any recommendations or like most of the time if for my for my personal cases like when I contribute to multiple various open source organization even I have like gone through such cases where like I have sent a pull request and like maybe took more than one to two months to get feedback on that so basically what I used to do was that if I have a new change like let's say I send a first pull request and again after sometimes I didn't get a feedback back so I'll again maybe it travels through the code again and if I find something I'll fix that and again send the same like fix that and send the pull request so at that point I will act again actually ping them and ask them if they are free to give a response back so basically it's from my context of the talk I'm asking all the code reviewers to actually respond to whatever comments they get so that the contributors don't we don't let all these contributors hang in sounds good what we do we have a bot doing this so if the if the developer comments and there is no feedback within months like no response to the suggested changes there is a bot that pings to people hey are you still working on this patch then does it second time and if there is still no response then it drops the page yeah any more questions I think it's time thank you and you get for your talk