 All right, we will spend some more time talking about the previous goals and then towards the end of this panel we will reveal the new ones. So one of the things that was really surprising to me when it started was that two of our three goals were suggested by very new people, people who hadn't done a lot of things in our community before. But who brought so much energy and drive and new ideas into this. Do we maybe want to talk a bit about that? How about you, Nier Fritz, do you want to start as one of those people? So yeah, for me, as I mentioned last year it was an amazing experience, like coming to GD, I was around I think like two to three months, maybe six, I don't know. But it was very early for me, I joined via the promo team and first of all being able to feel that it's like it's okay for me to suggest the goal to the community was a major factor for me getting more involved. I felt welcomed, I felt like the people were willing to listen what I had to say as a newcomer and I urge you guys, if you're newcomers here to do the same, don't be afraid to speak out about what you think. And for me it's been an amazing experience, it helped me learn a lot and hopefully do a lot for KD through the goals initiative. So yeah, I think that's an amazing part of this community, that newcomers can have an impact and have an impact very early on. I also think that it sometimes helps to have an outside perspective and the goals I think is a pathway for outside perspectives to be invited into the KD community and bring that to us and for existing contributors to rally around an outside perspective. Sometimes if you're external you have a better overview on what can be wrong with the whole organization or not necessarily wrong but just in potential of improvement, right? Because sometimes we are in the sick of it and we get used to our ways of doing things and then we don't innovate and iterate them any further. But if somebody new comes in who can see this is inefficient, this should be done differently then the goals offer them a way to immediately get sort of cloud and the team behind them and improve those ways. I always think that one of the most beautiful things about the KD community and one of our greatest successes is that KD is so multi-generational where not only do we get successive new generations of contributors involved, we also tend to retain the old ones and have them work side by side as I think you have photo captured really beautifully. And we've always done that really well with technical maintainership where for example I got into KDE around 2005. The initial sort of projects I made my name with were not projects I myself started. I took them over from previous people and to me it was really great that that was possible, like the old generation of developer was not so entrenched that a new one couldn't take over rather on the contrary they encouraged and supported that. And now I think the goals allow us to do that not just on the technical level but also on the sort of meta level about improving the organization, improving the community. So I think that's been really great. I agree with both of them. All right, so looking back from today to before the goals started, what would you have like to know to make your life easier? What would you have done maybe differently to make your life easier? I think, do you want to go first? Well, at least for me coming as a newcomer, I had no idea how complex the whole KDE community was and its projects, it's like huge. I still don't know in all of the people, I still don't know many of the projects, I still don't know what the things we are working on are. So I'm still trying to figure out my head around that. So it would be good to have, I don't know how could that be improved. The mentoring of people actually helped a lot like Lydia, Ike, Alej and other people were very close to me and helped me and supported me through this process. So what I wish I knew at least then, what I would have done differently is probably try and hopefully we can do better this time with a new round of goals is to not be alone in terms of courting the whole process and pushing for that. I think having teams formed around the goals and having more people involved on a higher level and trying to push for them will do wonders to our goals. Because it can get busy, it can get frustrating, it can get like lonely, so having teams working on that will be a big improvement I think. I think, so my perspective is a little bit external because I participated in a goal but I'm not made. But I had the feeling that all of the goals had their first sprint relatively late after the election. I want to ask you, do you think it would have helped your goal if the sprint had been sooner in that process to galvanize the team more early on? Would that have helped, do you think? It probably would at the same time to me. It gave me some time to try to think of what has been done and what hasn't and where we need to put much more effort in. Because as I mentioned earlier, there were only a couple of major tasks that we didn't manage to close in these two, three years. But yeah, maybe on the other hand it will really help to have the sprint held here earlier, maybe have a second sprint later based on that in order to help with the whole team building as I mentioned earlier. So yeah, that's a good idea going forward. I think, I'm so sorry. One thing that just blasted through my mind that you couldn't have known at the time because it happened after the election is that in the last year, our income situation, as you will hear later in the financial working group report, improved a lot of our annual income quadrupled essentially. And we made the decision to give the goals a budget to work with, which wasn't true at the time they got elected. So yeah, I think the next set of goals can start from that safe assumption that they have money to work with, that they can put to good use towards their goal. So considering that goals are like normal KD projects, I do agree that we need to have much more sprints than we used to. In essence for the privacy sprint, which was amazing, but it was quite late in the goal game. And people who appeared, we didn't really have a focused goal that we were going to do on the private sprint. Everybody worked on their own privacy project, related projects. Some even invented that their projects were privacy related. If we had an early sprint where we could, let's say, agree on some specific focus points, then all the later sprints would be much more, I wouldn't say productive. The sprint was productive, but it would be more tangible to say, okay, we did this for the goal and not because our project needed it. Those are all very good points. One last question from me, and then we can go to some audience questions, was all of you alluded in your talks to still work being left to be done. What's the one thing that's most important still to do for each of the goals? Well, for me, I think the thing that needs the most work and it's very important is the setting up of a development environment story. I mean, I think we can do much better in terms of making it much easier to people. We have the solutions, we need to work on them and make that possible. So hopefully we can continue with that, maybe with another sprinter in the future, work on that, and try to have some solution. I'll say that for the start. And of course the website, those are the major two for me. Well, I think the biggest challenge is to keep the momentum up and keep going. As I mentioned on one of the slides, some of those user pain points are still not fully relieved. There is still work in progress there that will continue. I think Nate not being here will take the opportunity to say that we need to help Nate scale. He has been fantastic at leading his goal that he submitted and looking after it and communicating its progress to the world. Now, I think that's a huge overhead on his shoulders. And I think we should take the opportunity now to see why has the goal worked so well and formalize some of those processes and make sure they're not just on his shoulders. For example, maybe we should resurrect the KD comet digest so that Nate doesn't have to log all the things by himself. That could be one way to go. Anything? So for the privacy goal, the main thing that would be for all of you to spread the word that privacy and security are extremely hard. From the simplest things to the really, really complex stuff. One of the things that I just wanted to mention, we obviously are trying to do our best always. But you should ask yourselves who has implemented the cryptography, who has implemented various different things in the projects that you're using. I've seen several projects, I'm not going to mention any names. I'm not, I'm a layman in cryptography and I've seen problems. So all the developers should know what they're doing. And if you're doing something as important as cryptography and privacy are, you need to learn a lot of stuff. Thank you. All right, let's go to some audience questions. Do you have questions? No questions? So there's one question I have in regards to organization. I think there was from the beginning always a point person for every goal, right? So I don't know in privacy, I think the point person changed at one point or something like that. For the new goals, is it clear that if the point person is not available, how the process will be, I think for, it wasn't such a smooth transition in the privacy goal for some time, it wasn't continuing until you took over. So do we know how we would, in the future, we would act in such a situation? I at least don't have the perfect plan yet, but it's definitely something we need to figure out. There's a BoF I scheduled, I think for Monday, where I think this should be one of the things we talk about. In essence, as I said, the goals should be normal KD projects. In normal KD projects, when the maintainer disappears, nothing happens. Somebody takes over. The problem with goals is that we are not, we don't consider them to be a normal project where that thing can happen. In essence, I hate the fact that there is a point to person. It should be a mailing list, it's a normal project. If, I don't know, if Peter Peterson is not present, somebody else should reply. So a goal should not be dependent on a single person, ever. I'm not technically a question, but just onboarding stuff and all the goals that made my life as a developer a lot easier. So now when you have some random new person, I'll see if they have a question and they want to get involved, there's now something you can point them to. Go on this wiki page, it has all the information you need. And also a little story about new contributors getting them involved is very important. At some point you get, we call it in German, bedriebsplend, it stops seeing issues or you get so used to that one thing being broken that you avoid it. And then there's this new person, so they said it couldn't be done and he didn't know it, so he did it and it worked. So that's very important to keep the spirit in and get new people involved. They just do things, you knew it could be done this way, but it didn't because you know it's probably not ideal, but then it turns out it is. And then you figure out it's amazing, so it's very important to get new people in. Hi, I think one of the most important things regarding onboarding and stuff is that when you join a project and you think how can I contribute and most people here will contribute by writing code. But if you contribute by trying to bring more people in, it has a multiplier effect instead of an additive effect. And say for example you're a busy maintainer of a project, you do it only in your spare time and you're thinking I want to do this and this and this, so I want these bugs to be fixed. One of the ways that you can actually get that done is to get other people to do it and how can you do it and obviously we've all touched upon it, documentation, pointing to people how to build your project, how to run your project and stuff like that is really important and I think that's one of the main benefits of the goals that we've seen over the past couple of years. I don't like being, well I don't like being a pessimist, but so your idea is amazing. The problem is that a lot of us are good at writing code and bad at everything related to communicating with other people. So while I completely agree the best way to do something is by giving it to others, sometimes you don't know how. I think one of the reasons it's so hard for us is not actually because we're all that bad at communicating. I think people in our community or engineers in general have a hard time quantifying their productivity in other ways than writing code. If you're doing code with you, if you're helping somebody out, you don't feel as productive as if you just fixed 10 bucks and I think we can build a social etiquette around realizing that if you're doing those kinds of things you're also being productive and reward that. Because I do agree with you that one of the most important functions of a project maintainer is to enable the work of others, not just to be the lead coder or just to say no to things, but rather make it easier for other people to write code in your project that's an important part of being a maintainer and we should recognize that and also celebrate that. One of the ways we do that is at this conference with the Academy Awards. I think we should just have more of that. So to that, I have an open offer to all developers. If you have notes, if you have a fabricator spring, anything that you think could possibly make a good blog post, send it to me. I'll make it into a blog post. You can publish it under your name. Don't even have to mention me. I mean, we just need more great blog posts than invite more people in. Have you just invented blogs as a service? Valerie at KDE.org and it really is open to any developer. A Google Doc is even easier, but... All right. Do you have more things you would like to talk about from your side? All right. I thought so. Shall we move on to the revelatory moment? Go for it. So, as you know, new goals had been proposed and voted on and are now selected. And the three new goals that we have are consistency, Wayland and all about the apps to go a bit more into those. So consistency. This was about making all our applications, settings, websites, everything our users see more consistent and more harmonious. And you can kind of see it as a continuation of Nate's work and everyone around him. Then the Wayland goal is an enabler for a lot of things to come, right? Some of the other candidates, for example, will need us to support Wayland before we can really make good progress on them, like the touchscreen support, the input methods one and also moving towards more hybrid devices and things like that. So it's really an enabler in keeping up with the technology that is ahead of us. And last but not least, we had the all about the apps, which is really over the past year, we've spent a lot of focus, and we should, on promoting Plasma and everything around it. But we also have a lot of rock stars in our apps and making them more visible, much more easier to get, much more easier to install on Linux, on Windows, on Mac, and so on is something we should spend time on according to our community. Yeah. So let's get more consistent, shiny apps into the hands of our users. Are the people who propose those goals in the room? Yeah. Jonathan? Yes. Can you come here and say a few words about your goals? This is your moment to shine. Hopefully it's a multi-year moment to shine. Indeed. This is how the goal ends. Well, thank you for selecting all about the apps as one of the goals for the next couple of years. I'm awfully scared. I have no idea how to do this. We have many fabulous applications. We have many interesting and worthy applications, stuff like games that are not world-class, but they're still great, and they deserve to be promoted. Until recently, we didn't even have a website that listed all our apps with an up-to-date list of applications. They deserve to be easy for users to get. We've been pretty slow in embracing modern methods for distributing our software for people to be able to get it directly. That means new responsibilities, right? That means new integration between application developers and finishing that last step of getting it out, but also making sure that it's maintained, secure, reliable, and deprecated, that when it comes unmaintained, we have a way to mark it unmaintained, and we don't have that at the moment. It opens new possibilities, like new business models. Creators have been able to hire developers because they've embraced modern ways of people getting software, but pretty much nothing else has done that, and I think that's a real missed opportunity. But I have no idea how to organize this. I mean, hopefully we can have a bath and make a start in discussing it. Because there's a lot of work to be done and a lot of potential that we can grow on. So I'm very new to the KDE community. This is my first time in a year. So I surely need some help to organize, and if you have any suggestions or anything, just write it and it really should be our community work. And from what you see, from my point of view, I think that the important thing is that there are for the consistency goal, small goals and bigger goals inside it, where the small goals are small, like changing buttons, alignments, or small visual adjustments that should be found in the first place. So finding inconsistency should be the first thing that the people should do, and you don't even need much technical knowledge to do that, so everybody should be able to do it. And then there's fixing the small goals, and then the consistency goal was about bigger goals such as using a single panel, instead of having both panels and a ladder dock, that is an example. But to be consistent from that point of view, which is obviously way more bigger goals, so it should rely on very experts and a lot of organization. I'm Nicola Venerandi, aka Vigero. I'm Jonathan Riddle. Well, once again, I'll be substituting for somebody else and reap all the glory. No, so the third goal was Wayland. Wayland is a next-gen tech we use to handle input and output, putting things on screen, getting input from input devices. We've been working towards adopting Wayland in Plasma and in KDE Software and Upstream and Qt for that matter for several years at this point. We've made good progress, we have adventurous users using it. We need a big final push to get it over the finish line and make it the best way to use KDE Software. I think this goal is a really neat choice because it's a good example of a complementary goal. If we adopt Wayland, if we make it production ready, it will bring improvements to privacy. Wayland has a much better security concept than the predecessor technologies. It will also help relieve some of the pain points I mentioned in the earlier talk about usability and productivity. Wayland allows us to do multi-screen even better, for example. In many ways, there's also a continuation of previous goals, just with a little bit of a different focus that is sorely needed to get this done. I'm very happy that it got chosen. I look forward to participating in it and then helping drive it forward over the next years. All right, thank you so much. And yes, if you want to talk about these goals, about the goals, processes and so on, please come to the booth. I think I scheduled it for Monday. Quentin Wayland booths all through Wednesday morning. There you go. All right, thank you so much.