 Hello, everybody. This is the second session of this room of the DevCon 2022. So welcome, everybody. And the next talk is Orohan by Issues. Let's have a party. It will be presented by Pep Tromari and Trosten Svesic. So welcome and the stage is yours. Thank you so much. Good morning, everybody. Thanks for joining Orohan by Issues. So let's first go with who we are. So it's Pep and me. We both work at Redhead. And we both started in this team we are in, which is the topic with Pep and operate first. It's on my side. If you're interested in this, join the session with Marcel Hildes this afternoon at 2pm. Some little announcement from our side. Sorry, less advertising for today. So we are both software engineers. And because we started last year, we had this problem looking into GitHub and being over-bent by Issues. Good morning, Pep. How are you? Good morning, everyone. Yes, we're here to try to have a party after the situation of Orohan by Issues. But that's what we will present in the next slide. Maybe we can get into what we are trying to convey today by having a party Orohan by Issues. Well, first let's define, you know, what's the problem? What does it mean to be overwhelmed by Issues? Here we would like to ask you, everyone, what do you understand by being overwhelmed by Issues? We have some ideas, but we also have a poll that you can see here where you have potential things that can feel overwhelmed when talking about Issues. And by Issues, we mean GitHub Issues, for example, whatever items that you use on your, whatever tracking system, in our case, GitHub, to track the work to be done. So, Thor, what is for you, what does it mean for you to be overwhelmed by Issues? I mean, for sure it's the amount of issues. If you open GitHub and you look on your issues you have, then maybe you have to scroll a few times and that's a lot. And the other thing is, how do I know what the issue is about, especially if you're starting a new team and maybe the technical issues are different or what you take care of is different, then you have no idea sometimes what the headline means. And if you look into the issue, then you sometimes don't know exactly where to start. Yeah, that's an aspect in my case, in my particular case. A key thing that I found when starting to look at the issues in the team was, you know, there are dozens and dozens of repos and it was hard for me to get the context and connect the dots between the different issues across the whole project. So the poll is ongoing. We proposed a few ideas, but if you have others, we would like to hear as well in the chat. And I'm seeing it. No, sorry, go ahead. Yeah, and I'm seeing that most votes so far are about missing information and this is a thing that we will focus a little later on the slide. Let's call it kind of a quality thing. Yeah. What our goals are, sorry, go ahead. So the goals for us here is for this presentation and hopefully you have something when you go out of it is number one, bring the fun back into handling issues. And fun means make it easy, get the team involved, let it be satisfying when you solve things and when you organize them. The non goals are for sure. Besides 42, which is the answer to everything, we will not be an out of the box answer for every team and for every project or for every development situation. So we will tell you what you should focus on and maybe find your own grid and clusters to organize your issues and optimize them for the problem and the project you have going on. What we expect you to take away from today's talk is we will share our experience so far this past few months since we joined the team and try well started to tackle this topic of, you know, making issue handling fun. And we will share the ideas that we had and how we started to implement them. So let's go then. We want this to be a party. Let's move to the next slide. And we will have this analogy of a real party. Just to keep in mind that in our context, having a party would be fixing everything like solving all the issues in a real world. The idea you have of a party is let's, let's get together and have a lot of fun by, you know, dancing, listening to music, having food and talking. But in order to have a proper party and have real fun, there are a few things that you need to take into account in the real world. Right. I mean, just jumping into the party and doing something can be fun. But if you don't know how to dance, for example, or if you don't know where to get the drinks, then there's a problem and maybe the music is not playing. So starting with a party means also planning the party. And this means as far planning ahead, like the invitation list, because it's important when you look at your issues, what actually is the audience you're talking with to the issues. Like if you have a team and this team is just for cleaning up some hot problems from the last days, then maybe you need a different look on the issues than if you're planning for the next three months. Or what we're going to have an epic running for the next year or something like this. And so you have to also figure out who does what who brings the music who brings the food, who does these things, which means organizing ahead. And then there's a party by themselves by itself and the party. This could be the fun part solving issues and bring them on the right track and making them better which would be the dancing thing. So what comes after the party, Pep? Well, you know, you need to clean up. You can see here in the picture the results of the party where you have food and drinks and all in the bed table. You need to organize like, well, clean up in the context of issue handling. You want to make sure that after issues have been solved, they reflect the real status that everything is understood, properly understood, properly documented. For example, if there is a need to follow up with something that there is another issue for this follow up, make sure that the priorities are clear for the next steps. The end goal here is that you, this is an ongoing thing. We want to have a party every day, right? So we want to be able to have fun fixing issues or working on issues day to day. So this requires, well, a few things that we will introduce like some ideas that we will introduce in this presentation. In particular, we have two main kind of topics or proposals to share during this presentation. The first one is in the next slide. Let me certainly make a stop here if I may. Sorry, because I see the words are still going on and missing information in detail. This exactly fits to the cleanup after the party because just solving the issues is maybe sometimes not enough for the people coming afterwards or for the next party. So putting details in your issues, that's one thing. Okay, so we go ahead and here we go with the quality. Yes. So yeah, two proposals. That's the first one. We are going to affirm that if all your issues have a good quality and by quality we mean a definition of how you want them to look good. What is quality? Well, good looking issues. If all your issues look good and have good quality, then this list of issues will not be overwhelming anymore. That's kind of a bold statement. But we will explain what makes that quality and hopefully with the rest of the context. It will become clear how this helps you have fun with the issues. What makes good quality for the issues? Well, there are a few ingredients. This is the list. Well, obviously starting from the bottom. An obvious thing is that they are properly written, an issue that qualifies the problem statement properly, etc. But there's more. You want to make sure that there are some labels that help you classify the issues. That's a bit of a spoiler of the next statement that we have. The idea, the list, you know, this list is a set of the tools that will help you achieve that goal. The main idea is that you look at the issues and you are happy looking at them. Look what a nice issue I have here. It's clear what needs to be done, when this can happen, what tools do I need to solve it, etc. One aspect. And you don't have to reinvent the wheel all the time. So we leaned our ideas to the Kubernetes contributors community. And the link is in the presentation. It's public presentations. You can look there. And so labels is a thing. So what labels mean, for example, here's from the MiniCube project. So a label could be what kind of issue you have. Like if it's a bug, it's a feature, if it's a cleanup thing or just a documentation. Or if you go into the next slide, then if you're developing for different operating systems, a label could be for what operating system you are coding this thing right now. And one thing which is mostly in all projects important, the priority of an issue. So here in this case, important long-term backlog, something like this. And some people use the priority as a life cycle that depends on the project you have. We just mentioned it here. Yeah, couple of final points about quality. One of them is that it depends on what moment in time you are and what you are wanting. So I'll give you a complete example. If you are going to fix, you know, right now want to see what box you need to fix. You might have some standards for quality at this point in time, but maybe you launch a service and those standards change. So things like the time to result might be bound to an SLO that you said. What I want to say is this quality or this set of standards is bound to, it's not fixed. It's bound to change over time. The other thing, the other aspect is also the audience of who is looking at the issues, you know, looking at an issue might make you happy, but some difference they call them might not be so happy. So it's important to define the quality that makes everyone happy. Right. And so we talked about overhead and sometimes the feeling producing stuff ahead or overhead makes things complicated or taking too long. But at the end, you can control what you can't measure. Me coming from the my last jobs were like in building dashboards for financial things. So control means not controlling of money necessarily, but control means being prepared. So here bolting with bears, one of my favorite authors from Tom DiMarco. If you know that the bear is heavy and steps on your foot, maybe you're wearing the right shoes. If coming back to the party, if you know that there could be a fire, you have a fire, the thing was prepared, which makes you enjoy the party and solving the problems more because if you have everything prepared and you measure things right. And you know what's coming up, then you can just focus on the issue because no, you know that everything else is taking care of because you organize ahead or afterwards. Yeah, it's not about, you know, imposing control. It's more about being able to relax and have fun. Right. Okay, with this we go to our second main proposal of the topic. So you are overwhelmed. You have an elephant here, a big elephant that you have to eat. How do you eat an elephant? Well, one bite at a time. And translating this into the world of solving issues. The idea is that you should apply proper filters to show you and clusters of issues. So filtering them in groups will help you eat that whole elephant one bite at a time. One point here is that we mentioned in the previous point about quality. How do you define quality? This will, you know, having quality issues will actually enable is a kind of a prerequisite for achieving this, being able to tailor the cluster of issues that you look at at any time. A classical example of this is how to distinguish, you know, urgent versus important issues. What is urgent? What is important? Let's not the urgent prevent you from doing the important stuff. Right. But how do you define what's urgent? It depends. That's what you define when you define your criteria and the quality of the issues. Right. And so these two statements we have here, the one about the quality earlier and this one about the cluster is taking care of number one, the quality that you know what's going on in the issues. And the second one, if you don't have too much of the pure amount and by clustering issues, you can kind of reduce the amount of issues that you're taking care of at this particular time or place that you are in your project. Cool. Well, one thing that we have found when implementing this is that preparation is key. In the end, the last point here is you need a clean starting point and basically you cannot start to have the party back to the steps about how to have a fun party you need to prepare. Right. And that's very key in the in the world of issues as well. You need to know who the audience who is going to look at the issues, for example, and in which context, this is the audience and goal thing. Are we now going to look at which what work should be done over the next screen over the next quarter, or are we looking at what do I have to do today. Right. Different requirements like those imply different views and different. So it's important to know what what you're trying to to see. And, well, there are tools to to to help you achieve each of those goals. In particular here we are going to talk about to one. Again, we we are taking inspiration off the Kubernetes ecosystem and how they do things. One of the tools is triage party that actually inspired the name of this talk. And it helps with the well as the name says triaging more on the day to day or what we call the bottom up approach we will clarify in a bit. And the other tool that we use as well we we have all the issues we in in GitHub issues and we use GitHub projects to help the top down approach here. So and if you got no some other tools because we're always looking and improving our ideas. Feel free to put them in the chat and we would love to share them with the community afterwards. Let's go a little bit more into details now how a party I mean the tool triage party would look like. Why did we choose triage party I mean GitHub comes to the law of nice features and get love does to and get project that everything going on. But one of the main things we figured out is creating filters for maybe specific problems to find the right issues was not helping. So triage party has like an amazing set of filters you can use regular expressions and even more. And so that's why we at some point decided to try triage party. You can easily fork it from the GitHub triage party Google area. We started locally and then deployed it on on our operate first system. We use the powerful filters to create a different cluster. I mean we talked about audience and time in your project. So you create filters and you can create collection of filters to design different kind of dashboards in your browser because it's a web tool in this case. And it gets also the fun part we talked about because there's a party mode you can invite like an amount of people from your team. And this tool automatically splits the open issues up to these to all of your team members and you can solve them together. And at the end you come together and find things that are not solved yet or maybe not labeled or not the right qualities in them. Some things you can't do it's no direct edit mode for issues. So you have to always go into the YAML file to do this. And there's no bulk edit. Always if you click on an issue it goes directly to GitHub yet. You want to add something? No just to summarize it's a very nice front end to help you show not edit as you said but it will help you achieve that clustering of issues and showing you views that help you, you know, eat the elephant one bite at the time. We have examples here but we're running a bit late. I don't know if we want to. No, no, no, I think we can skip that we had the example of configurations but yeah kind of emphasize that it's just to summarize it's trash party allows you to filter on more sophisticated ways than GitHub. That's that's the message and that will let you achieve that classification. But yeah, let's move on. And the shared principle. We thought first of doing a live demo but realized takes too much time so in the presentation presentation which is shared at the end you see some screenshots from the definitions and different rules. Yeah, and again, sorry we can run a live demo here but we have this screen a couple of screenshots of our we have two deployments of of trash party for each of our teams. This is towards initial view of trash party highlight here. I don't know if you want to talk that's your. Yeah, I mean it's you see this is an example you see if you this is not really clustered and really label because we have the top down approach on our team. And this is an a bad example how you see because it says check daily and they are 341 issues on this cluster view. So the generic template from triage party is here not working for our team. So there needs to be some customization. And then we go again in the other hand that's that's that's our trash party which no no yeah you were showing that looks more manageable. This is again the initial view what what the tool showed us initially. It's a fewer number of cases resulting of our team have been using more labels but on the other hand, that doesn't mean it's not overwhelming as we mentioned at the beginning there are multiple criteria that can result on overwhelming issues and in this case it was quite hard, even if the number was slow, quite hard to actually through ice them because missing context, let's say this case. Okay, so our experience so far. We didn't come to a final solution yet because we want to have make it fun and until it's not fun for us. It's a work in progress we will not present it or force it onto the team. So we are still in sharpening the song, which means we need some fine tuning as you saw. So different approaches of the team top down and bottom up pepper mentioned this in the next two panels here. And I said is not we're not having fun we don't push it to the team. So, you would like to go to top down and bottom up. Bottom up meaning the triage refining approach where basically triage party the tool shines looking at individual issues and then, you know, looking at them individually that helps you do the things right. So it helps you with making sure that each issue has good quality for example, but it doesn't help you connect the dots and get that context this is kind of where the top down approach comes handy. Which is looking at the things at a global level like look at those start from those issues that I mentioned that are tracking work for the next few months. And then dive dive under. So I think we can move to the next and final slide because this this correlates. Well, we believe one of the recommendations we we have for you is we believe we you need both approaches both top down and bottom up. And they are quite different, but they complement each other you cannot do just triaging like individual issues you need that high level view, but the high level view by itself is not alone you need good quality individual issues right that's one of the recommendations for more you want to cover the others. No, I think it's kind of a summary. Sorry. Yeah, so in the general, define your quality know ahead what you want to go what is your audience. Use the filters from triage party to, yeah, sort to think a little better and cluster them which makes it easier. And think about the purpose for all the tabs you're creating on triage party and then do both things top down and bottom up plan ahead and work and have fun with the issues. Yeah, and we hope that this will allow you to have fun working on those issues. The two things. The questions are pretty short because we are running out of time we know this we are in this adventure work adventure area later on if you want to talk to us here's our contact details feel free. And the slides, there's some attachment at the slides where you find links to all our things we talked about to our triage party deployments, and also a little checklist how you can maybe make more fun of your triaging your issues. Thank you. Have fun. Great. Thank you very much for your great presentation. So everybody feel free to go to the organization here and see you in the next talk. Thank you very much again. Thank you. Thank you.