 Hi. Thank you for coming to our talk. We had, so we are the Code of Conduct Committee minus one person who couldn't be here for the Kubernetes project. And so a lot of the types of things that come to us on the committee were sort of the inspiration for this talk. So we had the idea that how can we help the community, how can we kind of like be a little bit more proactive. And so this is our first kind of foray into that, well, second technically, but actual like dedicated content foray into that sort of a mindset about we're going to start helping people to build the skills to be more successful with communications in the community. So moving right into that, I already said who we are, you already know why you're here. What we're hoping you're going to take away from this is just sort of the tools and the mindset to go into what might otherwise be slightly difficult interactions, giving feedback can be very hard, it can be very emotional. Going into that with tools to be a little bit more successful, make sure that you're received with the intent that you're trying to give. And then when that you are receiving that you are receiving with an open mind from the from the person providing you that feedback. So we're going to ready sweet. Thank you all for coming. I'm going to kick you off with some things that you can do in order to prepare for that feedback meeting for when you're starting to write your feedback comments on a PR or about to have a tough conversation. The number one that I say is to make sure to prepare the last thing you want to do is just be in a situation where you might be feeling more emotional, more agitated, and you might say something that you might not want to say, or you might not be able to deliver it in a way that is comprehensive to the other individual, but also in a very human way, because at the end of the day, we're not computers, we all have feelings, we all have tough days, and we want to keep that in mind. We have to start off with thinking about where you're coming from, like, what is a situation and what are some of the biases that you might have. You might have worked with this other person in a prior project and had an incident with them and this new time, like two years later, you might have some biases around this situation or certain SIG. Try to keep those aside and look at the situation in a new lens. You also want to remember to be very empathetic. We try to tell folks to treat one another as you like to be treated, so lead with kindness, and that's something that you always want to keep in mind as you're preparing for that great feedback, that harsh feedback. We just want to make things better. We also want to avoid being dry, and Xander has some things on how to go about that. We want to be short and concise and straight to the point. Nothing too long. You don't want to drag out a conversation. You don't want to leave three to four paragraphs of just rambling about how something makes you feel. You just want to get to the point and help that person be better. We also say to not start out with bad news first, and you'll see shortly in an example what that actually can look like. We want to make sure to start a conversation with an open dialogue, make sure that that empatheticness really does carry forward, and whenever possible, make sure to provide examples. It's really hard sometimes to come up with examples, but think about the different interactions that you've had with that person where a situation may have not gone the way that you want it to go about it, or where in a PR conversation there has been dialogue that has breached code of conduct has been said with hurtful ways. And a big part of giving and receiving feedback, especially in open source, but also in companies, is taking into account the relative position and the power dynamics between the person giving and receiving feedback. As an example of that, if you are a maintainer or a project reviewer, you have a lot of power within the project relative to someone who is a new contributor opening their first PR. The way you interact with people who you speak to all the time is very different than a random stranger or future friend, but it's important when you're giving that feedback to them to sort of be approachable because they often look up and respect maintainers of projects. And so if someone comes to you, you know, a lot of issues are someone's trying to get something done for that job, you know, someone uses Kubernetes or like SCD or whatever. They tried to do something for that job, or they got paged at 2 a.m. and woke up and they're feeling pretty bad. They might be a little bit tusse and aggressive with the communication style and it's important to sort of come back to them with kindness and not escalate the situation. And on the flip side of that, you know, if you're a new contributor or an end user filing issues on a project, you do it because you care about the project, right? You don't open issues on things randomly. And so you've got to remember that maintainers want you to succeed and they want you to do well with what you're trying to do. But sometimes they're competing priorities and something isn't going to get addressed right away because there's far too much to do. Like I reset my GitHub notifications like two weeks ago and there's like 500 of them right now. Like there's too much to do. And so remember that we're all like trying to make things better together. And you know, just because someone can't work on your thing right now doesn't mean we don't care. And so as much as we understand your frustration, please don't get angry and GitHub issues. Some tips that we also wanted to put forward when you're coming about giving that feedback is that you can also reach out to other folks for help. So it comes in like, at least in my experience, giving feedback is extremely hard. I lack that confidence of like standing up to someone and really speaking my mind. So what I do is that I practice with a friend and it's like, these are some of the things that I want to say, can you help me write them out in a clear and concise matter? Or how is it that I can actually word this in a friendlier way? You can do that with a friend. You can also leverage online tools that can help you figure out if your messaging actually makes sense. And we're also the Kubernetes code of conduct. So you can also reach out to us and we can help guide you to success, whether it's your tone, whether it's certain words, or maybe even just like talking through a situation for you to figure out what is the type of feedback that you want to give to that project to that maintainer, to that other PR, to that other person in the PR. So that kind of leads into what I wanted to touch on here. And that is that when you're dealing with online communication, tone is very important. You know, when you're writing something, you've got the tone in your head, but that doesn't always carry across in text. When you learn sign language, for example, you learn that the facial expressions you make are just as important as the physical science, because that's where the tone comes from. And it's not always there with just the words. So if anyone has ever communicated with me on Slack, I do apologize for all of the exclamation points and emojis that you'll see, but you probably know that I wasn't being hostile. So the example on the side there is like the first line of text really is an okay thing. Like the person that wrote that probably meant that the, you know, whatever PR was being was in good shape, but there are a lot of ways someone can interpret that. So when writing text like that, there's always something you can do to just kind of read through and make sure that the impact that that text being read by somebody matches the intent that you, you know, set out to convey. And the next thing here, so anyone that knows me might know that I do pottery and I'm insufferable about it. And I think there are a lot of things in the art critique, like world and practice that can apply to this. So I wanted to kind of touch on that and, you know, point out those parallels. So if I'm looking at that mug on the left there, you know, I picked that up the handle, it's not super comfortable. And so if I am doing a critique of that piece, I might start by asking the person that made it, what was your intent with the handle here? What are you trying to achieve? Because there's something that doesn't feel quite right about it. So like I want to understand what you were going for. And they might respond with something like, I wanted the handle on this piece to be a prominent part of the mug. And I wanted to draw your attention to that. And so from there, now that I know that that's what the person is going for, I can try and say like, well, maybe instead of this round shape, you could try adding some of these flourishes onto the handle, like the one on the right, and change the shape a little bit. That way it's more comfortable to hold. But it still has the effect that you were going for, which is drawing your attention to that part. And so it comes down to when I think about applying that to what we do, you know, code is also art. I think it's important to approach things from a place of curiosity and always making an effort to understand what the person was going for. And rather than enforce your viewpoint upon them, how can you help them achieve their goal rather than shift it towards your own biases? So this gets down to like, what is the strategy, right? There's a pretty common classic, if you will, strategy known as the sandwich strategy. And basically, it's you take a good thing, and then you put the bad things or the negative things or the not good things in the center. And then you end on a good thing, right? So sandwich. And this kind of helps to, it's almost a little bit of a social engineering thing, right? You're kind of helping to like manage the emotions of the person to whom you are communicating. You're demonstrating appreciation for their efforts. You're demonstrating appreciation for their work. You're demonstrating that you understand and value their position and opinions. But you also still give that critical feedback. And so I just wrote up here an example of what that might look like. This is literally came from my imagination. There are no real GitHub issues that look like this as far as I am aware. But this is what I would recommend. And this is the type of thing that I've been coaching engineering leaders in my organization to do as well. Because sometimes what happens is we review something. And we say to ourselves or to other people in the review meeting, all of the good things about the pull request. But we may notice, oh, there's a typo here or there could have been a potential different implementation strategy, but they might have equal weights. So it could be dealer's choice on which implementation way we go. Right. So you can get all those things. And so what I saw happening in my organization was all of the good things were happening live on the meetings where we reviewed things together. And the only thing making it onto the comments were the bad things, which is fine-ish if everybody is present for the meeting. But when somebody has to go take their sick kid to the doctor, and they don't go to the meeting, and all they see is the negative things left on their PR, they feel unsupported by their team, they feel undercut by their leadership getting back into that power dynamic issue. And so by coaching my engineering leaders in my organization to start applying this strategy instead, we actually went from somebody feeling like she didn't belong on the team and she wasn't valued to now she is the functional leads understudy. She feels supported, she feels empowered, and has completely changed her relationship to her team by having them change the way they are providing written feedback. So that's a really critical component of success within a team, success within an open source community, just having good communications and having a good path forward for your engineers. Now, obviously, you can't always agree with a pull request. Either the feature that's requested or attempting to be implemented doesn't align with the strategic direction of the project. That happens. Maybe you really don't think that the implementation strategy is the correct one. There could be some style issues that cause it to not match. It could introduce a new component that makes you uncomfortable. We need to balance our technical debt with our features. That's really important. So, you know, this is probably an even, again, like overly, overly nice example of it. You don't have to be quite this flowery. But generally speaking, the most important thing to do is acknowledge the effort and the time, because we're pretty well all doing this in our free time. And approach with curiosity, right? Ask them questions about their approach. Ask them questions about the feature ask, ask them questions about, you know, if they've set it up to a component, provide some of the other things that you might have thought about, right? Give them paths forward or invite them to come to the community meeting or to chat more directly or, you know, something with a little bit more opportunities to convey tone than, you know, the kind of drive back and forth on the GitHub issues. Not that asynchronous communication can't be successful, but it just gives you a set of options to kind of pull from for trying to be successful, including, you know, creating a synchronous opportunity. So again, when you don't agree with somebody, you don't agree with what they've tried to propose or whatever, like, that's fine. But do give them a path towards success or help them to be successful, you know, further down the line, whether that's suggesting to them something else that may solve their use cases that they're trying to cover. However, that looks helping people understand what a path forward is, as opposed to, you know, just a no with a like closed door. That's going to keep people engaged with the community. That's going to keep people coming back. That's going to help people, you know, appreciate the know for what it is, and then still want to try again in the future with something else. And that's going to be really critical for us to continue to succeed as a community is that we have people feeling like they can do things here eventually. So on the other end, right, as Xander mentioned this, and I couldn't agree more, software engineering, at least for somebody completely not artistic like me, like this is my art, right? And so a lot of times when we're the person receiving that difficult feedback or being told, hey, you know, I don't like your implementation strategy, right, whatever it is, like that can be that can hit emotionally, because this is this is a part of you a part of our core identities often that is on display and being critiqued. It's not just code. So it's really important to kind of take a step back and appreciate the other side. You know, try to have empathy for them. There's no like, SLA, right, we don't have an agreement on how fast we have to respond to things. I know it feels like we need to respond to things as soon as we see it, but it's actually good either from the giving or the receiving side to take a step back, separate yourself emotionally from it for a little while, maybe talk to a rubber duck about the situation or what have you so really like finish processing and then take the feedback in with kind of that opportunity to step away emotionally a little bit. 99% of the time, it's not personal, right, a rejection of your of your PR rejection of your feature proposal. This is not personal. This is just business. So we, you know, trying to keep that perspective. And you know, if someone says no to you, do the same thing that you would expect them to do in saying no, approach it with curiosity, get more information, learn more, continue to put your best foot forward. And yeah, go feel your big emotions in through whatever your healthy outlet is. Obviously, you're more than welcome to do that. But try to understand that none of this is personal. And once again, we wanted to remind you that if you ever feel like any of the interactions you're having on community calls on PRs with other maintainers with some other folks of the organization are not in line with the Kubernetes code of conduct, you can always reach out to us and we can always help you understand what is going on and give you more resources. And we can sit down with maintainers on calls. We've helped do trainings to provide them better ways to give feedback themselves. We're always happy to help us. So feel free to reach out at conduct at Kubernetes IO. And with that, we wanted to open up for questions that y'all might have regarding feedback or just code of conduct things. Before that, I just want to say thank you all to, I mean, we did a talk like this in Amsterdam and way less of you showed up. This is wild to us really. So honestly, thank you for being here. Hi, my name is Sasha. I'm engineering manager and I wanted to actually challenge you on the sandwich method because myself, I know this technique and when I can detect it being applied to me, I feel manipulated because it distracts from the main message from the constructive feedback. And I was just thinking that in long term, it can actually ruin the trust because the person who feels they being used this technique against can say, okay, probably this manager can is not being authentic with me. So yeah, I just wanted to challenge you on that because I personally prefer not to use it. And just to be vulnerable and authentic with my reports, I normally give them choice. I just tell them, there is constructive feedback I have and positive feedback, what would be your choice? Yeah, because otherwise, this technique is very famous. And I think at this moment, it's actually causing more damage than good. So in the context where you have a team and you work with them all the time, it's far easier to learn individual people's communication preferences. Things like the sandwich are mostly useful in open source when you're dealing with people you don't know. I also personally hate being on the receiving end of it. I'm quite autistic and I just kind of go, yeah, yeah, just let me read them a little bit. But not everyone is like me. And so tools like that are useful for dealing with people where you don't know that background. You don't know who they are. And so you want to be a friendly face while also giving that feedback. I'll also add, I hope when someone uses that method that it actually is coming from a place of a genuine place, but thank you for sharing that because it is something that I think we can keep in mind. I appreciate you having that context. I saw one here and then over here. Oh, hang on. We got an actual mic has been handed out. I've got a real runner now. Okay. Is it me? Yeah. Okay. Thank you. Yeah. Thanks for presenting this talk. And so when I give feedback to some people, sometimes I find people tend to get defensive sometimes. And it's kind of natural. I mean, people want to protect themselves. So inside, would you mind to share some tips or some practice? Will you hit this kind of self defensive situation? That gets so rough because there's a lot of context to those situations that may lead to that defensiveness. It could just be the way that person is. It could be the way they interpreted what you had written. I think honestly at the end of the day, it's one of those things where trying to provide a path forward can be really helpful. And then continue from that place of curiosity, empathy, and kindness. There's only so much you can do to manage somebody else's emotions. And if they're going to continue to be highly emotional in your direction, like there also ends up being a certain degree to which you have to determine what your engagement looks like going forward. And whether that's you're in the open source community and maybe you can actually rely on somebody else to try and take over the conversation with a different communication strategy, or whether that's you're within an organization and you can rely on somebody else for kind of the same type of thing to kind of help. Maybe they have a closer communication style than you and that person does. At the end of the day, I think that kind of ends up being you're not going to be able to perfectly communicate with everybody always. So if you can rely on somebody else who may have a more successful time communicating with that person, that would be a good opportunity to leverage your community. Or if you don't have anybody like that, you could always just reach out to us. There doesn't have to be a conduct violation for our committee to come in and try to be helpful. Okay, thank you. I was also just going to add one little bit, which is also apart from offering a path forward, you might not know what that might look like. And when someone's coming off defensive, we do have to remember like everyone's human and we all have reactions. And one of the best things you can do is also offer some time, some like, let's touch base in two hours after you've thought about the situation or like, let's touch base in 48 hours. And the other thing on that hand is like, we don't have those SLAs that the communications need to be so immediate. So you can also offer an alternative messaging method. So let's say this is happening in a PR, you might be able to send them a Slack message and offer some time to call because like Sandra was saying, tone doesn't always carry well. And you actually might need to see like hear each other's voice or possibly hop on a video call. And that might help to feedback come off a little bit differently. Also, like when that happens, I often just ignore that PR for two days and then they chill out. And it's time, time helps people cool off. I will say sometimes there is an issue with the fact that we are communicating globally. And sometimes it's through a layer of translation. And that layer of translation may be imperfect. We've definitely seen issues with that where we've had to go find like native Chinese speakers to tell us what's really being said on the PR because if I listened to what Google translate told me was being said, some really offensive things were flying, right? But that wasn't reality. That was a failure of the of a computer, right? So understanding that sometimes tone is really important and can be completely destroyed despite best efforts if there's any level of automated translation. I saw one early right here. So thanks. I guess on a similar note of the feedback sandwich thing, we in our not as a challenge, but we in our organization do a lot of like radical candor if you're familiar with that approach. And I was wondering if you had seen any success of any things within like sort of the radical radical candor thinking within the open source community. I think it can be effective. I think how do I phrase this? I've also seen people hide behind the usage of that term as a means to be unnecessarily direct and harsh. So I think when wielded appropriately, it can be a fantastic tool for direct kind communication. But I've also seen a fair amount of misappropriation of the term. Yeah, I will say this. So similar to Danielle, but also very differently. I am also incredibly autistic. So I am one of the most like direct humans you have ever met. The number of people that I have unwittingly offended by saying something that is completely true, but maybe not the way to say it is why I have personally gravitated towards these strategies. And I think as people get to know you, although the sandwich message could potentially come across as a little patronizing, as people get to know you and they see that this is a consistent way that you're communicating with everybody, not just with that one person that should come across to them as the fact that this is just your communication style and it is authentic. So you know, it's one of those things where if you say something really direct to me, if it's true, I'm like going to be like, Oh, okay. But you know, that's not everybody. And I've had to apologize and I will consistently apologize. I think that's the most important thing if I'm accidentally offensive, right? It's just consistently apologizing and owning that mistake. But yeah, you really have to be aware that your impact is more important than what your intent was. And that at the end of the day is what you have to really like make sure that you're going to have to have ownership of your impact, not of your intent. Hello. Thank you very much for your talk. It was very timely. I have one comment and two concerns that maybe you can give me some good advice on. My first comment would be that I'm also a bit getting tired of the sandwich technique. But I read a research paper, which says that actually the power of feedback lies in how much information you're conveying. And I think it's quite easy. Like you also said during the talk to just focus on the negative things of a PR or whatever. And I think that where the value of the sandwich techniques really comes is also to say what you like about the PR and what, because I mean, you bothered giving feedback on PR. So obviously you think this is worth something. And often that gets gets lost. So I think that people who don't feel that they're authentic enough with a sandwich technique at least bother saying also what you like about it before you go and destroy the poor PR. And that makes the sandwich technique a bit more authentic. And then I wanted to raise two points of concern or advice from you. The first one is that I review a lot of documentation and both as somebody who's receiving feedback, but also as somebody who is just passively looking at how other people are giving feedback, I'm a little bit more of the done today is better than perfect tomorrow kind of person. And especially when it comes to documentation, I mean, let's be very honest, it doesn't matter if there is a typo or it doesn't matter if the message doesn't quite come across. I mean, it's not code, right? It doesn't need to pass a unit test is not going to lead to production failures. I really would rather like people to write a bit crappier documentation and no documentation at all. Do you have any advice on this? Like how to synchronize a whole team on let's say expectations that were a quality level and, you know, also leaving a bit of slag in your feedback to not always get into that nitpicking, so to speak. So I have really big thoughts on this as somebody who has dyslexia. So as somebody with dyslexia, documentation is so important to me because I have to carefully read every letter of every word. The way a lot of people's brains will kind of automatically infer the word and therefore it doesn't really matter if there's a typo. Actually for me will completely jeopardize my entire understanding. So we do have to think about who the documentation is for and the fact that we're an extremely neuro diverse set of people, right? Like if I hear what you're saying, like it's just a small typo, like let's just let it go forward and we can fix it later. I definitely agree with that. But I think that we also have to keep in mind that like for me and I'm reading something and reading is already hard. I don't know why I'm a software engineer. That was a really dumb decision. But like reading is already hard and then I will have to go back and completely reread everything I've already read because a typo has ruined my understanding. So the perfect cannot be the enemy of the good. We say that a lot. We say it with code. So I do think I do think there's a balance there between between nitpicking and also appreciating the fact that you know somebody with dyslexia or somebody who's having to read it in a language that isn't theirs, like it's going to massively jeopardize their understanding of the documentation. So there's not like one perfect thing. I do agree with the 80 20 rule, but I do think that it's important to kind of have the perspective of not everybody's ability to understand is going to be equal. And then especially with open source and infrastructure stuff. I try to have empathy for the person who's reading this at 2 am after like just being woken up after like putting that kid to sleep. And so I'd rather the documentation exists so they don't have to go look at code after that. But I also want them to be able to read it. And so it's a like fine line thing that is worth like talking to other like docs reviewers about setting a standard for. So I think we have time for another question. Unfortunately, we were told to keep keep tight on time for this one, but we all will stick around. Please come and chat with us. We're happy to talk and thank you for the engagement and the attention.