 Okay, hello, I'm Mike Kagansk and today I wanted to present something not very technical, not very deep, just some fast rewind and fast forward over what I accomplished during the last year. First of all, who am I? I work for Collabora, mostly on core part, so I work on improving LibreOffice and CollaboraOffice best-of-solution. Previously I was a system administrator before joining Collabora and I was so happy to be noticed and I'm glad to be part of the team. First of all, and the largest part of my presentation would be just a discussion of commits, what kind of commits were pushed during the year that passed since the last LibreOffice conference. So, well, I'm proud to have a rather large count of commits, oh, Collabora joined so he will laugh, I see, but, well, anyway. And so these commits fall into several categories, bug fixes, build fixes, optimizations. And, well, I hope that overall everything we do, everything developers do, improves the product. So, of those commits, more than 100 references, some TDF, bug zealom issues. There are lots of them and so I can say that many things are direct response to requests from users because, well, bug zealom is about that, getting requests and tracking its implementation. The first thing I wanted to tell is that I can, I have discovered the true meaning of LibreOffice conferences. You are told that it is a community building, that it is some kind of blah, blah, blah, but actually it is just to improve impress. Every year, the developers that prepare their slides fix bugs that prevents their slides. And so I can tell that the first thing that I did last year after coming from the conference was fixing the bug that hit me there. And now I am sure that even though I prepared this especially boring presentation, at least my system won't sleep during it. So, yes, and it shows actually how important it is for a developer to actually use not only run, not only reproduce something, but also use for real the product that we create. Because, well, it becomes, you start to feel users pain and, well, fix something that stretching your own niche, which is very important. And to conclude the topic of impress, there are some other bug fixes here. There were crashes, there were wrong chart colors on slides, wrong sizes of images, so different kinds of bugs. But not that many this year, I didn't actually focus on impress. The next one shows the other aspect that I didn't really focus much over this past year is it is calc bug fixes, only six of them. And also one of them is just my own regression, so shouldn't count as an achievement, of course. So, here comes the mine part. I focused mostly on writer specific problems during the year, and writer specific problems also fall into several categories. First one is the general ODF user interface, but writer specific user interface. Sorry, sorry. And so on. And there were quite a lot of such improvements. They, again, crashes happen and were fixed. Some performance improvement and, well, fixing behavior of different user functions such as searches, such as selection, everything like that. So, you see, there are several slides listing these fixes. But then comes even bigger topic. They were already talked about interoperability, it is really an important part. And I played some role in improving this topic in the field of docx compatibility. You might notice that it is all about bug fixing, not actually creation of new features, but this is what possibly unusually I like most. I must confess that I more like to fix bugs than to implement new features. So, yes, sometimes I hear an idea that we should focus on, should not focus on interoperability, like we should just improve ODF and don't care about people who try to use, to export to other formats on the grounds that it will never be really 100% perfect and so on. But I really disagree. We all learn foreign languages. We communicate with people. And sharing documents is just a way of communication. If we don't allow people to communicate in different languages, like file formats, it is not real freedom, real help to our users. So, well, I feel that creating, improving interoperability is one of the most important topics in LibreOffice's future. So, well, these section of compatibility fixes is the biggest one, so you can see this list without paying attention to the contents. But, well, I wanted to say that one of the biggest problems that I faced was mapping word styles to writer styles back and forth. And we made quite some improvements here because sometimes it makes a very strange appearance of a document absolutely unclear why some parts of imported or exported documents suddenly become italicized or something like that. Well, I handled a bit of these problems. Well, and there was a work on table of contents, compatibility fixes. Parts of text were not showing at all as if it was outside of paper while it was not. So, very many edge cases appear and people file bugs and we fix them. By the way, what I wanted to also tell is many users complain that developers are obsessed with creating something new, but we do file bugs in large scale. So, the docx compatibility fixes continue and this slide lists other bugs, but one of them is also dear to my heart. It was, in word, there are also many levels of formatting and they do not map one to one to writers and we needed ways to represent this formatting and coming from tables. And this was a rather interesting engineering task, how to do that. Hopefully, I made it in a useful way again, because there is no one to one mapping, we needed some creative workarounds. Of course, as with any such thing, I expect regressions, unfortunately, but no fix without regression. So, this concluded the docx fixes that I made, but there was another file format that I worked quite a lot during this year. It was HTML and by the way, specific flavor of XML, which is implemented in the same filter. And we improved the correctness of generated HTML in some cases, like lists in tables. So, there were edge cases when, for instance, the table was the first, the inner table was the first element in the author table and it got lost with export and import and so on. So, I hope that after this past year, our exported HTML and XML will be much more correct. So, also, there was some PDF fix, hopefully less page scaling problems will appear, but okay. And now, the writer section was done. Let's move to the API and scripting fixes. It is used a lot. If you open our forums or ask site, you will see I estimate about a third of all questions are about scripting. And so, improvements in this area definitely benefit the community. You might also see how many bugs are there in the bug tracker about it. So, fixing those in TDF, I believe, is also important. We optimized some processing which took ages to complete. We corrected use of URLs. We have our internal URL schemes. And sometimes the API, not related to basic, but our UNO API were implemented simply wrong. So, they were also improved in many cases. Here, it continues. And so, I suppose about 40 bugs in general were fixed in the basic and API area by myself. And let's proceed to UI bug fixes. This is a rather problematic area because in UI, there is even less agreement among users what's correct. So, it is more of an art than of a science. Well, still, since it was bug fixing, it was simpler to me restoring some lost things. For instance, the tool tips in toolbars were lost since a decade ago. And nobody noticed it until recently. Well, it is restored. Possibly not that important because it was so, but still. Some problems created recently were also rectified like improper application of favorites in special character dialogue and so on. There was a regression related to decimals in font size field that also were fixed in the UI section. And there were also ruler problems, ruler related problems and autosave configuration. I believe the autosave is a hot topic and Justin works a lot on that. I hope that the next 24.2 version would make many users happy, much more happy than today with the automatic safe feature. In some sense, it was really broken until recently. And continuing the UI section, somehow I feel responsible for one specific topic here. It is about warning that Java is needed and it is not. For some years already, I fixed new and new cases and I hope that I fixed it already like three years ago, but users are very inventive finding other situations when this wrong dialogue appears. So fixing that was one of my fixes. This small slide is about Windows specific tasks and since I use Windows, I think I know something about Windows API and the specifics. I often am asked to fix these things like Unicode support which is done differently on Windows compared to how we do it on Linux or how paths are handled there, which is also done differently. The problematic thing here is that many problems here come not from LibreOffice itself, but from external modules used by LibreOffice. And that part might be very hard to fix when they rely on basic C++ routines, streams and so on, which are not really fit for the Windows specific Unicode support and so on. So sometimes instead of a real fix, I have to work around deficiencies, like in the old unmaintained Lucene library, which I recently had to patch to only prevent crashes in it, caused by too long paths and not supported by the root methods and functions it uses. And some quite sizable part of my work in this year was fixing and improving the feature that Collabora has introduced recently. It is a native language tool integration. As a new feature, it is expected to have some rough edges and indeed they were, but they were not that bad. And my part here was to make it more smooth. For instance, the language tool integration provides some specific language versions like Spanish, Argentine flavor, but also generic like Spanish, simply Spanish. And the problem was that when someone had a language like Spanish Bolivia, it wasn't checked by the integration. We improved that, so now generic fallback works correctly in this case and hopefully it would improve the user experience. Also, we rectified some URL handling and the passing of the Unicode characters in some edge cases and improved some user interface, added some tips, explanations and so on. So users will also have easier time understanding how to configure language integration. Now we finally arrived to the section of new features. If you ask a developer which feature is the most important, which features are the most important in a new release, every developer knows that it is indeed the features that the developer implemented themselves. But even then trying to find which of those is number one is usually a difficult task. I solved this task this year. I only implemented one feature so I can easily tell which feature in the new version will be the most important one. It is the legal numbering which is, did you hear about it? Don't you know this most important feature of all time? Well, it is important for interoperability and, well, it is implemented in the upcoming 24.2. So here it is. Oh, I need to hurry up. I'm sorry. So a short discussion about build fixes. We have CI infrastructure, indeed, but still sometimes there are cases when some platforms are not tested. Indeed, Windows 64 bits is very esoteric platform which is not tested in our CI, so sometimes breaks. Sometimes there are conflicts and so part of my fixes were about build fixing. And there was quite some effort in code simplification and refactor. It could seem unimportant but sometimes you just can't make sense of the code until you refactor it somehow. So it helps yourself. So I just need to refactor and then start debugging. It helps to others. It helps to newcomers who would be able to easily understand what goes on. I hope that my refactors don't mean that someone else next will need to re-refactor back so my changes make sense but still there were quite some commits here. And now I wanted to stop talking about the commits and say a couple of words about forms. I started with a need to use the software to feel the user's pain. And I also feel it's important for developers to visit user forums to read them, not only bug tracker which gives a structured overview of a problem but sometimes users just can't present their problems in a structured way. So you just need to come to the forum, read and try to see what is the most pressing thing. For me personally, the most pressing thing now in the project would be the problem that we often, currently we often corrupt documents because of not ideal export of OXML which prevents user from opening them again. This is not ideal for the image of the liberal office in my opinion. And just a few words about one very important topic. Who can, developers here so surely you know how this essential developer tool is called. The rubber duck is our friend. And what happened to me many times over all the years but most often during this last year was how often creating commit message turned out to be the best rubber duck helping me to understand that when I created a bug fix, when I finished it, when I clean it up and I start to write something explaining what the problem was and what I needed to why it was there and what I needed to fix and how I did it, suddenly I realized that I did it wrong. Just I just to throw it away and start from scratch. And if I didn't write it, I wouldn't realize that I created it in the wrong way. I was really happy about that. It wasn't like anger. Oh it is rather it was exciting thing that I was able to catch it and fix it myself. So good commit messages is your good rubber duck friend. Please create good. I am really excited to follow the commit messaging of Armin, Stefan, Miklos they create. I hope I am the fourth. So writing commit message, good commit messages is a very important thing. So thank you very much for your attention. This is all from me for today.