 So, yeah, my name is Chiusco Fauli. I work for TDF, I partly work for TDF part-time. Been in TDF for the last three years, and I do mostly QA. It's going to be a short talk, because when I submitted it, I did it as a lighting talk, but then they gave me half an hour. So, yeah, I don't have enough things to say, so, yeah. Well, yeah, so I want to talk about how we try to prioritize bugs in Baxila, and in LibreOffice project. And the reason I want to talk about it is because in Baxila, well, in our backtracker, this is a screenshot I took the other day. So you can put in content how many bugs we deal with every day. So right now, we have 72,000 bugs. And well, right now, some are still unconfirmed. There needs to be 3,000, 13,000 are new, and then 50 more than 50,000 are resolved. So I've used this screenshot before in other presentations. And then when I was working on this presentation, I thought, OK, let's compare it with previous one. So this one is from September 2018. Obviously, the numbers, the total numbers were less. But what surprised me was that, well, comparing, let's say, one year and a half more or less ago and now, we see that the number of new bugs has increased only by 6%. But then it's interesting to see that, well, the number of resolved bugs increased by 16%, and then the verified 68%, and then the total 16%, which is in line with the number of resolved bugs. So it was interesting to me to see how the new bugs are not increasing that much. But yeah, back to the topic of prioritizing bugs. There's a wait. I think this is not the, sorry. I'm using the, sorry. I think I'm using the wrong, sorry for that. Oh yeah. Sorry, I was using the wrong file. So in Baxilla, we have these five categories of or levels of priorities in bugs. So HighGest or P0 could be crash, loss, data, inability to install. And what is important to me is that, well, it affects all or nearly all users and documents. Therefore, we also have high priority category. And it's not as important as HighGest, but then with serious problems and with open certain documents and then tedious, slow, and affects many users. And then we also have these three categories. Normally when a bug is reported, in general, it just goes to medium. And then in a few cases, it just goes to low or low-west. So this is from our wiki page. And this is the usual flow. When someone, it's a triage in a bug, normally we try to follow this. So I don't know if you can read it, but let's say you are triaging a bug. First thing you have to ask yourself is, it's a crash. It's losing data, inability to install. Then if it's yes, then you should ask these questions. Like, I can read it. Wait, I can do it. Yeah, so basically, you can ask yourself, does this bug happen very frequently? Does this bug involve major components? Or does this bug affect components that affect many users? So basically, this is the way the video is not working, seems. I don't know, but people on the internet say that it's not. Maybe it's recording, but not broadcasting. I don't know about that, but it says recording there. It's flashing, and that's on your screen, isn't it? I think it's all right. I don't know about broadcasting, but I don't. It's Boston Box, as the flashing red recording light. I think it's fine. OK. People say so. Yeah, so this is basically the workflow we have been using in QA, since the project started. So then I wanted to analyze how the progress of high-guess priority issues went in the last years. So this is from the last five years. And then back in the time, it was around 80 high-guess priority issues in Baxila. So then we found out that people, normal users, they were increasing the priority of those bugs. And then we had really high number of priority bugs. So at this point, we decided to create a contributory group. And then we see that from there, the number of high-guess ability bugs went down. So at this time, right now, it's around 20. So the trend is going well. So it should be, ideally, it should be zero. But at least the trend shows that it's going down. So sometimes when we are triaging bugs, it's easy to find that it's a crash or it's data loss. But we don't really know, or we didn't know, how many users were affected by this bug. So here we have an example. In the ESC meeting, ESC meeting, it's a meeting we do weekly. Developers, UX, QA documentation. Everyone in the project is participating in this meeting. So we have a section for QA. And then we just say, OK, these are the most pressing bugs or high-guess priority bugs. So sometimes we found, for instance, this issue here which at first glance doesn't look like a crash or it doesn't look like data loss or it's not affected installation. But then we found that many users were affected by this issue. So if I open it in Baxila, I see that we have many people in CC which means they are kind of interested in the issue. And actually we had many duplicates for this issue. So that means that we got many reports in Baxila complaining about this issue. This was for 6.3, released half a year ago. So yeah, as I said, when you look at this bug, you think it's not at first glance, you think it's not a high-guess priority bug or high-guess priority bug. But then considering the number of duplicates and the number of people in CC, yeah, we decided to put it in as high-guess priority bug. So recently we are also using this, apart from the flow chart that I showed you before, we are also using these kind of rules. So basically we can have two kinds of issues or two kinds of tickets in Baxila. Either they are bugs or they are enhancements. So if we check if it's a bug, then we see if there are more than 20 people in the CC list or we have more than five duplicates. And then if it's a regression that we say, OK, this is a high-guess priority bug. And if it's not a regression, then we say it's a high-guess priority bug. And then for enhancements, we say that if there are more than 20 people in CC or more than five duplicates, then it's a high-guess priority enhancement. When I was doing, well, I started to use these rules recently. And then I found that many enhancements were put to high-guest. And yeah, in my opinion, it doesn't make sense because yeah, it's true that an enhancement can be reported many times. And yeah, many people or users would like to have it, but it doesn't mean it's really urgent to be fixed. That's why it doesn't make sense to have a high-guess priority enhancement. So after doing this cleanup, we found that, well, we were around 16. And then we found some old bugs that weren't tack as high-guess priority bugs. So now they are kind of more important. And they have more priority to be fixed in the list of issues. And then in the EC meeting, we started to track the high-priority issues as well. So now every week we see which issues are turned into high-priority bug as well. So yeah, this way what we can do, what we see is that we are having the same trend with high-priority bugs or high-priority bugs. So then in five years ago, it went up to 600. Now it's going, at this point, it was around 460. Then here is when I did this old cleanup. And now it's around 400. So yeah, the trend is showing that we are going in the right direction. There's still a long way to go. But yeah, it seems that we are getting there. It's a long process. So this is from last two months, more or less. So we see that here, when we did this cleanup, it went from 460 to 380. And now it's around 400. And now this is the current status. High-guest priority bugs, it's 22. And high-priority bugs, 398. And yeah, we have also this wiki page, which might be interesting to track these kind of issues. So we have a page in Baxila for stats. And here we can see, for instance, the list of regressions by number of people in CC. And here the list of regressions by number of duplicates. So for instance, we see that right now, the open regression, which is interesting or it's affecting more people based on number of people in CC, is the fonts getting blurred in macOS. And then same for number of duplicates. We have the same problem, macOS both regarding fonts. Those are right now the most based on what users report and what users are interested in. Right now these are the two most pressing bugs that should be fixed as soon as possible. Problem is that it's not that trivial or no one. It's really interesting to fix it. So I hope that TDF contenders these problems to be fixed this year. So that's my hope and I'm putting some pressure there. And yeah, that's basically it. So thank you. And do you have any question? You mean number of visits and I've never used it. So I have no idea. Maybe if we don't have it, we can integrate it and then have more input in there. But I don't know. What's the answer to the question if we have it? If you don't know. Yeah, to see what people look for and OK. So TDF per se doesn't have developers or paid developers. So we are based on contributors or affiliated companies, CIB, Colabora or others or needs from Hungarian government and others. So basically the way it works in my experience is that if an issue or a bug, it's a regression, then we normally bisect this regression. We find the commit where the regression was introduced and then QA. Like I do that and QA team do that. So if we have a regression and we have a commit showing where the problem got introduced, then we kindly ask the developer to fix it. And in most of the cases, they fix it. So once we have that commit, then everything gets speeded up and gets fixed quite soon. If the issue is not fixed or it's, let's say, longstanding issue that no one is really taking care of, then for this kind of issues like this Mac problem we have with fonts, the problem here is that it's not a regression in LibreOffice, but it's a regression in Xcode that where now the rendering is different. So we have to, let's say, change the code to work properly with this version of this code. So in that case, well, if no one is fixing that, we should find other alternative. And right now, one alternative is to propose TDF to tender that fix or find someone to fix it. So that's it. OK, thank you. Thank you.