 Hello, everyone. I hope you had a great coffee break. Now we're back with the scheduled content which is the Gold stock, which I call Gold. All the new because we'll be first talking about the present and then at the end the special treat, which is the future of KDE Golds. So, yeah, let's start with the past then. The distant past for some, 2017, ancient times. I see all the people not being happy with this, stop shaking your old bones at me. It is distant past. So anyway, Lydia's blog post, you can say it started it all, the whole initiative about the Golds. Credited in that blog post are some other contributors, Kevin, Mirko, David, and Frederick, apparently all put their minds together to figure out how the Golds initiative should work for the community. And apparently, for several years, this and a couple of next blog posts were the only place where the process is written somewhere. So, thankfully, the blog post was still up. Otherwise, we wouldn't have an idea how to perform the selection of Golds. So, at that time, the first Golds were selected. There were 10 proposals that ended up being available for the vote. And as you might remember, or not because that's the distant past, it was usability, privacy, and onboarding where the first three Golds that were selected. As a maybe funny note, there were over 600 Golds cast for that particular vote. And it gets hard to try to figure out with our ranked voting system who is the winner, and it's hard to do. So, Kevin created a PHP script to basically ingest the results from the system and spill out the winner. It's a temporary solution, but it worked for that time. And thanks to that, we got our first three winners. Then the not so distant past. You might recognize the Golds webpage because that's how it looks today. So, in the year 2019, time to select the new Golds columns. Well, just as a reminder, when we select new Golds, the old ones aren't cancelled. They are and ended. We just shift our focus to the new Golds instead. So, the usability, et cetera, are still alive and well. For example, you can check out Nate's blog post which started around that time and it's still going regarding usability. So, after two years, it was time to select the new ones to focus the community on. This time, 600 votes, 11 proposals that went to the final stage. And as you hopefully know, the winners were Wayland consistency and all about the apps. And as a side note, the same temporary solution was used again to figure out the winners because it's hard to count the 600 votes from the system. So, thanks Kevin. The temporary solution has saved us at that time again. And then something happened that you might know about. So, maybe a quick recap of what happened since then. So, even though the epidemic happened and it stopped some of the work, some in-person sprints that were supposed to happen didn't happen. Of course, this is our first big event that we can meet each other together. Because of that COVID situation, we actually extended the Golds for an additional year, hopefully to make it right. And finally, for this year, we're ready to select new ones. As a other thing that happened, we switched the Gold Champions for the apps Gold from Jonathan to Alish. And some other things that happened. So, the KDEV has hired a project coordinator, mainly to help with the Golds, yours truly. Maybe a consequence of that, the Gold selection process is now documented on the wiki instead of Lydia's blog post. So, if something happens, it's now possible to go through the process yourself and see what exactly should happen when, et cetera. So, that's good. And during my, as part of my work as the coordinator, we set up a, about monthly meetings with the champions to meet and discuss their work, to how the EV can help them, how they can help each other with outreach, with the work that's being done. And I hope this will continue for the new champions that will be announced today, as well. So, that was a quick recap from the overall process perspective. But as is tradition for Academy, I will now ask the champions to give their own updates about their specific goals. And I'll be starting with the apps. So, please welcome Alish to the stage. Do you want me to move it to the other screen? Yeah. All right. Okay. So, yeah, right now we're going to talk a little bit about what we're doing, regarding the app's goal here in KDEV. Obviously, not about everything that all of the apps have been doing. Like, all of you know what app you specifically care about, and I am sure that you're doing everything to make sure that this happens. But we've been trying to do some higher-level thinking work about how we can make them flourish more easily, right? Like, there's a ton of things going on regarding creating an app that goes far beyond the actual C++ project or whatever it is that you do, right? Like, you need a little bit of infrastructure in there so that you can reach your users. I think that it's worth noting that one of the things that we do quite well in KDEV is apps, some of them are very well used around the world. We have over 240 listed on our website. Some are more technical details than others, but all of them are for our users. And I'm pretty sure I'm quite convinced that, well, if humanity used more of our apps, we would have less walls. So, big part of the reason why we're not reaching these users, it's not exclusively because they're not as good as they could be, but because it's hard for us to do all of the work, right? Like, for example, as a software developer, you're good at, I don't know, doing a code refactoring on your code or maybe putting together a UI, but are we, well, as good as it gets to, like, putting everything to last mile, right? Like, getting on all of the stores that we could be, making sure that we're all integrated on every platform. And these are things that we always need to do. And as KDEV, we're not that all segmented so that we, like, we only do one thing. Like, if you as a maintainer, you say, no, no, I don't write blog posts, you're already a bad maintainer, right? Like, as maintainers, we need to write blog posts, we need to care about bug reports, about these specific features that two people care for, but we might care for because it's our app or not. In any case, things specific about our apps is that we have this end user focus in mind, so we care about things that people are going to use on their devices. We don't do, I don't know, apps for helicopters. We do things that you're going to have on your laptop, on your phone, on your, I don't know, TV nowadays. And there's always this one-to-one relationship with the app and the end user. Not that this is, we're the only people doing that, but this is something specific that we're doing, Katie. And then we're a multi-platform. We are based on a framework that helps us reach other platforms than our probably most important one, which would be Linux and the FreeSover platforms, but we're also, by using Qt and developing our apps with a bit of good intentions, we can reach other platforms like Windows, like Android, macOS, and actually whatever platform that might happen eventually in the future. So what I'm going to do right now is a little bit go through the different platforms we're on, see how well we're doing there, what kind of work we've done, and well, to give an insight on how I see things going now that the goal is getting wrapped up as a goal, because there's going to be three new ones coming up. The first platform I'm going to talk about, or the first two platforms I'm going to talk about are the Linux-based ones. I'm not going to talk about the different distros first because we don't have numbers, or we don't have very good numbers there. Not that we have good numbers here either, but also because we don't put actively our applications on the different distros. It's not us who put the packages on, I don't know, OpenSUSE, it's OpenSUSE people who are very friendly to us, and most of them are parts of our community who do that, but there's not a lot we can do, I think, for all to improve this situation there. Also, we don't have a lot of grip on what can happen over there. But on the other hand, on Snap and on FlatHub, we're going to see later, we do have that possibility, we decide that when they're stopped, we get to fix it and then release a new version. And we're going to start talking about Snapcraft. Snapcraft is the solution that Canonical and Ubuntu came up with to make it possible for people to provide applications for them without having them put them into their distro. We have a ton of applications over there, 106. Thanks, Jonathan. Are you here? Wave? Well, everybody buy a beer to Jonathan over this week. Thanks very much for that work. Both this one and FlatHub have the specificity that we're also putting forward package for other applications that use Qt and KD frameworks to be on the platform. Here we can see that we have 300,000 deployments of that runtime in active use on the platform, which I think that it's sizable and useful. It shows that we're not just providing for our applications, which is useful, but we're also helping the rest of the community to reach these platforms by providing the infrastructure that we need. The important part about these packaging formats, of course, is that it's not going to force our LTS users to be stuck in weird versions, and I think that it's very important, especially on Ubuntu. There's a lot of Ubuntu users that are using LTS, and it doesn't make a lot of sense that because you want your system not to crash all the time or get new versions, if that's a definition of stability, that you wouldn't get a new version of gate or a new version of chicken prey, which is definitely something you want because you need all of the puzzles, right? Our applications that are in most use, I tried to make a very short summary over there, a Clarence Krita with around 60,000 deployments, and then there's Caddy and Life and Color Paint, which are also fairly used. Ubuntu developers clearly need a lot of colors in their lives with both Krita and Color Paint, right? Yeah, it seems like there's more than just brown. So the other store that we are maintaining actively from Caddy is FlatHub. We have also over 100 apps. You can find, so here in Snapcraft, if you want to see if your app is there, you can go to this URL, and if it's not there, well, you can make sure that it's there either by talking to Jonathan and he will tell you how to put it. Here, FlatHub, we're having the Snapcraft packages we build within our infrastructure. In FlatHub, we are building them on their servers. We just provide some recipes on this GitHub repository. So again, if you want to make sure your application is available over there, you go to this GitHub, and I added the search because everything that starts with org.cd is ours. If it doesn't start with org.cd, it's ours. You will see. If your app is there, if there's a bug, you will see what needs changing over there. Obviously, it's just the recipe. Most of the bugs will be in your C++ because, oh my gosh. Something that is kind of interesting about FlatHub nowadays is that there's these devices that I think David will talk about later that are called the SimDex. The only store that we have available on the desktop mode and that allows you to install normal Linux in on-games apps is FlatHub. So if you want to make sure that your application is working on these devices, you just put it on the own FlatHub and it should just work. We also have a platform. It has a little bit less users. In this case, the numbers are even less reliable than before. Well, before, it's the numbers that Canonical gives or the Snapcraft store gives. Here we are going with the, well, downloads and updates numbers for the last version that we released, right? So you can make of that what you wish. The most used apps or the most download and install apps are Katie and Life and Krita. You will see that Krita is a constant on this, especially outside of Linux. These two are 25K and Oculus. Oculus is also very loved on the multi-platform world, which is nice. And then moving a little bit beyond our Linux, but still on Linux, I guess. We have Android. As Android, I think that the important way that we should be thinking to deliver our applications is Google Play. On Google Play, though, we don't only have two applications right now. We have Krita, which actually is a fairly new thing, but they already have over a million deployments. Wow. And then Katie Connect, which actually is doing very well as well over there with over 300,000 deployments. Also, Katie Connect, I think that it's worth mentioning because it makes, well, all of the environment that we create much more appealing to a lot of Android users because we allow for their integration, also not only on Android, but more about that later. What we did for Android was to put together an SDK, which right now is using Kraft, Kraft being the tool that we use for more most non-Linux platforms and a image that is used to just build applications. Here we're talking about that on Android, on Windows, on Mac, what we're creating are packages that include all of the dependencies. And Kraft is good at that. So that's why it works. And we get to reuse a lot of the metadata from each applications. I talked about Google Play before, but since there's process between when you start creating your application and when you decide that you're capable of delivering them to users, we put together a Nile repository for Android that has well, 25 apps of ours that are already compiling. They should just work right now. And if they don't, I recommend you fix them so that we can put them on Google Play and make sure that billions of people are able to use your application and enjoy the freedom through their not-so-free operating system. Here's two applications. Here we have KDE Connect. KDE Connect is the only application in KDE we have that is using the native Java way of doing things, which is quite nice because there's been a lot of contributors that have started joining because they knew how to do Java. But we're not all that familiar with C++, QMN, and Kirigami, as everybody should be, obviously. And here at the left we have KDE Tenere, which is developed by Folker. And it's an amazing app. This one is using Kirigami. You can see that they look slightly similar in many ways, but not all. Well, we can work further together to make sure that they look as integrated as possible. But I think that it looks pretty good. I've used that application all while traveling, not that I have traveled that much over the last couple of years, but that is not Folker's fault, that's just humanity. And then we have the Windows Store. Windows Store being kind of interesting in that, well, on one hand, it has been the reason why many of us have started developing in KDE, but on the other hand it has a lot of users, and it has a lot of opportunity for us to make sure that our software can reach what I was saying before humanity. So we do have a bunch of applications over there, eight on the Windows Store right now, including, well, Krita, of course. This one is on 3 million acquisitions, they call them over there. Actually, Krita is the one on the store and then two on the Windows Store. So obviously we have this thing where we can decide to ask for a price for applications, and it probably makes a lot of sense because it's a way to fund the development. On the other hand, like, anyone could compile it, right? But then in practice, what we have seen is that nobody really wants to compile an application. And actually, just being on a store, it has a lot of convenience value to us and especially to our users. So they're playing this game on both sides a little bit, which is not to be a non-problem, as we will see a bit later on, but you see what I mean. Here we're also using Kraft for the Windows builds. We have a continuous delivery system that you can use. So you don't need to have a Windows computer to develop this application. What you need to have is, like, Kraft build the application. I still would ask you to at least have some kind of virtual machine or something so that you can try the application and make sure that it works. And when somebody has a problem, that's it, right? But you don't have to do all of the boring, non-useful work that you should do to make sure that application is available. You can focus on the QA and the things that you know how to do because, well, that's why you're the maintainer and that's why you're interested in reaching the users. Yeah. Something that I mentioned here, and probably we could extrapolate to the rest, I think that something that we should be doing more in the future. We've talked about it in the past, but we never really took action is thinking about monetization is definitely a problem for our developers to, like, not be able to sustain themselves. And, for example, create that if just done it, they added the price tag and they did all of the work to make sure that, well, people got what they paid for. I think that we can extrapolate this format to other applications if you are interested in going all the way in this direction. Here we can see some screensets as well. This is Kate, like you will see, it looks a lot like the Kate you have, but it has different buttons at the top right corner to close it. But, essentially, it's more or less the same features that you would get on Linux, but on Windows. And that's fine. And then here we can see our jewel of the crown on Windows, Krita, which looks good. And you can paint, which is what matters. Like I said before, here we're asking for money for something that is available for free in a way. And when I sent it for this presentation, I went to the Windows web app and then searched Krita and then I got all of this. And these two, I imagine that they just go to the website and download the application just for half the price because they don't need to do any of the development. I hear they've been reported, but this is something that we need to be wary of anyway. And we need to see how we can fix if it's fixable at all. We're going to keep having these problems, I guess. But I don't know. I guess it's a problem to good to have your tool to good that people want to steal from you, I guess. So to wrap up a little bit, you will notice that I didn't mention Apple and or Mac OS, if you wish. We do have an application on the Apple store, which is the KittyConnect iOS application. And that's working fine. It's a client that was created native also using native SDKs for the platform. We're not using the infrastructure we have in Qt because it was just not convenient. We haven't decided to put any of the apps yet because there's a lot of fear around our place and how it would work to be on that platform. It could make sense eventually, but we need to make sure that it's a place that we can be comfortable on. So, well, I don't know. If you have an experience, reach out. If you want to do it, reach out as well and well, do it. And in the meantime, well, we do have infrastructure, for example, to build applications. We do have system for continuous delivery. We also have Kraft adapted to build Mac OS binaries. So that works. Yeah. Something to put an effort on an emphasis on is, like, it's about the effort. It's about the effort about going to the, like, all the way to make sure that your users get the application, right? When you say, my application, my application is really good. You could use that application on any operating system. That's true. But then you need to, like, put the effort into, like, saying, if you say, let's put it on Windows Store. You'll need to spend some hours into making sure that it works on Windows like it should. But then it will pay off. Like, you will start seeing users. And I think that using the recompensation features that you have on that store is a good way for doing that. I think that it's a bad idea to talk about free server as this free thing or this ring for free. But, so if we can make sure that, well, people get compensated somehow for making sure that the application works, it's always makes sense. Creating an app is about, it needs to be a team effort or at least you need to be multidisciplinary yourself. You need to do things, like, you need to do the app. You need to do very good coding and, well, tech work. But then you need to also think about other things like QA about promotion, et cetera. And in KDE, we try to be, well, a varied community where people can do different things or other different people can do different things. And I think that we should try to promote that. So if you're good at communicating, of course, I'm not going to be the one saying don't do it. But otherwise, reach out to the people who are doing it and work together. And when you do, well, thank them. And I am talking about promotion, but for example, QA, et cetera. Documentation is also an important topic. Everything is very relevant here. And then for Linux, so like I was talking on the other operating systems, one of the things they have is that they have a plan to be able to monetize applications. On Linux, what we're doing mostly is relying on donations. We are working with some organizations to put together ways for that to happen. We're also working with our projects to do that like we've started to do with KDE and live in a somewhat organized way. But I am sure that there's more to be done there. Again, if this is something that you would like to work on, please reach out. And this is something that we can definitely talk about. Bummer. So this was not an empty slide. This had a different color of background, but yeah, it had white letters. So what I wanted to talk about in here is that we very recently hired our app source support engineer named Ingo. You've probably all met him before because he has been at the academy and around KDE for, I think, much longer than I have at the very least. Well, the text I had here was more or less the same. I sent to the KDE community mainly introducing his position. But a little bit, the idea with this position is to have somebody who can help all of you to do all of these, well, none specific to your application tasks, still technical that needs doing. So making sure that, for example, applications can bridge the different stores easily and so on. We're going to start working towards Windows. I think that many of you will have, well, interacted with him in that way. Not that we only care about Windows, but I think that it's one of those that we can start to monetize the earlier. And I am putting specific emphasis on monetizing because I think that it's not really fair that we start paying position for non-free operating systems that, well, is not going to have a direct way of returning that investment as an EV. So this is what I think that is all the most important part of his position. So thank you. Hope you liked my explanation. Questions? No questions. Okay, then I hear we have some minutes for questions. So does anyone have a question just yet? Okay, thank you very much, Alish. So now I will welcome and please welcome him with me. Nicolo for the consistency goals update. Go ahead. Does this work? Okay, can we get this working by any chance? I like microphones. It says on. Okay, now it's on. Nice. Sorry about that. I forgot to turn it on. Nice. Okay, so consistency. Consistency was selected three years ago. Three years ago, I didn't know anybody. I didn't know anything about KD. I just joined. And it has actually been a pleasure to have an in-person academy before everything that has happened after that, to actually learn about KD and being selected as a gold champion was a great experience. However, being selected as a gold champion, back then I was very much naive. I didn't know how things worked. And the KD consistency goal in itself as a whole was very naive. So what I did first was to go out, talk to people, try to understand how the community worked. I set up a blog, chat for the consistency, everything, a wiki page, a fab, these kind of things. And I'll go through them later on to see what worked and what didn't. So I want to not talk about the yearly advancement of the last year, but the consistency goal as a whole and what was the original plan, what was achieved, what was wrong in my initial plan. So the first adventure is consistency between applications. And what has happened is that just after the selection of the goal, a lot of people actually stood up and told me a lot of very valid criticism that all went to fabricator. If you go to the consistency board on fabricator right now, it is full of very valid criticism that is very relevant. And it has actually started a lot, and I mean a lot of very long discussions like this. And I was mostly leaping through them, but we actually reached a consensus very often. And I'm quite proud actually of those discussions because we had a lot of mock-ups, a lot of designs. And I think that the first part of the goal actually seeing what's wrong and seeing how we could improve it was correct, correctly handled. So what has happened after that? Less so. The first case that has happened after the discussion about a design, of course the first one is that nothing happened for most of the stuff that was proposed, obviously nothing happened. And that's reasonable. I didn't expect everything to be handled, obviously. There are some things that I'm a bit sad about that I didn't see. There are some things in particular that I took and I talked about them in every presentation saying we currently need somebody with this skill to implement this thing. And it's really important. Case in point, similarly to the K-Emburger menu that's in many applications, I really wanted something that was a key panel. If you pop up Dolphin, it has panels on the left and on the right that are customizable, you can move them around. They're very nice. They're completely different from each application. Each application re-implements them differently. Having a common component that you could use throughout them was something that I talked, I think, in every consistency presentation and it was never done. This is just an example and I don't want to blame everything on others after all I could have implemented it. I didn't quite have the skills. Another thing that has happened is that people did implement their designs, but they completely ignored the discussions. This is where I think I'm a bit more sad about. I want to make a couple of examples because I think that with all the discussion that has happened, seeing that those components actually implemented but completely ignoring the discussion made the discussion themselves feel useless. The first example is the swipe navigator. It has been discussed a lot on Fabricator. It was actually implemented in Kregami and when it was implemented, it did not follow the designs at all and it completely ignored the discussion, which is fine, but I would like, when that happens, to see more discussions like going back to the drawing board and find something that everybody agrees on so that we actually have human interface guidelines about that component and we agree on them and then we implement it like that. Another example that I could bring is the review. There was actually a lot of discussion on how an overview should look like, like the one that was recently implemented. When it was implemented, it looked nothing like a discussion and the discussion was ignored. I did raise this point and they said that it was still being worked on, so the final version was going to look different. That was not true. I mean, it still looks the same way. Again, this is very much on me as well because I could have contributed to the overview to make sure that it followed more of the discussion, but at the same time, I would like, in general, when very big visual design changes are implemented that there's more discussion and more respect for the discussion that's behind them. In general, I would like something that a bit like you only merge a merger quest if tests pass, you only merge a merger quest if there's discussion and there's an agreement and we update the human interface guidelines as an example or any other webpage that describes how the component should work before actually merging the merger quest. That is my proposal after the goal. Am I forgetting anything? Yes, one last thing. To actually address inconsistencies between applications that are a bit less, I'll talk about that later. Anyway, second part, up redundancy. So another very big important part of the original consistency goal is all the application that seemed redundant. That is, we have multiple applications doing the same thing. And this could lead to work for, like, we do the same work on different applications, so it gets kind of wasted. And from the outside, we don't quite look like a unified brand as we could be as Keri. Now, it really comes down to whether one person thinks that Keri is an umbrella that should contain the projects that are very close to Keri development and everything, or whether Keri should be like more like a brand that actually tries to have the application for something. And a couple of examples here. I still think that it is very much not a good idea to have two different entire ecosystem within Keri. To make an example, Maui is very much doing their own thing with their own design. They have their own Maui kit. They also have their own shell with Maui shell, which is kind of an alternative to Plasma shell. And whereas Maui apps and Maui kit are part of Keri, Maui shell isn't even though Maui shell is usually shipped with Maui application. This whole situation, I think, is really awkward. And what I would like to see is after that, we have something like an HIG that defines how apps should look and behave to actually go ahead and say, if an application that's within Keri doesn't look at all, it doesn't even try to follow the Keri guidelines, then it could be a third-party application very closely related to Keri, but not directly underneath the Keri umbrella. And of course, this requires Keri to forcefully say bye-bye to some application, which is extremely naive, I realized that. But it is something that I would like to see more discussed in general. That is a proposal. Secondly, there are some apps that are a bit stagnant, not Keri Gami, obviously. There are some apps that are a bit stagnant. In general, I would like to see those apps move to Keri Gami because I think that Keri Gami helps consistency incredibly. Some apps that, as an example, came my money is a very nice application. I actually see it developed with new icons. I think that these kinds of applications, we should try to go to them and try to convince them to switch to Keri Gami. And that would actually help the consistency goal a lot. Again, extremely naive, but on the long-term, I think that should be the way. Thirdly, there are a lot of applications that seem extremely similar, but they are actually different in how they work. As an example, we have Kate and Kate Wright. And I actually want to congratulate a lot with how Kate handled this, because even though they're technically different applications, under the hood, they share the same code, they're almost the same application. This has been highlighted very nicely in a recent blog post from them. I think that that should be how it works to make another examples. Now that Lattedoc doesn't quite have a maintainer anymore, something that could be nice instead of, like many asked outside of the Keri developers community, replace the plasma panel with Lattedoc, which is not feasible, but try to share as much code as possible to make sure that Lattie becomes more of an extension to the normal plasma panels. That would actually help develop both projects and keep them alive. Thirdly, brand consistency. I talked about this a lot in the original consistency blog post, talking about the website. As an example, many applications had their own website that looked completely different compared to each other website. And I think that there has been a lot of improvement for this. Like just to make a very small example, recent one, the Bugzilla instance was redesigned to look very much more like the KD design. And I think like Carl in particular has done a lot of job to make sure that all the websites inside the KD.org directory actually looked with the same design. I think that has improved a lot. So I'm really happy about this. One thing that I could suggest, which I didn't even think about obviously, firstly, is that we could try from the promo side of things to commission brand guidelines to use throughout all external communications. We already have, I think, some good ones, especially like Academy, the style of Academy and Academy announcements are very consistent throughout the years. But I think there is some room of improvement in general. Lastly, consistency between applications and Plasma or within Plasma itself. Something, I think this is another place where there was a lot of improvements, like making the start menu actually look consistent in its design with the other applications. We have now consistent highlights between Plasma and the application. We have the header area, which looks the same and actually follows the color scheme. All of these things are great. And I think there are very nice improvements. The icons with the margin areas, I think, improved also. And their size is generally more consistent now. So I think there has been a lot of improvements from this side of things. One thing that I would like to see improve, and as much as I can, I would like to help as well in this, is the Plasma styling because we have split completely the styling between apps and Plasma. So Plasma is completely styled through SVG, whereas apps have their own Q-styles, which means that every time you make a design change, you have to implement it separately in SVG and in the Q-style. And I got to say that I currently actually like the SVG theming system. It is simple. You can easily use it. But the more I actually look into it and develop stuff for it, the more I feel like, what? So this is something that I would like to see. I know that there are discussions on improving the theming system for Plasma 6 and moving to something like CSS as an example. There has been that kind of discussions. It's something that from the consistency point of view would help a lot. So I would hope to see them. Lastly, I want to say that in the Plasma UI and some of the applications, there are some paper cuts to do, like very small spacing mistakes. Sometimes there are slightly less spacing that there should be and they're inconsistently used throughout the UI. Those are very small, very easy to fix. And I think those could be a good way to actually onboard people and get them to contribute. Whenever we post a screenshot on Reddit, there's always that Reddit guide that goes, spacing is wrong. And I think that could be an onboarding opportunity. Finally, how was the goal? Do you want to contribute to my slides? They were correct when I sent them. Anyway, how was the goal? I did a chat for the consistency goal. I think that that chat has lived a couple of days and then it died. That is not something that I would do again. I think it's really important to value the existing communities, such as the BDG. And that is where I would have used doing the goal again and nowadays. Secondly, the sprints that we had were completely useless, sadly. COVID didn't help. And the fact that the goal was prolonged one year didn't help us make an in-person sprint. I would have wanted to see an in-person consistency sprint. We couldn't. That was that. The blog post, I think four or five blog posts about consistency, which were supposed to be monthly, you know, falling near the meetings with Adam, I stopped doing them and that was a mistake. I think that blog posts either weekly or monthly are of great use and they actually engage the community a lot. And I would suggest in general that gold champions do blog posts about them because it actually helps convince other to, it helps with engagement and so other developers can actually value that gold more and contribute to it. So blog posts, yes, especially we can see the next one as an example on how it went great. Last point I want to touch is that I feel like the last year in particular has been super slow for the consistency goal. And if I were to choose now originally, I actually asked for an extension from two to three years because of the pandemic. Nowadays, I wouldn't have asked for it because it hasn't been of much use. So I'm a bit sad about that. It is totally because of me, because I didn't actually do much on the consistency point of view. I got lost in the contributing to plasma in other ways like the floating panels, this kind of things. I didn't help much. So that is totally something I blame myself for. I don't want to make this presentation like I'm blaming others now. And that was actually the last point I wanted to touch. So thanks everybody, subscribe to my YouTube channel, leave a like and everything. Are there any questions for the champion? To argue for certain projects to be included or not included purely on a branded basis, especially when in the case of things like Maui, we share a lot of code with them. So there are clear synergies to use a business award between general KDE projects and Maui projects. Yes, the G-Comprise example is actually one I went through when doing this live. So I thought about it. It is true that it doesn't follow the KDE's design, but G-Comprise is actually meant for something else entirely. It has a UI that is meant for, I guess, children to learn and so big buttons, big flash buttons. That's the use case and it is extremely reasonable for that user interface to be completely different. When I started three years ago at a consistency I actually took a lot with the Maui people on how to best address the fact that their design was completely different. And I feel like there hasn't been much effort from their side to make sure that they fit the community very nicely in terms of consistency. That is my impression. And I am not saying that we should like, okay, no, I am saying that we should kick in. Let's not try to sugar cut it. But I do think that it would be better to have Maui as a very close organization to KDE, so that very close to KDE, but not directly under the KDE organization. We have many other organizations that are very close to KDE, but not directly underneath. So that would be what I'm proposing. I think that this current situation is not optimal. That is a very controversial personal opinion that I wanted to share. Okay. So you talked about a subject near and dear to my heart, which is VDG engagement. My question is, how do you think we can make developers want to listen to VDG more? Because I think policies that aren't supported by pre-existing community desires don't work so well. So how do you think we can make VDG a more attractive thing for people to listen to? Yes. I don't think that most of the things that weren't implemented weren't because the VDG wasn't appealing. I think that there was, there's not enough work force to make sure that all applications and all maintainers start working towards consistency with what the VDG proposes. What I see personally as a way to improve things is making sure that as many applications are as possible currently either switched or made in Kuri Gami, because in Kuri Gami or other toolkits that built on Kuri Gami that could be created as an example, Janet wanted to make one. Because this way the components that can define their own style directly inside of the toolkit, so whenever an application uses that toolkit, it is consistent out of the box without even the need to go to each maintainer and ask them to change their design. If I look throughout Kuri Gami application, I think that their consistency is significantly higher compared if I look throughout Kuri Kuri Gami and Kuri Widgets applications in general. That is a way that I would see things improving. Thank you very much, Nicola. Applause please. The third goal is the Wayland goal. Unfortunately, Maven couldn't be with us today, but he is in spirit. And I think if we really think about him, we just might hear his voice. Good morning everyone. As Adam said, I'm here to present you the final Wayland goal update. I couldn't make it to Barcelona, but so what kind of this for me and my spirit will be here. So first a bit of introduction about the goal. The goal is just simply to deliver a pixel-perfect free lightweight and secure user experience on the Linux desktop and not just the desktop. So as anyone can hear, it's just easy, right? But that's what we asked for. But we are a first community with resources, so we need to find more people to contribute to and so to attract users and contributors. And that's what the main goal of the Wayland goal was. In fact, in a few years, we couldn't really achieve all we were tasked to do, but only if we were to find enough people to push things forward, to create this virtual cycle of users reporting bugs and bugs getting fixed, and more developers joining in and so on. So we make incremental steps, small steps sometimes, one but fixed at a time, one release at a time. And Plasma releases mark the milestone of the progress, you know, software stack. So I'm going to present a brief recap of Plasma releases and the Wayland progress since last academy. In Plasma 524, we got the overview effect. My slide, all right. Plasma 524, we got the overview effect, which improved the user experience despite the inconsistencies perhaps, but really greatly improved the back end of Queen, allowed Queen to be less stringent on OpenGL, which opened the door to better effects in the future, in particular, a simpler compatibility with Wayland. And we got improved NVIDIA support, because NVIDIA, the famous GPU maker, finally released a driver that could help support Wayland on the GPUs. Because of that, we implemented the support. Queen developers added support in Queen for these GPUs. But a patch in Qt was needed, too. So the patch was done in Qt 6, and back parted to Qt patch collection, which unfortunately doesn't reach all our users. And so that's why I put this asterisk. It's really a hard caveat given that the distros that doesn't, the users that don't get those patches are using a very popular distro unfortunately. It has been a sore point for Wayland user experience in general. And in Plasma 5.24, improved stability. So really, we got an influx of positive feedback on diverse means of communication online after the release. And then can you move on to my next slide, please? All right. And in Plasma 5.25, we got the touch mode, which allowed better tablet support, and which was awesome, which was really aligned with Wayland. And we got a ton of stability improvements, building upon the previous work. Next slide, please. And we are getting ready to release the next version. And next version is like the others. It just add a few more, it fixes a few more issues a few at a time. So we kind of get an improved virtual keyboard support. Virtual keyboard support got implemented a while back. But now it's a good opportunity to improve upon it and allow some nice work on it. We have better graphical tablet support. Also, it was implemented in Plasma 5.23, if I recall correctly, support. But now you can properly set it up in a KCM so that your graphical tablets rightly correspond to your screens, to your screen coordinates. And we got X-Wayland and GPI improvements. So now users will be able to set the behavior of fractional scaling with their X-Wayland applications between two choices. And we got a lot of stability improvements and got really impressed with how many bugs we got to fix and from small to big. And next slide. And but all is not great. We still have a lot to do and we have a long list of showstoppers that has been shrinking but slowly. And we have still have some big items that we will eventually fix, like missing color profiles. When I said at the introduction that we need pixel perfection, well, that's kind of the subjects that we need to tackle to achieve these goals. Because at least for some users and need these kind of features. And until we fix those, we fulfill those features, those users won't be able to use Wayland sessions. And we have a blurry rendering with fractional scaling and that you can observe whenever you use fractional scaling on Wayland, you will have blurry things because of double scaling up and scaling down the image. And those two issues are symptomatic of some of Wayland ongoing progress. Because those two are being worked on in the Wayland community where KDE members also are contributing in being part of the effort. But all in all, it takes quite a long time during this progress process, but it will eventually come around. And there are many more, quite a good handful more, sounds that we need Qt6 and Plasma 6 to be solved. And that's something that makes me think that Plasma 6 will be an important milestone for our Wayland support. And then we will have to achieve our goal, we will need next step, we will need a better application compatibility. Because once we have a good session, we need, there are a lot of applications that have different needs. For instance, for virtualization applications, usually they are only targeting X11. So through X Wayland, their support is not great. It would be so much greater if they could be Wayland native on the outside. And for screen recording, we have OBS that supports pipeline screen recording, but other applications need to adapt. And those issues are really the chicken and egg problem. But the good news is that we have more chicken than that. Well, the wheel is spinning and now as we progress, as other platforms also push Wayland usage, like it is going to use Wayland wherever possible if I recall. And devices that use Wayland by default will really push adoption forward and we will reap the benefits eventually. And the goal is coming to an end, but community efforts won't. By that I mean that we have a strong momentum and now we have a good chunk of our users that are using Wayland and expecting it to become the norm. So I started a poll on Reddit, on Caddy Subreddit, to ask our users how many are using Wayland or whether they were not just interested or finding it not suiting their needs. And on this particular webpage, we could see that about 40% of those users that answered already use Wayland, 40% are really expecting it to to improve before they can make the switch. And about 20% will wait the last moment because either they don't care about this kind of problem or they want stability above all. And that's really encouraging because on this forum, this is quite unrepresentative to all our users. But still, it allows us to see that Wayland usage begins to reach maturation stage with regard to the adoption phase. When we have a new technology, usually we have a curve of users that adopt them progressively. And we have the early adopters and then the step in different phases. And we, according to Reddit, we can see that it's more, we are reaching the maturation phase. But we need still to put that in perspective that it's not fully representative to our users. So it's a bit too optimistic to the reality. But now at least we can see that we created ourselves a critical mass of users that going to report bugs and help us fix them eventually with this thanks to the virtual cycle. And there's no stopping the Wayland momentum. Thank you very much, Maven. Are there any questions for the champion? I'll check the online widget. No online questions. Anyone here in person? No? Thank you again, Maven. Can we switch to my slides please? Okay. So those are the updates for our champions. The current champions for a few minutes more. Like I said previously, the goals live on the work on consistency Wayland and focus on apps I hope will continue after this presentation. But now let's talk about the present. So you are here hopefully either online or in person. At the moment you've been waiting for. Six proposals didn't leave they're not ready for voting. Six advanced to the final vote. Over 400 votes later. And yes, I had to use Kevin's script again. And I actually added it to the process at the wiki page. So it's part of the process now. Thanks Kevin. It's time to announce the new KDE goals. And as the tradition goes, I will ask the new champions to join me on stage. And without any preparation, they will have to talk about how they plan to lead the goal for the next couple of years. So without further ado, the new KDA goals are and you should know them. You have them on your lanyard. KDE for all boosting accessibility, automating systematized internal processes and sustainable software. Carl, do you want to join us on the stage? Most of you already know me. I'm Carl. I'm doing a lot of stuff with websites and as a calendar and as a new chat. A few KME applications. Yeah, I wanted to have this goal about activity because we are developing software, but importantly, software is not really yet to be used by everyone. And most, okay, we have the platform issues. What we are doing on every platform was the goal from last year. We bought the KDE for all the apps. It's for the apps goal. And I thought that because some issue with the screen with us, but not everyone can actually use applications because they don't have the capabilities always to be able to see the application or to use the mouse to navigate the applications. And that's why I'm wanting to have a goal about aggressivity. So we can reach more people and also help them because the goal of KDE is like to provide application for the end users. And so that they are also able to use our applications. I think that mostly is. Questions for the new champion? Okay, you're being kind to Carla. Nate, would you join us on the stage? Hello, everybody. So my idea with this automation and systematization goal was born out of the observation that in a volunteer community, such as ours, people come and go a lot. And it's amazing that we've managed to produce what we have largely through volunteer efforts. And I think it shows the passion that is embodied in this community. But it also means that because people are coming and going a lot, oftentimes when people go, they take their knowledge with them. And so my idea here is that while people are involved in KDE, we make sure that that knowledge gets out of people's heads and put into systems and processes so that the larger community as a whole can continue to benefit from people's knowledge, even when they may not necessarily be actively contributing at any given moment in time. So this comprises things like ensuring that we have automatic processes to do certain things with bug triaging, for example. It means that we improve our continuous integration to check for people to check for things that currently people are automatically checking for. It means that we document our knowledge and we put that documentation online. It means that when we leave KDE, either temporarily or permanently, we do off-boarding, too, to make sure that our knowledge stays within the community. And then when we return later, we can regain that knowledge and build on what was there. So my hope here is that all of us can sort of externalize our brains a little bit, and so that we continue to benefit the KDE community, even in moments when we're not personally contributing at any given moment in time. So thank you very much, everybody, for choosing this goal. And I hope we can make some really great progress with it over the next couple of years. Any questions for the new champion? I don't see any. Thank you very much, Knight. Yeah, so this concludes the presentation, because unfortunately we don't have Cornelius with us today for the sustainable software. But fear not, I will be contacting our new champions, figuring out our monthly meetings, and I'll be sure to make them do updates and outreach to the community, so you'll be hearing from Cornelius and the rest of the new champions very soon. Are there any questions about the process to me as a speaker from the audience before we end it? I don't see any online. Okay, here's one in person. Um, then this ghost process, there were like 200 less votes than the two votes before. Do you think before I think the ghost process was a success story? At least I see so, but for some reason, that a significant amount of people less voted this time. Do you have an idea why that is, or? Yeah, I noticed that we had significantly less votes than compared to the previous years. Unfortunately, I couldn't find the reason why. As far as I know, we did it completely the same as the years prior, which is to announce on the community mailing list, and also send direct advice to everyone with a developer account, because you need that to actually vote. And there were also follow-up emails to nudge people to actually vote for those who didn't. So I'm not exactly sure what happened. I doubt we had that much less developers or developer accounts active than previously. But it's definitely something I would love to think about and improve in the future so we have even more people voting. Maybe there's a opportunity to talk about the general process of voting and how to improve it. Maybe the restrictions are to be great now, and we should open up to more people. But I encourage anyone who has ideas who would like to talk about the process to either do it with me here on the conference or maybe on the community mailing list, and I'm all ears. Thanks for the question. One thing to add to that, I might have been spamming people a bit more in past years where people actually complained. Okay, so Lydia was spamming people more than I did. Maybe that's the reason. Yeah. One question and one comment first related to the last question and comment from Lydia. Did the voting happen during the same period of the year? Was it also in August? Because August is a season when people go on holidays. Maybe there was an effect there. Yeah, that's a good question. The voting is set up to happen. Like the time frame is pinned to when academy is. Because academy happens at different months, then the outreach, the voting, the selection process, etc., it's all pinned to when that date is. I would have to check at what month was academy for when the previous goals were announced and the ones prior to that. But yeah, there is a chance that the months were maybe less good for outreaching people for voting. That's a good observation. And also, I'm not the champion for sustainable software, but I'm involved in the Blower Angle for FOSS, and we will have a panel discussion. So if there are questions related to that, some of it may be overlapped with what Cornelius has proposed in the goal. Just wanted to announce that. Great. So if people are curious about the sustainable goal, then they can go to that. Thank you very much. Were we using GitLab when we were doing those previous votes? So if we were using GitHub for what? GitLab, because we used to use Fabricator. And I noticed it was a lot harder to keep up with pretty much everything after we moved to GitLab, because of all the e-mail spam that was uncategorized. So I wonder if like more people lost their e-mails within all the flow of GitLab e-mails or something. Yeah, that's something I... Lydia has an answer. Yeah, so the drafting of the goals just like in previous years happened on Fabricator. So we haven't moved to GitLab. Okay, thanks, Lydia. Anyone else? Any other questions? Okay, thank you very much.