 It's time. Yeah, I think so. Yeah, so thank you for coming. Today, I'm going to try to summarize in 20 minutes one year in QA, LibreOffice QA. When I thought about this presentation, I thought about a couple of things I could talk about. But in this presentation, I'm going to focus on Baxila, which is the backtracker we use and basically the main tool we use in QA. So, about me, I'm the QA engineer at the Document Foundation since September 2016. I'm based in Valencia, Spain, and that's my email and my nickname in IRC or Telegram. So, in this talk, I'm going to focus on three main topics. The first one is new reports we got in Baxila during this year. Then, second topic, tickets triage during this time. It doesn't mean those tickets were reported during this year, but it probably, sometimes they were reported before, but they were triaged within this year. And then, also, I'm going to talk about those tickets closed during the last year. So, the frame of time I cover, it's from LASA FOSDEM, a couple of days before. So, it's from February 1st and then up to this week on Thursday. I based this talk on a couple of blog posts I did in the past during this year, where I talk and I share some statistics in Baxila. And I also did a similar talk in the LibreOffice conference in Rome. But in this one, I'm also adding some more information I didn't use in this blog post or this talk in the past. And in order to get the data, I use an script. It's here, you can use it or even improve it. And, yeah, I just add the script to gather all the data. And, well, this is the general view. This is from today. I took the screens of today. This is Baxila, LibreOffice Baxila right now. We have 56,000, almost 57,000 bugs reported in general. So, it's difficult to kind of summarize Baxila one year in a presentation. So, I'm going to use a lot of charts, a lot of pipe charts. Maybe it's not the best one, but I don't really know how to sometimes present this kind of information. So, I hope you kind of understand it. So, first I'm going to talk about the new reported tickets. Well, we have to do two categories in the reported tickets. On the one hand, we have the bugs. And on the other one, we have the enhancements. So, in general, during this year, a little more than 7,000 tickets were reported in Baxila. And from those, well, almost 1,000 were enhancements and the rest were bugs. And it was done by 2,800 people. And here you have the top 10 users or people reporting tickets. And we have the list of the first one who has reported 355 and then J. So, yeah. This is how many reports we get every week. And the red one, those are the bugs. And in here, those are the enhancements. And as we can see, most of the time, the enhancements are, every week, they are similar. We have the similar number of reports. But then, talking about bugs, well, it depends on the week. We have, like, release a new version, but I match the releases and it's not the case. So far, I couldn't find any reason why we got more reports this week. Sorry? Yeah. And, yeah, in total, we get around 135 reports. And from those, around 117 are bug reports in average. And this is the same chart, but split by month. So, we got in average around 600 new reports every month. And from those, around 80 are enhancements. Yeah, then, about the current status of those reports we got during this year, we see that if we look at the general picture here, we see that right now 33% of those are still open. But then, if we split the chart between enhancements and bugs, we see that 66% of the enhancements are still new, while 30% of the bugs are still new. So, it's important to differentiate between enhancements, which most of the times are nice to have features, and bugs, which is, from my point of view, things that we have to focus more, although enhancements are important as well. And here we see the components we get for each report. So, right there, in both cases, is the component we get more reports for. But then, talking about enhancements, we see that the second one is about LibreOffice in general, while here the second one is Calc. And then we also see here that Android, we get like 8% while in here we don't get much, which is kind of expected because Android is under development now, so people just want to have more features there. But probably that also means that we should, at some point, focus more on Android enhancements because people are asking for that. No, that's everything. Yeah, it's not there. Yeah, maybe it's. Okay, so yeah, then it's only LibreOffice, the product. Yeah, probably, yeah. And then this is about the version of those reports. This is not really accurate because if someone reports a bug saying it's happening in the sixth branch in the release this week, it doesn't mean this bug is coming from that version. Maybe that bug was there from the beginning. But yeah, we see that during this year, which is kind of expected, most of the bugs were reported against version 5 or the branch, the interior branch. But it's also significant that we are still getting some inherit from OpenOffice or even LibreOffice 3 bugs. Then, about those tickets triage during this year. Oh, okay. So it should fit here. Well, here we see the number of unconfirmed bugs per week. So we see that the number of unconfirmed is kind of flat. But then at some point we have some peaks where the number of unconfirmed bugs are going up. And I think at this point we had the LibreOffice conference, so no one was triaging bugs. So that's the reason we have more unconfirmed bugs there. Ideally, we should have this to zero or at least try to because then the less we have, the faster we can triage bugs. But yeah, right now, like last year it was around 476 and right now it's about 410. So we are kind of going that way, although it's going to its long process. And here where we see when a bug is confirmed it means it goes from unconfirmed to something else. So it might be need info or need or resolve duplicate. So it's every status different than unconfirmed. So during this time 5600 tickets were confirmed from those around 800 enhancements and the rest were bugs. And this triaging was done by 240 people. Here we see the top 10. And right now this is the status of those triage bugs or triage tickets. We see that if we look at the whole picture we see that 45% are still new, but then if we split it then we see that 71% of the enhancements are still new while the bugs 40% are new. It doesn't mean because we are counting like even bugs reported last week or last month. So it's really difficult to get a bug fixed reported this week and fixed within a week. So that's the reason we have the number of bugs in new status at 40%. So probably if we could take another range, if we took another range of frame of time like last year probably the number would be less. And here in this chart I'm measuring the timing in order to triage those bugs. So we see that in 52% of the tickets they are triaging one day and then within a month we have like 80% of the tickets triage. And then well there are always some tickets which take longer or there is no way to reproduce them. So we have like less than 1% which are more than 3 years in unconfirmed status. But then yeah it's important to know that within a month we cover like 80%, 85% of the bugs. And then again the version well kind of expected that most of the triage bugs are in LibreOffice 5. Probably if we do the same next year it's going to be LibreOffice 6 but we also have 15% of the bugs already in LibreOffice 6. And then an important part of the triaging is also tagging the bugs. And well an important one I wanted to remark is tagging bugs are regression. So we have during this time around 1,000 bugs were tagged as regression by 78 people. And this is the chart over the time. We see that the open regressions is kind of flat although it's slightly going up. But then the number of total regressions in Baxila is growing faster. But the one we have to care about this one so far it's flat. Ideally it should go down but as long as it's going faster like this it's good. And then well another important task in triaging bugs is to bisect them. So we have around this time we have around 650 bugs tagged as bisect. It was all my 20 people and it's kind of the same. We see that the number of bisected bugs, the open ones are kind of flat and then the number of bisected in general is growing faster. And yeah we have another this keyword it's also important to when the application is crashing or when there is a hand in the application. So it was done on 258 bugs and sorry that's a mistake there. And it was done by 15 people and then here we see that the status of this bug. So when a bug is tagged as regression 36% of them are still new. But then if the bug is bisected around 30% are new and then if we add the half bug trace well if we have a bug trace then it's even lower. It means that the more we can provide to the developers the well it's going to reduce the number of open bugs. And here is the time comparison so we see that within a month the tag regression tag is at for 85% of the cases and the same for bisected and half bug trace. And well this is the version of this of each keyword and now well I'm going to talk about the close tickets. So in general close tickets are those who are moved to resolve verify of close or close and here is the top 10. People doing that and well we have around 536 people who has done that and well so we see that if we focus on bugs we see that 22% of them were resolved as fixed. 22% were resolved as duplicated and then insufficient data which means the bug was moved to need info then we didn't have any feedback from the user. So in the end we close it as insufficient data and here I don't see like 20% it's work for me which means the bug was reported at some point and then the user tried it again with a new version and then it was fixed. So this is the chart for the bugs close every week and we see some peaks here that's because that week we move all these need info bugs to insufficient data so that's the reason we have those peaks there and this is every month. And well if we focus on those which are fixed then we see that 1866 were moved to resolve fix here we have the top 10 and it was done by 152 people. And if we focus on those which are duplicated it was done by 125 and here is the top 5 so we here see a profile which is developer and in here we see QA people. And the time comparison we see that well no so so let's focus on resolve fix we see that in 9% of the cases they are close within a day and then around 40% of the cases they are close within a month. And yeah within a year it's around 70% of the cases and on the other hand we have the resolve duplicated which normally are close as duplicated within the first day. And then around 60% of the cases or 7565 are close within a month. Sorry but yeah I didn't know like how to process all this information but maybe it was too much for you.