 All right, so we're at the time, so I will get started really quickly and jump in. So my name is Robinson Tryon. I'm a Q engineer with the Document Foundation, and I dabble in other things, proofreading stuff in English, because people think I'm good at it for some reason, release engineering and a bunch of other stuff. But I also volunteer and do a number of things, promoting the broadcast use in the United States. I'm big about document freedom day. In fact, I brought some stickers from our last document freedom day to bribe all of you with. So even if the content on my talk isn't to your liking, I have stickers to bribe you. And because everyone always asks, I used to live there and I live here now. And I'm not actually a cowboy, but for some reason we talk about wrangling bugs. So there's that. So my talk today is about bug tracking, about bugzilla. And I wanted to give you, some of you are rather technical, some of you aren't, but hopefully there'll be something in here that all of you will find interesting about how we use bugzilla with QA and what we're doing to make it easier for people to contribute to our tooling, which of course then is a sort of side effect or knock on effect in terms of helping out LibreOffice itself. So bugzilla, so the first LibreOffice bug that I could track down, it was filed a little bit before actually the creation of LibreOffice by about a month. So this is this crash in office suite and this is actually sort of maybe classified as a predecessor, GOOO, which is one of the predecessors or parents to the LibreOffice project. So these are our humble beginnings of where we began with QA and with bug tracking. When we started out as a project, LibreOffice, we had basically no infrastructure, at least I'm sure someone's going to raise their hand and tell me about that, but yeah, we really benefited from free desktop.org who gave us mailing lists, source code repositories, wiki space and a bug tracker, which was very helpful at the time to have someone else deal with those things so that everything else that needed to be addressed could be addressed in terms of dealing with a new project. So free desktop still exists, the bug tracker still exists, it's very stable and it continues along. There are several issues and some reasons why we decided then to migrate away from free desktop and to explore our new opportunities, new things we could do. So we have many other projects that we shared, this instance of bugzilla at free desktop. There are about 130 projects, there are just a few of them and the list goes on forever. You probably recognize many of these, probably don't recognize some of the other ones, but free desktop provides an amazing service, but there were some limitations that we had. So for example, we had just one little slice. So we had LibreOffice, we had one project out of 130 and we included a lot of content all lumped into what was, I think the terminology is products, but basically one slot underneath bugzilla. And this limited us a lot, it meant that we couldn't expand and accurately track what we were doing. Everything including our infrastructure, some continuous integration infrastructure, two other products that we had an impressed remote, which some of you might have seen. I don't think Michael used one, but he used one in the past with a little Android remote for controlling presentations. And then our Android viewer, we're all lumped in with bugs inside LibreOffice itself. So this complicated things when you're trying to figure out all kinds of information including statistics. Also we didn't have our own administrators in there, we couldn't delegate, user management couldn't delegate roles, so this is, you know, got to be a little bit of a headache. Limitations on values and it was difficult just to concentrate on our document foundation bugs. So we developed a special front end actually, a separate piece of software to make it easy for people to report bugs into LibreOffice. And we faced some other hurdles in terms of changing the tooling and some of our goals to make it easy for people to report bugs inside LibreOffice and pass long information such as version information, component that you're testing and so forth. We also got very large, we were a big project obviously when people talk about free software and the free software environment, LibreOffice is say made at the top of the list, but it's up there. In fact, it's great going to conferences where people are so excited to see us and they're excited that we're being used, but of course because we're very popular and because we have so many users, we do see a giant number of bugs. In fact, in the last few years, we were almost two thirds of the resources of the free desktop bug tracker. So it was very clear that we needed to move along and have our own bugzilla, our own instance where we could track bugs. So we migrated. It took place this year, it gave us flexibility, allowed us to add as many admins as we wanted. So if anyone out there wants to help us administrate bugzilla, we're always looking for new blood. We will delegate you responsibilities, of course, and we can do things. So for example, when we were trying to release new versions of LibreOffice, sometimes we had to track down one of a short list of people who could say add a new version to the bug tracker or it could make little tweaks. And now it's great. So we can actually accurately connect the users that need privileges with those who have them. It's marvelous. It also means that statistics. So here, for example, you can see statistics about just TDF projects. So before, again, we were buried in 130 different projects. Now it's just LibreOffice and related projects. And in the future, we're going to narrow that down even further, provide specific statistics. So things we've improved. So I mentioned, and I know I'm sort of going to a breakneck pace, but I think I have a bunch of slides and a short period of time. So I'm going to hurry on through, wave your hand if you like me to explain something a little more in depth. But we are now able to use a built-in capability of Bugzilla. So Bugzilla forms. Yes, core. Not as loud? Not as fast? No, no. But it's slower. Slower. OK. OK. OK. OK. If you have time. Yeah. Well, OK. Well, I'll go a little slower and then I'll jump through. Yeah. OK. OK. That's fair. That's fair. That's fair. So yes, so we now have an interface, these Bugzilla-guided forms, that replaces our old Bugzilla submission assistant. So that was something that we tapped on to Bugzilla because we didn't have direct control. So now that we have direct control, we can use what's baked into Bugzilla and can make it easier. So you can see there's some helpful hints here. This should not have the exact version. So this is the precise version that you're running. And what's great is that now we have integration with LibreOffice so that if you are running a testing version of LibreOffice, for example, you don't have to be very careful about copying that version in to report a bug. You can just go into the menu and click Give Feedback, I believe it is, and that information will be pasted into your bug report. So this is very helpful for us. And in fact, one of my goals in the future is to include more information so that it's sort of a bulletproof method for users to interact with us. We fixed a lot of different things. I'm not going to go through all of them. But we've been clear about licensing, making sure that people are cognizant, that for example, if they're attaching information, if they're attaching a document, that we're going to use that for testing. But other people could also read it. So please do not attach your invoices, your bank statements, your resumes. That was something someone didn't want to have. There are lots of different things that people have attached publicly that maybe seems absurd, but we still get removal requests, even though we have these red messages. We will continue to try to improve that. We also are doing, I think, some neat things about state. So for example, in the past, when someone said, here's a request, here's a bug I have, and we wanted to ask them for more information, we would put the bug into a particular state, so the need info state, and then we would write them a message. Now this, as you can imagine, took a lot of time, because we took the time to write the message and put it into state, multiplied by not every bug, but many bugs. So what's great is that one of the first things we did, actually, one of the first things that we modified, was to make an automatic, so there's an automatic message that appears when your bug is in need info state that says, we're waiting on you. And this is, I think, very helpful, sort of optimizing one of the most common cases. We also made it very prominent that you probably want to file a bug about Libre Office or about the Impress Remote. The other projects are there, but you can file, but those, of course, are the most prominent ones. I don't want to read that upper part as a better app, and ignore it. Ah, that's bad. You know, there's no search for Libre Office. Well, there you go. You can just control that if it's fine, you know. We'll put some arrows, maybe, and it's like, yeah. Don't know. We've made a number of other changes as well. So we've tried to customize the error information to make it abundantly clear. So for example, if you're trying to change the fields to some value you shouldn't or you're not allowed to, we'll be very specific about that, especially because for many people, English is not their first language. So being as clear as we can, I think is very helpful. So in terms of modifying bugzilla in terms of contributing, there are many different ways to do so. One way is to modify extensions. So we have a few extensions installed. We have a weekly bug summary, for example, we use every week for bug summary. And it's a crazy idea. But we use this to collect some information, some statistics. And this is actually one place where it would be great to get more statistics. It would be great to modify this extension, make it into a more customizable tool. So in terms of bringing more people in, this would be a great place to see more development if someone's looking for a project. Right now, we're actually modifying the core of bugzilla a lot. Basically, we have a lot of TDF, a lot of our project-specific modifications. But we do, of course, want to share our modifications with others, and extensions are one of the best ways to do that. So yes, basically just a little more information about how you can learn and how you can get started. So very quickly, for those of you out there who don't install bugzilla every week, which is probably much to you, we are using a version of bugzilla 4.4. If you want to grab a presentation afterwards, there's a hyperlink to documentation about how you can install it. We've done several things, perhaps because we like to do things our own way, to modify those installation instructions. So we use a different web server, we use a different database. We deploy a bugzilla with automation tools for our own convenience, and we store a lot of our data inside Git, inside a version control repository. The reason there being so that we can share a lot of information and keep track of who's modifying what. This might be a little more complicated, but it does make things easier for us. So one of the things that I'm hoping to do in the future is to simplify the installation process. We have some easy collaboration tools, but right now I am drafting documentation, improving documentation, that will cover all aspects of these contributions. So whether it's installation, basic development, there's a lot of information about bugzilla in general online, but I, of course, want to make this specific to our bugzilla because of our tweaks. So one of the challenges that we currently face is the fact that we're using a legacy database, a legacy version of bugzilla, we're using a modern version of bugzilla that has been upgraded all the way since 2003. So I believe there are some modifications and pieces of the database that may have followed us through all these upgrades since 2003, and as a result, we have a very large database that has some unique and sort of crafty and interesting things. As a result, when we're testing and when I would like to give people a database to test locally so that if they want to give contributions, they can ensure that their changes won't break our changes, what I'd like to do is to modify that database. So this is one of the challenges is to craft a database that is similar to ours, that has, for example, holes in it where we are missing bugs because we share the bugzilla with several other projects and then deleted their bugs out, but yet make sure that the database is representative of what we're testing, with attachments, bug change data, and various user accounts. So let's say that you've got bugzilla installed. I know I'm sort of running through this, but we have a short period of time, so. So let's say you've now gotten bugzilla installed, you've read some code, you want to add a feature, what should you know? Reading through the bugzilla documentation is helpful. Talking to bugzilla mail and list is also very helpful. There are some interesting nuances, I think, about bugzilla that you need to know. One thing, for example, I was surprised to hear is that bugzilla wants you to modify the existing pieces rather than, say, adding new pieces, for example, a field. So I think there's some, perhaps, interdependencies and other pieces. So if you want to change something, they'd like you to repurpose an existing field. This is, I think, a little bit novel for some people. They might like to add a fresh. This might scare away some new contributors. Also, bugzilla, the way it's designed, I think, is because it's history, being developed over so many years, it can seem a little out of date. Some features aren't abstracted out properly. When I was looking at making some modifications to labels, to values, some of them are spread all over the code. And this can be a little challenging, I think, for newcomers, because when we modify our own bugzilla, we don't want to make massive changes against upstream because this means that we would have to forward port, we'd have to carry those changes forward every time we upgrade bugzilla. And I know that this community has a long experience forward porting changes against an upstream source. So metadata is another piece we need to address. We store metadata in three different places, two configuration files, and in the database. And this is another piece that I think has been challenging for people. It was, for me at least, it was just learning where pieces are supposed to go. So keeping track is a little bit frustrating, but we've tried to configure our bugzilla to make it easier for people to make changes, changing the rules, yes. So we also use bugzilla in a slightly different fashion than some other projects. For example, we've added a custom component, this UX Advise component, if you guys have ever assigned bugs to that, that field is basically a way for us to put bugs into a need info state, a request state, looking for input from the UI, the UX team. So if you are looking to contribute, if you're looking to help us develop, it's somewhat important to understand, I think, the processes of each of our teams so that you can understand how we have modified bugzilla for our needs. So basically, learn the back story. Contributions. So there are lots of different ways to help us with bugzilla. So coding, of course, is one of them, but there are lots of different non-coding ways as well. I'm sure there are several people out there who maybe would like to contribute, but they either aren't a programmer or would like to leave the programming at work and do something different when they go home. So having clear proposals for improvement that considers how we see our UI and how we will implement the changes. So one issue with bugzilla that I see is that the interface can be very confusing to users. It's one of the pieces of feedback that I've received several times. So if you're from a very technical background, I think it's much more compelling, it's much clearer, but for many of our users, it's very complicated. So input on how you can change bugzilla, provide useful either warning messages or information messages, I think would be one of the most effective ways for us to upgrade, for us to improve bugzilla because at least in QA we spend a lot of our time communicating with users, trying to explain to them why we configure bugs, why we specify changes to bugs in the bug tracker. So a simpler communication with users, I think would be very effective. There are several changes that we would love to see in bugzilla itself that can be done in the upstream project as well. So several of these, I guess all of these would require programming experience, but the benefit of this, of course, is that if we could see these changes happen in upstream bugzilla, then several of the projects would benefit. So for example, attachments. Many people attach compressed files that contain test files, images, maybe, et cetera, and it'd be very convenient for us. It would help us speed up our work if we could see those listed individually inside bugzilla. Similarly, I get requests. Yeah, sorry. Yeah. It's just a pain in the ass to what? Okay, so you... Many types. Oh, so you, oh, it's a ban those types. Okay. Yeah, I mean, I guess, I mean, seven zip, so you're just saying it's a pain to open them or what was the... Is it aligned range? Okay. Sure. You got access to the... Sure. Yeah, and I guess it would be great, I think, to address that on the backend, right? So if, for example, we could have the server at least, it could be just in time, I guess, but basically, the server deal with the decompression and listing, then from the developer's perspective... So if I search in the zip files, which will sometimes be a great thing for... Sure, sure. ...restricted for instance. Yeah, sure. I think one of the things that, I guess, from my perspective in terms of improving bugzilla is that several of these issues have been longstanding. They've existed inside of upstream bugzilla for quite some time, and I know it's a similar thing with LibreOffice. It's about finding the resources, the time, the money to go forward and actually make these changes. So right now, our current plans are to make some small changes. We want to make some further restrictions to fields who is assigned, QA context and such, so that, again, ordinary users, I want to say it's malicious, they just don't know that they shouldn't be changing these fields, they shouldn't be modifying the bug in particular ways. We're going to upgrade to bugzilla 5.0, which will give us some more APIs. Unfortunately, it won't give us some of the great features as I listed before that we'd like about attachments, but it will give us, I think, some easier statistics and some basically better user interface. There are definitely a lot of future ideas, a lot of ideas that we've brainstormed for the future of bugzilla, and if any of these, in particular, appeals to you or seems like something that you'd like to work on, I'd love to talk to you because we have a finite amount of timing, QA, that we spend both on improving bugzilla and, of course, dealing with bugs themselves. So one more person into the team can make a big difference. So one of the ideas was adding recruitment language to bugzilla. So one of the biggest places that we recruit new users to join the QA team is from bugzilla and from the user lists. So if we see someone who wrote a very competent bug report or someone who's asking the right questions, it would be great for us to be able to paste in some information directly, maybe send them an automatic email that would bring them a little closer to joining us. Just real bugzilla VM, one of the ideas because the installation of bugzilla is a little complicated with all of our modifications. It'd be great to have something we just hand to people. They'd boot it up and they'd already be ready to start making changes to the code. Guided forms. So I mentioned that we have guided forms. They're basically a Fisher price-like interface, hand-holding interface that makes it easy for people to file new bugs. I'd love to, again, parse more information, make it more automatic how we deal with information coming from Libravis intelligently. And I'd like to add some dashboards. So we aggregate a bunch of information, but I'd like to provide some graphs, and other information online about outstanding information, backport requests. The backport requests sometimes are not on people's radar, and so that way we could see what bugs people have requested to be backported. So basically, bugs that are fixed in master, but that people would like to see backported onto stable branch of Libravis, or one of the existing release series. And of course, for QA, it'd be great to see, again, a interface so that we could keep track of any gardening tasks, any cleanup tasks, things that we shouldn't see like there should never be commas in the whiteboard field. It'd be great to see all of that visually so that we would know when we should go through and clean up these particular details. I have a whole bunch of ideas about how we can speed up bug triage and respond to questions from users. But of course, the biggest piece here is to recruit people who are excited about making changes to Bugzilla, who are interested in helping us improve the documentation of how we use Bugzilla and improve our processes, because that's how we have time to work on some of these exciting features rather than working on just the regular bug triage. So, I think that's my talk. Any questions about Bugzilla? Yeah? Matthew? Ha ha! Yeah? So you're using Bugzilla for productivity? I what? Yes, so you're using Bugzilla. Bugzilla, that's right, yeah. Did you consider using ZILA by alerting too many to directly? ZILA? ZILA. Oh, ZILA, okay, yeah. Um, I... Screen focus also. Yeah, so our first big step this year, as I mentioned, was migrating the bugs to our own bug tracker. It was a big step, took a certain amount of planning and it went very well, which was great, I think. So we moved, we sort of duplicated the database, the Bugzilla database and the content and set it up and now have been working with our own instance. I do think that there are several features that Bugzilla doesn't contain and again due to the age of the source tree and perhaps the current level of development that we are not seeing some of those new features being implemented quickly. So, you know, I do think there are other bug trackers that offer a sort of compelling set of features. I think for some of them, I'm not as familiar with them. I don't know if, you know, developers are as well, but it's something we could consider in the future. I know that, I think it was Wikimedia moved a whole bunch of their infrastructure to Fabricator and they were talking about that at the falls this year and it seemed, you know, interesting. It seemed like that was a very large amount of work migrating to a different system. And, but I think it could be something that we could look into in the future because it, you know, if we could move to a system that was more agile, that was easier to modify, that could save us energy and could make us more effective in the long term. So, if you have experience with Azure or other tools, I'd love to talk with you about, you know, what you think, how we could, for example, structure LibreOffice project and components and may some of our other tools. So, we have other things, libraries, for example, from the document liberation project we store in Bugzilla. So, if you have some suggestions about what would be a possibility, I'd love to hear from you about how we could use that. Yeah, yeah, yeah, no, that's, yeah, later, yeah. Okay, yeah, okay, yeah. So, that might be sort of a deal breaker for us because I think for a lot of people we, you know, as much as possible, like to use, you know, free open source software projects and there are bug tractors, though, too, as I said, like Fabricator, and so that there are other possibilities in terms of using other tools that might be more effective. Right now, Bugzilla works for us, I think, and offers a number of great features and has the possibility to be expanded for more. So, you know, again, I've been, I guess, shepherding a lot of these changes and addressing a lot of myself and I am really happy. I'm actually looking forward to bring more people into that mix and, you know, not only having their help and impenetting what I've looked at and what other people have suggested, but what they suggest because I'd like more people to feel like they have ownership over the bug tracker. It's a piece of shared infrastructure for the entire project. And again, hopefully our changes will benefit not only us, but other projects. So, yeah. Any other questions about LibreOffice, Bug Tracker, Bugzilla, QA? Okay, well thank you. I have still a bunch of document freedom day stickers, as I said, so if you'd like to come grab this from me or have questions, I will be around all week of course. There's no wallets on these stickers, but I'm sorry. I'll make sure to have some next time, so. And I think we need to name the wallets, too. So for those who don't know that a lot of QA, iconography and a couple of t-shirts, and my talks often have a wallets on them, which came out of some discussion we had in the QA channel, which I like to think is the most fun LibreOffice IRC channel. But I think sometimes the Dev IRC channel gives us a run for our money. But we have this sort of, yeah, mini mascot wallets.