 Hello and welcome to my talk how to win an argument with a maintainer. Now about me my name is David Edmondson. I've been a KD hacker for over 10 years. I currently work for Blue Systems and I'm a maintainer for a lot of projects and I spent a lot of time committing patches to other parts of KDE and even other projects. So why am I giving this talk? Well somebody asked me at the end of QTS. It's very question and I spent the next 10 months thinking about this and trying to come up with some useful tidbits that might help other people. So what do you want to avoid? Everyone probably knows that situation where someone's pushing for something and maintainers pushing back. You're not really going anywhere. The argument is just go on and on and they'll drain a lot of energy. I know somebody in KDE who bragged about their ability to just keep pushing and pushing until your maintainer back down but that's not really winning an argument. That's just being better at bullying. So this is a situation we want to avoid and there are several steps and patterns that I see in other people do and things that I know I want to receive as a maintainer which can help avoid ever getting in this situation. So your winning move is to try and avoid that headbutting situation because once you win this massive argument it's very hard to get out of. So what are some steps that we can do to approach this in a way that ends up being better for everybody? And one of the most important opening steps is to make sure you focus on a problem not a individual specific solution and this is for multiple reasons. Firstly as a maintainer if I see a patch or somebody wanting to change something in a bug report the first question I'm going to be asking is why what problem is it trying to ultimately solve? Because that's the main job as a maintainer and if you approach explaining of why the why aspect it reduces a layer of communication difficulty that you're going to have to get through anyway. Also if you're coming to try and change a project it's a lot easier to try and convince a maintainer that a problem exists and we need to find a solution than to try and to convince him both at the same time a problem exists and that this is a specific solution that solves it. It reduces your problem in half when you're approaching a project. Another thing I found is that if you can convince somebody to reach a conclusion themselves everyone's a lot happier for that and this is something we used to see a lot with the old VDG old UX group with Thomas Fife and Co is they wouldn't push for a change it would just keep asking questions until you reach that same conclusion that they were possibly hinting at. And that makes Abram a lot happier you're not telling somebody what to do you're setting up a problem and helping them maybe find that same solution. But it also sets a tone for compromise if you come in saying this is your one solution and I'm not willing to talk about others and discuss others and it doesn't show you're willing to compromise and if you expect a maintainer to change their position it's important that you also come across as being willing to change your position as well and reach some kind of compromise. Last but not least if you come at explaining what the real problem is what the end goal that we're trying to solve. If you work together brainstorming every possible solution looking at different avenues and the maintainer typically has a lot more experience in knowledge of what's available and what what the problems are what we what's been tried before you might find you actually reach a better solution than the initial one that you had and you came proposing. Another common mistake that I've seen happen at the beginning of conversations is a lot of focus on why a specific decision five years ago ten years ago was wrong. And this is a complete waste of energy if you try and argue why something was wrong people are naturally going to defend it they're going to explain why I made that specific decision and suddenly you're in an argument and the one thing you want to do is not try and phrase the argument as a winner and a loser but as compromise and ultimately unless you have a time machine it doesn't really matter you can't go back and change that decision and if you do have a time machine it's probably better things you should be doing. So instead the best thing to focus on is why should a decision that's been made five years ago be revisited and this really helps if you can point to one or more specific changes that should retrigger discussion again. This could be an external technology that didn't exist when a previous decision was made it could be a general trend of user of things in the field something specific you can point to and say well now this thing has happened therefore we should revisit this. Moving on from some of the initial problems is something you can do when you start to see tension in an argument and this can help it applies really well just on code of use as well as bugzilla and in real life in general. And one thing that I've seen to work and I try and do myself is to prove that you're on the same page. So one thing I like to do when you see it as a starting to get some tensions at the start of an argument is to rephrase the other person's counter argument in your own words. So something like so what you're saying is blah blah blah. Ideally in a really concise way because generally if somebody writes paragraphs and paragraphs they don't really understand anything. If someone can explain a complicated problem very simply they're normally a smart person it takes a smart person to do that. So this is important because it resolves misunderstandings very early. One thing I've seen is if you go into an argument and you misunderstood a technical a very small technical thing at the beginning of the discussion you can waste lots of hours, waste a lot, create a big argument and you're never going to get anywhere if you're not on the same page to begin with. It also proves to the other person that you're listening. People don't like to not be listened to. So if you prove it you've read your arguments you've understood their arguments but you still disagree. It changes the scope of the conversation completely. Suddenly you're a smart person who happened to disagree not just a general pleb. But also it concentrates the discussion into more precise concrete points. Sometimes people ramble for ages and ages and ages without really saying anything useful and as you can distill that into a couple of key sentences of this is the problem this is what we need to fix. That can have a really big impact on the rest of the conversation and I've learned from my googling this is called tactical empathy and there's lots of resources about that and why it's generally a good thing. So somebody told me when I encode reviews I always typically respond with questions rather than statements and this is because I'm trying to understand the situation and that really helps. It's not creating a conflict is asking a question which is helping members of it. Another suggestion that really helps is having some sort of big overall picture of what you're trying to change. If somebody comes to me with a patch on my project that turns a background purple I'm going to reject it saying this is just random I don't know what you're doing. But if someone comes to me saying well I have this task I've got this overall idea of changing a palette this is the way I'm going to do it. That's a lot easier to accept. It seems that somebody has this overall goal I can understand what their main goal is it's a lot easier to accept. The counter argument is if you're submitting a patch for another project it's to make sure you do it in small incremental chunks. Don't do this massive world refactoring change all at once because that's going to be makes life a lot harder for you. If you can break it down into this is my end goal here's my first chunk to get us there that's generally well received. Another thing to make him really helps is to make him most of meetings be it virtual be it just an ISC and make use of other people as well as actual conversations things on fabricator can get really convoluted really quickly if you bring in other people if you get into a real chat these can help so I don't know how this works here but if there are any questions just ping me I guess