 I'm so happy to see all of you today. Guys had a great time with the reception yesterday? Yeah? No? Maybe? Don't remember? Well, I'm so happy you decided to join. Today we will be talking about how to lead projects and open source teams with better feedback. And I'm assuming everyone knows about feedback. We've just gotten feedback on either their code or their paper or something else. So we're going to be looking at how we can improve the feedback loop to kind of get both positive and negative feedback. And we'll dive into that and then we'll look at how to actually deliver it. But first, a little bit about me for people that don't know. My name is Jessica. I'm in my 20s and I'm currently studying computer science. Other than that, I started doing tech and coding from a very, very early age. So I have kind of been on the sideline looking in the open source space for a long time. I've done open source projects before I can even remember. I'm also a maintainer of Pipandop, which is a very popular Python library. That's a wrapper around the Pipandop document converter. Recently in 2023, I joined the GitHub accelerator program, which was a program hosted by GitHub where they took a bunch of projects and put us through a 10-week program to try to find new ways to do sustainable open source, more focus on the financial side. And this summer I had a software engineer internship at Uber where I learned everything about distributed systems and how to work in a team. And that is where probably a lot of stories will come from as well as having to, as well as me having to give feedback to a lot of people from a very early age because people look at their eyes. You'll probably notice something a little bit peculiar. I'm fully blind. We're ensuring that I have to basically be a first for many people. So whenever I've been in contact with institutions, teachers, colleagues, we've always had to work together to try to figure out how to do things and it's usually been me that's been in the position where I've had to give them feedback on how they're doing. So based on that, I feel I have a good basis to talk about this, but we'll see. So what we'll be covering today. We'll take a look at what feedback is as well as we'll try to dive deep into the actual definitions and the different type of feedback that we can give each other, both as maintainers to contributors and contributors in between. Then we'll take a look at what a wider implication of good feedback actually means for the ecosystem as a whole. And then we'll look at how to deliver it, how to phrase it, what to do, what not to do. And we can look at, we'll look at how to combine them and deliver and then at the end there'll be some time for Q&A hopefully. Feedback and open source. Feedback is the way we communicate with each other to describe if something is good, bad, negative or positive and there is a very sharp distinction between those. The entire ecosystem is based on feedback because that's the way we actually collaborate. We always come with suggestions. Just the act of coming with a suggestion to other people's work is a kind of feedback. Without feedback we do not have any opportunity to help each other grow or to help the ecosystem as a whole thrive and continue forward. The talk here will be mainly focused on from a maintainer to a contributor perspective of feedback as well as contributor to contributor. This works both in smaller open source projects and also in larger organizations with inter-team relations. So the difficulties about giving feedback is we don't everyone have the exact same background. I will almost guarantee that everyone in this room right now has their own experiences that they have lived through, their own challenges, the things that they're good at and the things that they're bad at. Because of that it can be easy if feedback is not delivered in the correct way to come into very easy and harmful miscommunication that can lead to demotivation and discouragement for continuing working on open source. I've had the same in my own experiences where a bad example of feedback can both be on the negative side where you have a code review as an example where the only thing people point out is all the things you need to change. Has anyone ever had that happen to them where you had some code you contributed and you think people commented on what things you had to do better? Yeah. Yeah. That can be very discouraging. But the opposite is also true. Where the only thing people say this will be also more contributed in the staff skills maybe where people only talk about your good sides. Is there anyone that's had that happen but people only give you positive feedback? Yeah. That can also be very challenging when we're getting into that. Maybe so. That positive feedback is all the good things the things we get told we get at. It feels very good to be told you're very something. It boosts your confidence of course it makes you want to continue contributing to whatever you are doing that be a project or a team and of course it promotes a positive environment if it runs positive then that means that your team as a whole is going to be very happy. It can feel really good after a long time of negativity to get something positive. Imagine after a code review you get told something positive that can feel very good but as I said it can also be very bad in the sense that you don't actually have anything to work on if the only thing you get told that you're good at things well I'm already good at those things so what am I going to work on? So the example is just this especially if they don't actually describe what's especially if they describe they don't actually describe what is good like with the example we have it's just this is looking good but that's the bad example whereas the good example can be it looks good and then they actually describe what you did well so you know what you need to continue working on so the impact of negative feedback negative feedback is the sense that that's the things you need to work on so again negative feedback can be very easy to miscommunicate or it can also if you get too much of it at the same time it can also make you feel really bad it can get you very down it can get you demotivated and discouraged it can get you want to not contribute as as open as much as you actually wanted to initially but this is where the key is because this negative feedback is how we all grow but the main key is that it needs to be delivered correctly a good example I've had in my personal experience while I worked at Uber was a code review that sounded absolutely horrible in text but that was because again it was in text it was very easy to misunderstand so a bad example of that is just saying I don't like it, change it have anyone had that happen before? I don't like this line of code, change it but they don't actually explain what's wrong with it and what they don't like about it so you kind of have to read their mind which is very bad whereas the good example is that they explain what it actually is that they think is wrong and they give you a call to action that's not just they do this they actually suggest so the broader implications as a whole when people get good feedback and they can feel they're growing they feel as a part of a community whereas if they don't get any feedback or no one actually comments on their things they just feel like they're screaming into that echo chamber in addition they also get very energized to work if people interact with you you naturally get more energized and more happy that people are actually happy for your contributions so in addition to that good feedback also have a waterfall effect where when people actually receive good feedback they will naturally adopt that way of giving feedback as well because one it feels good but they can also feel like you're growing so that will also make them in the future try to adopt the same style of feedback when they have to give it to people if positive feedback if good feedback is giving it would also result in really amazing growth both for the community as a whole and as for the individual contributor they'll also want to come back to your project if you get them good feedback that where it has both positive and negative sides they'll both have something to feel good about while still having something to work on that will make them want to come back to have even more contributing factor in your project as well as maybe talking to other people about your project because of the amazing community some practical tips for giving actual positive feedback positive feedback is most often seen on the software side on the human side of things in many cases we forget to give positive feedback in code reviews as an example tell people if they're doing something right in the code if they have a good implementation of something tell them that you really like how they wrote it or how they implemented this solution to our specific problem that will make them feel good and it doesn't take much more than a few seconds also tell them they do something right either tell them that they're doing something right but don't overdo it that can be reversed very quickly to coming off as being condescending just the main key here is the positive feedback is useless for the receiver unless there's a why tell them why the youth gets good tell them why what they're doing is good and why they should continue as an example it's good that someone can be proactive because it helps getting things done quickly and it's great for everyone to take initiative or good that someone has an eye for detail because it helped us solve this bug that we've been having problems with for the last month and last do it without comparing to yourself don't start talking about what you would have done but there was good what they did just have them actually as we look at the example again they come with a why we like how they implemented it because it takes care of the S cases and while still keeping track of performance there's no comparing it's a good symbol it's good because of something and that fulfills all the criteria for positive side of feedback so tips for giving negative feedback that can be summed up pretty easily people will naturally remember negative things because that's what sticks in their brain but also it's the main thing they work on or can improve on so on the same side it's good as long as there's not too much of it the same holds true for positive as well as negative as not comparing to yourself or say that we don't or I don't in the team try to come up with suggestions ask them first why they think it's actually bad what they've implemented or then afterwards come with suggestions or ask how we can solve it as a team or as an individual contributor and if they still can't come up with anything after giving them ample time to think about it then you can start suggesting them suggestions to improve again with the example just I don't like it change it to I don't think it's a good implementation that first of all opens the floor for a conversation instead of an ask or a tell you explain why you don't think it's good but still they end up with a call to action what can we do to fix it which again it still fulfills negative criteria there's something to work on but it sounds much harder than just a direct ask or tell and telling you that you're just bad so sorry if I make you guys hungry but the main way we can remember giving good feedback that incorporates both positive and negative sides of feedback is by utilizing a sandwich method where we start with positive and then negative and then positive again so why is this necessary as we gone over if you only give someone positive feedback there's nothing to improve on and that might be good but in the short term but in the longer term it will stagnate the project or the team and have no one either individual or team grow but the inverse is also true if you only have negative that will very quickly have people want to leave your team or just not want to contribute as much as they did in the past so positive and why don't we just give them positive and then negative feedback well pretty simple they'll hyper focus on the negative have anyone of you maybe had that happen where you have positive and then negative feedback and you totally forgot the positive because you hyper focus on the negative yeah that's a very common thing we tend to put way more value on negative things so we forget the positive even though it was just said so positive and negative and then positive that's the way to go because if you also just have negative and positive people tend to also just ignore the negative because the positive was said at the end so if you have a method where you do positive and then negative and positive you ensure that people have something to work on while still being praised for their work without it being too much so I have a very funny story about that from my own experiences working both as an open source maintainer and also in a actual big tech company so the story boils down to I have a talk with my manager where he started giving me positive feedback and then he gave me negative and doused up and I had a really bad feeling for the rest of that day because I only remember the negative so it also ensures that your maintainers or contributors won't have the rest of the day where they just feel down because of this feedback so delivering feedback so delivering feedback in a physical space can also be very challenging not just because of the words we say but also how we compose ourselves so very quick tips to help improve that is don't sit opposite each other that way it feels less like a confrontation or more like a conversation if you sit either beside each other or to the side of each other and regardless of if you are at the positive or in the negative side of the method just keep a smile on because at the end of the day it's a conversation and also we don't like being around negativity so people will naturally close themselves off to whatever you have to say and again keep your composer nice keep it in warming and inviting with your palms upwards at least so you have a warm and inviting attitude while you talk and last keep a friendly tone and keep it casual just don't start sounding angry or upset or raise your voice because that only has the opposite effect of closing people off to whatever you are saying an example I have with myself with keeping it casual was when I had my feedback sessions with my manager it was called the formal feedback session that sounds very scary so how do we deliver it online if it's on a video platform such as Zoom or others it works very much in the same way keep a smile on or keep a friendly tone keep it casual if it's on text though spell checking is always a good idea at least that way if it's too hard to read what you wrote they just will skip it or ignore it it also leaves room for easy miscommunication or misunderstanding if people think you wrote something else than you actually did also don't imply anything or just assume they know if you need to refer to something just talk about it not like the thing or you know or actually spell out that you're referring to issue whatever or the thing that happened on this day or like the and of course a good way to always end feedback is they're always welcome to follow up with any additional questions they might have and of course just like in physical spaces the method, the sandwich method that we saw earlier can also still be applied here so in quick summary and conclusion good feedback consists of both positive and negative good feedback has a waterfall effect where people in the future will remember your feedback style and naturally give it on to to someone else positive or negative feedback can't stand alone it needs to be combined just remember to be open and inviting whenever giving people feedback remember it's a conversation where you can grow as the giver you can learn how to manage people, how to give feedback and where the recipient also can grow their skills at and there are other like more software skills and then we have a little time for Q&A if someone have any questions you can just yeah realize this was a little easier for smaller audience but anyone have any questions? yeah I have a question very excellent presentation thank you Jessica and my question is that you just mentioned what's the good or bad example of feedback I'm considering how to perceive those bad or good feedback in the community automatically because we can receive a lot of different feedbacks from issue, from poor request and everyday so I don't think we have enough time to perceive those feedback it's good or bad case by case or issue by issue, poor request review by review they are in a way to perceive that quickly or efficiently thank you okay so to answer that the very some small steps we covered as well that you can start implementing today to make sure that we don't have to go through this process of trying to identify it as feedback givers make sure to both talk about what they can improve but also what they did well that way we kind of mix and match like both of them this mostly applies to stuff like code reviews or if you are in a bigger organization and manage people and you have to hit KPIs or something like that or talking about the actual issue at hand where poor requests that's more where you can start actually going in and reviewing and giving feedback to people I hope that answered your question thanks you mentioned in your introductions that you were, that you are a maintainer of PyPandoc what type of feedback have you received from the python community that I've received both feedback and assistance in the sense that people told me when python 2 reached their end of life they said python 2 is bad, remove it but again that's one side I also got assistance for that many times when I'm a co-changer I leave it up for a few for a week or so mostly for people to comment if they have suggestions because I'm the maintainer I could just merge it right away but in that way we actually I ensure that people are on board with the changes I decide to make or the way I have decided to fix an issue usually the kind of feedback I get is from either from people that either ask clarifying questions or they suggest other ways to do it and that's where we can again have that conversation where we can understand where you're coming from and we can together find the best way moving forward thank you and to follow up on that you said that you'll usually wait a week for people to comment on a PR before you merge it do you just wait that week or do you reach out to the community to say hey this is a pretty big new feature that someone has put in what do you all think are you proactive or do you just kind of sit back and if nothing comes you just merge and how do you make that decision on which way to go typically if there's already an issue an issue out for it I'll tack the original kind of discussion the people that had the discussion in the issue and say hey there's a poll request out for it feel free to let me know what you think about it if it's a new feature where there's not an issue already I typically go to the pandoc discussion groups there because they know of me already I make a poster saying hey I have this poll request for the python wrapper of it what do you guys think should I do anything differently if there's an ongoing discussion already or I have to be the one that takes that initiative thank you hey Jessica thanks a lot for the presentation there is a lot of good things to I'm going to consider for my future feedback so the question that I have is as a maintainer how do you deal with the apathy when the I mean you mentioned about receiving good or feedback or bad feedback but what about those cases where the contributors or the people are not willing to share any feedback at all like neither good one or bad one so how do you encourage to the contributors or to the maintainers to provide feedback yes so that's almost in a topic in itself I can give you a few pointers but we can also talk about it offline if that would be better but the few pointers I have found useful is have of course open discussions don't just use issues as an example issues on github or githlab to just for code things or things that are not working but use them as a way to actually gather feedback started an issue where you ask okay we have a new upcoming version we have these features and what do you guys think what should we prioritize first like keep the discussion open and don't just limit it to code specific and I think it also both a way to share feedback openly on github but also get in contact with the maintainer team or you if you're a single maintainer just like privately through twitter or something else to make that obvious in the readme as well should be under the contributor heading or in the code on the contributing like file how people can provide feedback and make it clear that we are not just looking for code specific feedback but also feedback about governance or documentation or similar other non-code related topics but again it's a whole thing in itself how to actually get people interested so we can talk much more about that offline if you want of course there's the thing with feedback and gut feeling which is really hard because you said that bad feedback is I don't like it change that but sometimes when you know software and somebody changes something and you have the gut feeling that this is not a good choice but you cannot really explain then it's hard to give feedback on that yes I totally understand that point but I make the counterpoint that there's always a reason for wanting to change something either because it's not a best practice or because there must be something that we can link to or say it's not a good idea because I don't know these people had it before and it's just that didn't go well for them or something like that there must be there's always a reason for gut feeling whether we remembered or not we have probably read it or seen it somewhere before I'm not discounting your question or your feelings I just have a very strong belief that everything happens if we got feeling we get is for a reason but again the other thing is like then switch it around and say okay I don't think it's the optimal solution can we find another solution that solve this problem better because that way you are letting them know that it's not actually their thing that's bad you just think it couldn't be done in a smarter way without putting the blame on them if that makes sense thank you for the talk first of all when talking about this feedback cycle basically for pull request or something like that I guess especially for larger open source projects there is now more and more bots basically involved in the conversation right you push your merge request and the first thing that you get back is a very angry linter telling you this is not the right thing to do and I guess like people in IT tend to accept this part to a certain point because it's not a human giving feedback but it's an angry linter and it's a machine right yeah that's just funny but what is the like general what is your opinion on this limit there because like I had personally experienced invested a lot of time into writing code and I had the feeling after some weeks only talking to bots there basically telling me yeah this is not good this is not good that is not good do you have a feeling there's a like a limit where human interaction is needed to a certain point for pull request or do you have a feeling there you first have to pass this this bar of the machine needs to be happy and then humans can join the feedback cycle yeah so for the first half I think it's definitely important if at all possible for these bots to give the context so many times when we see these lenders it's just it's bad but yeah okay we have like code coverage of your your your pull request give code coverage of 82% but what's the standard in the project is the standard like if his standard is 95% and then there's maybe something to work on but if his standard is 75% then all of a sudden you're doing really well and I have seen many projects where they use these automated bots, linters, code coverage, test reviewers and so on but they don't actually provide any insight into what is the standard how's the master branch looking with code coverage like how are we doing on main are we are we back are we like behind or forwards it's all about the like reference point so I would say if at all possible if to change the bots to link to the like the coverage or the lending before the the the pull request or put it in the main read me for the second half I definitely think that even though the bots are being angry at you humans like shouldn't wait until the bots are happy we're coming with feedback constructive code code or non-code review and feedback I definitely think as soon as the pull request is open that that loop can begin regardless of the bots the bots are here to ensure like automated code quality but they're not there to reason about the actual functionality of the code so I think they can run in parallel thank you of course we have a little more time is there time for one more question yeah that's plenty of time as a woman and as someone who is unsighted unsighted do you do you think you receive feedback differently from your peers and if so what are ways you think that people can equalize the playing field and how they provide feedback to everyone and not just you as a woman or you as a person who is unsighted yeah it goes back to what I said earlier about keeping the standards for the project for the team like open and available for everyone like if you're working in a cooperation and you need to hit KPIs or similar keep those KPIs open for the team or at least if you can't do that because it's individual to everyone then have a company wide average for your position if you're a junior or a senior software engineer then have an average so you know what you should hit so you know you're not getting low-bold or high-bold depending on your diversified circumstances and on the other hand it also just comes down to trust and see people talk about you're the one that's giving you the feedback are they getting really good feedback while you're getting like trashed or is the other way around that they're circuit coding it for you while actually giving more constructive feedback and of course second thing is you're always welcome to tell the people that's giving you the feedback how well you receive that feedback again it's an open conversation and you're allowed to give them feedback about their feedback to you as well I hope that answered the question if we can always talk about it offline I would love to thank you time for two more questions maybe if anyone has any maybe yeah thanks for your talk I wanted to switch this a little bit when we talk mostly about contributors right now so how about feedback from users because we are a little bit more on buffed the stack so that users directly interact with our project and I think we have okay feedback culture with the maintainers and contributors but we have sometimes problems with users because they expect basically enterprise support from a free time open source project what are your thoughts on how to provide feedback for them that this is not to be expected well first of all I've had some experience from that from the good hub accelerator program so if you want to dive into that later I would be happy to have a chat with you well there's two sides one if they expect enterprise support if it's like a tool that's using your software in a small medium or large business then give them enterprise support figure out how you can make it financially viable and build from there but if you are not interested in that give them specific criteria to give you feedback give them like a form it's really difficult to figure out what you're going to get if you just say hey give us feedback and then a form where they can just write whatever ask like what do you think is good what can be improved, what are your annoyances what are you happy about give them actual more specific sub prompts of specific things you want to measure yeah we use this GitHub template for discussions so basically the issues are closed off for continuing a normal landing page for users in other discussion pages with templates but usually they ignore it then I would honestly say send them a nice message in the issue say hey please use the template and if they keep ignoring it then just say we have a template for a reason please refer to our contributor guide like how to provide your issues I'm sorry but you need to follow the template be nice about it but be firm in your boundaries and then close the issue ok thanks you do this with labor space but thanks for your feedback I think that's all we have time for today but if anyone wants to ask me more questions I'll be around here for a little longer right outside the room but if not I'm so happy that so many came out thank you everyone for your time thanks for listening