 Did you know that KDE has goals, like not just goals in general, like formal written goals to achieve? And if you didn't know the goals are these three currently they change, I'll get into that. KDE is all about apps, wayland and consistency. So what are goals in general? Well, first of all, goals are selected every two through three years. And they are just areas of improvements where KDE thinks it has to work on in general. How this works in practice is that there is a proposal where literally everybody can propose a goal for KDE and then there is an internal voting and everybody can choose which goal they think is more appropriate for KDE and the winners do get selected. What does that mean? Well, formally, it's not like anybody gets hired to work on this. The role currently KDE is mostly based on volunteers and it has no employees that actually do development. But what that means is that you get a lot of support from the AV and the community to actually bring your goals forward. Let me make you a little example. If you're a goal, you do get some budget to actually spend on. It's not that much. You cannot hire anybody with it, but it is useful to some extent. I think it has never been actually used because of how KDE works, but you do have it. You do have that option. You also get hold the infrastructure of KDE so you can create your own work boards, work boards, wiki pages, chat rooms, everything. And you do get the promotion group actually telling everybody what you're working on. So it's actually pretty useful. Even though it's meant internally to try to convince people to actually work on these things because you don't have to. The fact that consistency as an example actually got selected doesn't mean that anybody should say, oh yeah, it got selected, so I'm just going to do whatever I can to do that. You have to convince even the developer to actually work on these things. Which is why giving an example of how to work on these things is so important if you're a goalkeeper. And goalkeepers are the people that actually bring these goals forward, are the people that propose them. And I am the goalkeeper of the consistency goal. I was actually, my goal was selected, not me. And this is how I joined KDE mostly. I had done some merge requests, but when my goal was selected and I got the KDE in touch for me to actually help me get started in the KDE world, that helped a lot. Which is, by the way, why I'm not going to propose any goal for the next round of goals? Because I do think that it's a very good opportunity for new people to come in and get started in KDE. So, when are the new goals coming soon? Actually this year. And what goals, let's do a bit of speculation. We'll have time to see how consistency wayland went in these years. But I think we're more interested in what's coming next. And to do that, let's actually do a jump in the past and see what other goals were proposed when these three were actually selected. So this is the page with all of the goals that were proposed. These are the selected ones. Let me actually quickly go through them. This one is the consistency one, which I've written, as I've said. And I think one of the reasons why it got selected, in my opinion, is that it's super long. Like I had some very specific idea. There were people that were actually interested in what I was saying. And I was very specific on what I wanted. Mostly I was like, okay, if we take all of the KDE apps and we put them side by side, they don't match. Like the visual elements don't match up. So this is sidebar. So as an example, this sidebar is different from this one, which is different from this one, which is different from this one, which is different from this one. They all have different sidebars. This is another kind of sidebar, which is different. But again, it looks different for each application. And then we have the hamburger menu. Some apps do have hamburger menu. Some apps don't. That was, that is inconsistent. We also get tabs. Tabs have completely different styles, depending on what app you're using. And so on. Even like the find box was completely different is completely different, depending on the application. Now, these issues, sorry, are super hard to actually address. And I can only say me and the rest of the VDG and other developers did surely our best to address this. And to be honest, there was a lot of improvement. Maybe not on these very things that I initially thought were going to be the most important tasks, but actually other steps that I realized later were much more important. Like the general style of a window. This is the title bar that we had back then. And if we just looked at applets, we do have a top area in applets that actually completely different from this top bar. I mean, just look at them. Now, with as part as the consistency goal, the header bar is absolutely consistent. They use the same color. They use the same shade of gray because they're actually kind of the same component, kind of. There's always some little implementation catches. But still, that was a great improvement. And even if not everything that was listed here was done or almost nothing of this list, the goal actually achieved a lot. Because this is not the most important things is what I realized when I actually started working on them. Then we also have stuff like scrolling is inconsistent, which is currently very worked upon and likely getting some nice smooth scrolling on all apps is not that simple due to UQT not having it implemented perfectly, let's say, but they did implement it recently. So there's a step towards that. Also, I talked about the fact a lot, the fact that all web pages of apps are very inconsistent in where they're placed. Some apps are in the main website. Some are external websites. Some are on wiki. It's rather confusing. And so on. I've talked about redundancy in apps. Like if you have like Latidock and Plasma panels, I was like, why don't you just merge the project? Or I don't know, Kate and K-Write. Why don't you just make a single product? This turned out to be much more complex than I initially thought because everything is more complex than we initially think. There has been some steps, I think, in this direction. But most of these projects are different. And there's, of course, a reason why they're different. So you cannot just come and say, let's make them the same application that will work out, right? Not quite. And of course, we had a super long discussion, like super long discussion about this. Then there is the Wayland one, which is, I mean, not as long because it's rather obvious. Like we need KD Plasma, KD in general, to work on Wayland. That was what was said back then. It was discussed how to actually implement it. You can see that the task is much, much shorter, much less controversial in how to actually implement this. There has been huge steps forward for this one. And KD is all about apps was initially proposed by Jonathan Riddo. And then he actually stepped back. And the goalkeeper for this goal is currently Alekspo. And this is about improving the ecosystem of KDE. Because KDE, you probably think it's the desktop, but it's not. KDE does not stand for the K desktop environment anymore. That's not it. The desktop is called Plasma, Plasma Desktop. And KDE is the community that does software. And something that KDE does is apps. And this goal is we need to tell people that our apps are apps that you can use anywhere. Even outside of KDE Plasma Desktop, obviously even on Windows, even on Macintosh, Android, Flata, Snaps, everywhere, we need to make sure that people know that KDE is about apps. So these are the selected goals. What about the goals that didn't quite make it? So one goal that I was 100% sure was going to be selected. I think it's gotta be like the fourth one is this one. Plasma on touch screen devices, especially because if we see how many people were actually willing to put working into this, we've got a lot of people, myself included. I love touch screens, I just do. And in general, this is I think also proposed by somebody who hadn't like a very long story of contribution to KDE. Yeah, I think they joined KDE to propose this. So yeah, and it's mostly about, you know, making sure that KDE Plasma in general actually works on touch screen devices, which could be two in once with a tablet like the touching screens or keyboards, depending on how you see it, or even touch screen just like this. And there was a lot of discussion on how to actually implement this. Even though it was not selected as a goal, doesn't mean that people didn't work on this. And there was a lot of work on actually improving the situation on touch screens. And now with Plasma 5.25 tablet mode got so much better, it will even get better in Plasma 5.26, stuff is coming. And the newer apps done in Kuri Gami have much, much improved the touch screen abilities. And now with the Plasma Mobile project being super developed, a lot of apps that are meant for touch screen user usage on Plasma Mobile are also usable flawlessly on the desktop as well. So a lot of step forward on this one. Another very interesting one, which initially I thought it's not really necessary, but nowadays I think it should have been selected probably is the KDE for big enterprises. Because we do need, we do need, if we want KDE Plasma, this was actually authored by a longer time developer, David Edmondson. And if we want KDE as a whole to succeed and we do like the people who work on KDE do want this, generally speaking, we do want enterprises, companies to actually use this software and to actually reach that, you do need, it's a different use case compared to everyday users. If you're a company, you do require certain features that maybe the general user just doesn't care about. I'll make you a quick example to add on this one. Accessibility on KDE Plasma is not really good. And when it comes to KDE Plasma being used in public institutions, for example, accessibility is super important. And it's one of the reasons why KDE Plasma isn't, or KDE in general, software isn't as used as could be. This explains other things like password expiry support, network printer settings, blah, blah, blah. You can actually go through this. It's rather interesting. It's not my area of competence in any way, so refer to this one. We do have related a goal for accessibility, another one that probably after three years of being part of KDE, I think is much more important than I initially thought, even though it's not something I'm expert on at all, because again, back then I didn't think it was important to actually get this kind of skills. And this is, as an example, keyboard navigation, focus handling, screen reader, magnification zoom, which I use a lot actually to be able to see parts of the UI when I'm debugging, but other people have even more important use cases. And adding accessibility to HIG, which I think was actually achieved, yes. So we do have this again. It was not selected, but that doesn't mean that people won't work on this. What else? Reorganize the KDE ecosystem, which is an interesting task, but the feasibility is all about how you actually want to implement this. In general, we have this KDE works, blah, blah, blah. KDE should precisely define the core structure which platforms are needed, how they are connected, how transition will be done from today's date, who we work on, what. As much as this is super interesting as a task, it's so hard to actually achieve something like this. KDE from the inside does not feel as organized as this task make it seem to be, if it wants to, well, I guess that is why it's called Reorganize, but we have provide software solution for consumer devices, which is actually getting KDE KDE Plasma in laptops, phones, which is again something that happened a lot, even though this goal wasn't selected. And here it talks about documenting the technologies to make it easier for device vendors to use them, involve KDE community to work on their apps for non desktop devices. So a little bit about the Plasma Mobile and Plasma Mobile applications project, et cetera, et cetera. In general, this has achieved something really nice. As an example, the relationship of KDE and Pine, which does a lot of very cool Linux hardware is really nice. And in general, all Linux vendors include KDE Plasma at least as an option. We collaborate with many of them. There's the slim book, I think it's called. Right now I don't remember, which is actually sold in partnership with KDE. So this was actually improved. Of course, we could always use some more Linux KDE out of the box hardware, but you know, this is a step forward. We did a step forward compared to when it was proposed. At least that is my impression. This is interesting. I probably would not, probably don't quite agree with this, but it's an interesting take. This is feeling of freedom out of the box. I also think this was authored by a newcomer to the KDE community. And it's tough like, okay, out of the box, you have like, I mean, not out of the box really, but if you have Linux out of the box or you install Linux on a machine, as soon as you start using, so in that sense, out of the box, you should feel it's freedom. That is, you should be able to tinker with it. And not only should you be able to, but the software needs to try to convince you to actually tinker with itself. What this means is that this should like, add, create and edit buttons to everything and tell the users how internal US subsystems are possible or improving documentation. So actually linking the source of any application directly from the app store, stuff like this. I personally think this is not a good idea because most people are just not interested in actually starting tinkering with everything and they have the right to do so. They have the right of just trying to use something because it works without having to mess it up to achieve something better probably, but they need to get work done. And it is cool that you can edit the source code if you want, but it has to be if you want. And I don't think the software should try to convince you to actually please edit the source code. There's no need to. Somebody who wants to do that will have the chance to and that's what matters the most in open source, free and open source communities. There's more. There's a better localization, another important but not very often cited task. And then these were not actually voted upon at all. Improving the personal information managers who like contact the KD calendar situation. This is the, I'm gonna say old KD PIM. It's not really, it's old in the sense that there are some new apps that are slowly doing the same things as the old ones in some aspects like calendar does cover a lot of things that contact does. But of course, most of the features of the KD personal information manager has a whole product are not yet covered by anything else. And I personally feel like it's not maintained enough to be a quality product. So I understand task. We've got better tiling, KD prioritizing privacy. And though this sounds like a really cool goal, it was actually the goal that was just ended. When we started voting on these goals, the previous goal was privacy. So it was a bit redundant. And then we had this one, which is super important, which is the goal template, which we all copy pasted to actually get our goal proposals. So why did I go through all of the goals that were proposed? Because I expect at least 75% of these goals to be proposed again very soon. And why don't you join like everybody can propose goals? I mean, everybody could propose goals the last time. So I have no reasons to think that you shouldn't be able to in the next time, maybe with some restrictions. I don't know, there weren't last time. So if you're interested in giving, like trying to give KD what is your impression of what should be worked upon on KD, keep in mind that goals should be super broad. Like anything, they should cover the entirety of KD. Like improving KD Plasma desktop or I don't know, fixing bugs of the KDE PIM. This is not going to fit as a goal because it does not cover the entirety of KDE. If we choose improve KDE PIM as a goal, all other projects are going to be left without a goal and that's not good. So that should be avoided. Stuff like all of this that you do see actually cover the entirety of KDE. So if you think that you have an idea for the entirety of KDE that you think is feasible, then start trial, if you want, if you want, you can start trying to write a formal proposal, which I mean, it could be super long. It surely worked for me. It doesn't have to. But if you go into details on how you would get this implemented, the more detailed you are on how to get it done, I think the better it is for you to actually get accepted. I think it's better to have a structure if you're voting something because you have an idea on what will happen. And of course, if you do so, you also take a bit of the responsibility of actually getting it done if it is selected. So to end this super long video about the KDE goals, let me actually emphasize something because you, I can actually go over the donation. Okay, let me emphasize the fact that even though I do take donations and I talk about KDE Plasma, KDE in general, this channel, sorry, is not part of KDE. This is my personal channel. Sometimes I'd like to talk about something else entirely, you know, poetry, something else. And the donations that you do, the links that you currently see and the donations that the patron do are to me and my projects that not necessarily are the exact same ones as KDE as a whole and just one person. If you want to donate to KDE, that's easy. Let me show you. This is the KDE.org webpage. There is a button called donate. You just click that, done. But if you want to donate to me, and of course the animation started again, sorry about that, then you can use the links in the video description. You've got the choice. So see you tomorrow.