All right, thank you so much for coming. This talk was originally supposed to be held by Nate Graham, who closed last year's Academy to a standing ovation, so that will be a tough act to follow. And unfortunately he couldn't make it to Academy this year, so a few days ago he reached out to me and asked me to substitute for him. And the material I'm about to put up is based on an exchange I had with him. So I'll try to be a faithful conduit to what he had in mind and what the team that had been working with him has been up to so far. So just like with Ivan's talk, this talk is supposed to give an update on another one of our three community goals. In 2017, at an Academy, we came up with this idea of electing community-wide goals that would allow us to tackle issues that span more than one project team. And get things done as a community again because at that time we felt we had fragmented a bit into teams that didn't work as closely with each other as they maybe had in the past. Privacy was one of the goals. Onboarding was the second goal and the third goal is usability and productivity. That was chosen in November 2017 in the first goal selection. And it was submitted by Nate and people from the KDE Visual Design Group, which is itself already a community spanning team that tries to tackle design issues and visual issues in our UI and maintains our seeming and that kind of thing. The Visual Design Group itself sort of is the successor to some previous initiatives we had in the community, like the HCI initiative and the KDE usability slash open usability group. I myself, my name is Ike, I work on Plasma and on KDE apps. So at various times I've been a participant in this goal. At other times I've been a benefactor from the things that all the amazing people who grouped around it have been doing. And in the past I was also part of the HCI initiative. The goal, like all the other goals, held a sprint that happened this year and was co-located with the Plasma sprint in Valencia, Spain. On that note, thank you so much for our sponsor SlimBook, for hosting us in their offices. And let's take a look at the goal in detail. So the goal set out to improve the usability and productivity of all KDE software. Those are complementary, they are not supposed to compromise each other. There was a strong belief that those can be tackled in tandem and can inform each other. On the usability side, we wanted to have better defaults across all KDE software. We wanted to improve the consistency of KDE software in terms of how it handles, how it looks, how things are done and the discoverability of all its functionality because most KDE software is very powerful but sometimes that power is quite buried in there and we wanted to surface it better. One of the ways to do that is to try to make things easy to understand with natural language instead of employing technical jargon. This is also an idea that sprang for us in parallel on the KDE promo group that was doing great work on cleaning up our websites and framing and presenting our software in more natural ways that allow people to understand what our software actually does at times. And we wanted to improve the ease of finding KDE software of installing it and of managing it on your system and allowing the user to do that with greater ease than before. On the productivity side, we wanted to retain all of the powerful functionality that KDE software has. We didn't want to remove any of the features to make things simpler or easier. The idea was that we want to surface that functionality and make it easier to use. One of those ways was to maintain and improve our keyboard shortcuts which is something that power users use to accomplish tasks faster. And that's a sort of metaphor for how we approach that. In general, keep features that allow power users who get very intimate and familiar with software to be able to accomplish their tasks with the same speed they're used to or faster. A while ago, the Plasma team specifically adopted a motto for Plasma called simple by default, powerful when needed. These two halves of this goal were chosen to sort of complement that and to be inspired by that motto where usability to us means we want it to be simple by default. It shouldn't be harder than it needs to be but at the same time it should retain its power and be powerful when needed so that the user can start using KDE software and find it very easy to engage with at the start and also as they get familiar with the software they should be able to become progressively more powerful using the software and have an easy time discovering the functionality and use it. So the approach that the team took to accomplish these goals was a very interactive one in terms of interacting with the audience around KDE software. Conscious emphasis was placed on fixing long-standing issues first. There was a perception in KDE's user community that sometimes reporting bugs was sort of pointless almost where things would be repeated by large groups of people but not tackled in that sort of order where users were screaming they had this kind of issue and that kind of issue that would fall into certain patterns but they wouldn't get addressed timely based on the popularity of those issues. So the first step was to index all the issues we have and sort of triage them by how long they had been around and how many users had been clamoring for sort of relief of those pain points. On the meta sort of level we wanted to make it very easy to get involved with this initiative. One of the other goals was onboarding. It's very complementary in the sense that to get this work done we needed new contributors and a lot of them so we worked very closely with the onboarding team to get new developers into KDE and get them to help us out. We did that by trying to standardize the build tools and the documentation on how you can build plasma or build KDE software locally on your system. We improved a lot of the Viki pages to make it easier and made some hard decisions on what is our preferred way of installing a development session and helping out. And then we wanted to communicate our progress so people could keep track of what we're doing and feel good about it and make sure that the world knows that this is happening and that we take the concerns that the user audience had seriously. So we started a weekly blog series helped by Nate who collated all the work being done by the initiative and would write a weekly blog post listing all the things showing screenshots of the things that had been improved often contributed by the people who had made the fixes themselves and it became very rewarding I think for the team to sort of document their progress and it certainly helped with motivation and keeping the momentum up. Now let's talk about the results. We've been doing this for slightly over a year almost sort of 18 months. In that time we have relieved many major pain points that had been long standing that people had been complaining about. A lot of effort was placed into improving Plasma Discover. Plasma Discover is the software center that is part of a KDE system. This harkens back to the earlier point about making it easy to find and manage KDE software on your system. This covers the way to do that and we put a lot of effort into improving its user interface also improving its reliability making sure it never crashes as little as possible and making it faster improving the way it presents software search results improving the way it presents search results and updates that are available and a lot of that work on Discover actually ended up affecting other applications. Discover uses one of KDE's newer technologies which is the Kirigami user interface toolkit which is based on Qt Quick and QML which Lars talked about earlier and fixing Discover meant going lower in the stack and improving that library a lot which in turn helped other applications also built on the same stack. Another part of a KDE system is the Balu file indexing service which is powering our search and certain advantages like tagging and saved searches all across KDE's file manager and file dialogues. Balu also had some long-standing reliability issues that was another area of strong focus to finally get rid of those and good progress was made there. Another problem that lots of users encountered was inconsistent behavior with their input devices where certain mice wouldn't or trackpads wouldn't operate as expected. One of the reasons for that is that on the Linux desktop until recently we had to sort of separate input stacks and depending on which device you used different stacks would be in use and we made the decision to default to the lib input stack which is the new of the two and by upstream intended to be the replacement for the old stuff. We wanted to get on board with that and we wanted to switch to lib input as well consistently which meant a lot of work on our settings UI and stuff related to input devices to make the newer generation of input stack just as complete as the old one was so that we could then retire the old one. That was driven to completion essentially. Currently we have full lib input support and expose essentially all of the settings it offers. And still in progress are improved UI and workflows around SAMBA file sharing which is how Linux systems access sort of Windows based servers and also Linux based file sharing servers a lot of the time. Users had performance problems, ease of use problems with file shares, we've worked on that and also multi-screen. Multi-screen was a big pain point for many years throughout Plasma 4 but also Plasma 5 where in a setting like this people had trouble connecting projectors conveniently or when they docked their laptop at work they wouldn't remember the screen well and things would jumble and jump around. A lot of progress was made on fixing that and then we come to the consistency improvements This was I think a good third of the work done over the last 18 months where we went into tons of apps and the Plasma shell and reworked the default settings. Often this meant just sort of reflecting the status quo on how KD Software was actually deployed to users. As we are an upstream we work with downstreams with Linux distributions who are in some cases more directly user facing than we are and the distributions get a lot of the feedback from the users on how users actually prefer to use the system and often distributions would then ship different default settings from the upstream ones and a lot of this work was looking at what had users demanded from distributions and what was actually popular out there and getting better metrics on how users like to use KDE Software and then adopting those things as more reasonable defaults to ease the maintenance burden on the distributions but also, for example, to help developers because now when you install a Plasma-based development system you get the same settings that users actually use and get closer to the user and better able to understand their needs. System settings, which is the application that you use in the KDE Plasma system to manage your system settings obviously, but also peripherals, file sharing all these kinds of things was cleaned up. We simplified a lot of the partly very old UIs that go back straight to KDE 2. We gave them a visual overhaul. We made them a lot more consistent in many places a lot simpler without losing any of the functionality just by adapting more modern UI patterns and porting them to newer UI components we had in the stack. One of the more controversial, perhaps, efforts was aligning the shell and the apps more closely. Back when Plasma started in the KDE for days back then a very conscious decision was made that shell and apps should have separate steaming systems and separate looks.  We felt that that decision was at the time to force by the technology where for the Plasma shell we had a different vector-based steaming system from widgets for the applications. As QML and Qt Quick become more popular technologies for applications to use and as Plasma 5 rolled out the Bree style which was much more simple to implement in Qt Quick we finally had the sort of technological requirements to have consistent visuals again between the shell and the apps and use the same steaming throughout. This has been, I think, very well received by users so I think it was the right thing to do and I'm very happy that the team worked on that. And altogether hundreds, if not thousands of bug fixes were made both in the Plasma shell but also all across the applications and many sort of awkward workflows were cleaned up or improved. For example, as you get the notification what you can do with that notification what apps you can directly open from the notification or what actions you can take has been approved considerably or use spectacle to take a screenshot be able to jump into all sorts of apps or sharing workflows from there these kinds of things which is exactly what we wanted to accomplish with this goal instead of tackling something specific to one application or specific to the shell we want to make improvements all across KDE Software and all of this work I think has had a huge impact on the KDE community but also on KDE's relations to its user and developer audience. Before this goal came around if you went into online discourse on KDE and Plasma frankly it was sometimes quite negative. Sort of the general tenor was I really like this there's stability problems I ran into bugs quickly the default settings were not that great and it took me a lot of time to figure out how to change them This has spun around tremendously where these days if you jump in there you either see lots of love for us or at least people have perception of great forward momentum and they enjoy following what we put out there these days in general we are perceived as stable and nimble during the KDE 4 days we got a lot of criticism for our performance not just this goal but all of the community pulled together to improve our performance for example startup speed Alish will give a talk later on Plasma startup speed and the work done there so generally these days users perceive as a stable and performant people also enjoy using this cover much more which is very important because it allows us to surface KDE software to users much more efficiently than before so in general I think the audience now has the feeling that KDE is moving again and moving at greater pace than before communicating regularly with the audience is very important in that sense and it has helped a lot but personally I think the greatest accomplishment of the goal and Nate in particular and I want to really thank him what he has done there is that he has really a great new group of contributors around this goal and by extension around the KDE community when I went to the Plasma sprint in June that I mentioned earlier as a Plasma developer there were many new faces there for many people there it was the first KDE event ever and immediately it felt like they had always been there which is amazing and it's been just fantastic to see new people pour in do really great work grow really fast and extend the team and the best thing is that all of these new contributors just like this goal they work across the whole community these are not contributors that have been attracted to work on a particular app they are contributors who feel like they own all of the apps and improve all of them so I think in that sense the goals have definitely accomplished what we set out to do when we came up with this we wanted to work all across the community again we wanted to have new contributors who identify with the KDE community in that way and that has definitely come to pass with this goal it's been wonderful and along those lines choosing complementary goals I think can be very powerful in this case the usability and productivity goal was very strongly aligned with the onboarding goal and they certainly informed each other onboarding by itself as NeoFutures will certainly talk about more I think had as its goal to improve our developer onboarding and our documentation which we really needed for our goals and the usability and productivity goal and yeah we did that together and it worked so that's great alright that's all I got Any questions? Thanks for your presentation in the beginning you mentioned that the first step for the goal was to gather user feedback also when I read the blog post of N8 I saw many new names many contributors that at least at me looked new what's the primary platform that this contributor came from web platform or something I think interestingly the way we got contributors this time is not that different from the ways we got contributors in the past and I think it shows that we just need to keep going and always do new things namely I think N8's blog post got a lot of new people involved in the past in the KDE community we had something very similar called the KDE Comet Digest which was a weekly publication of ongoings on the developer side and I myself around 2005 became a KDE contributor because I was reading that and I was excited by it and I wanted to be one of the cool people so I think the lesson is that blogging really helps for any project for the community as a whole but also for teams if you show your forward progress and you show your momentum and you show that you have cool things going on then people want to get involved with that that's very important and your futures I think is agreeing so I think that was a big reason I think another development in the community has been a switch to new communication media Ironically I think the academy conference indirectly spawned that because many years ago for an academy somebody opened a telegram channel to allow people to communicate more easily with their mobiles at the conference and from that developed the fact that our communication in the community initially fragmented between our old chat media IRC and telegram and a lot of the new contributors came in via telegram this was a whole audience that sort of got in bed with open source there and hadn't been in touch with KDE before but as we started using telegram more we were able to connect with them that's sort of a good thing and a bad thing because telegram doesn't sort of satisfy all of our requirements on the open source side so we rolled out matrix and bridging things and see where this is going but clearly we cannot sort of block progress in that direction in terms of communication media we need to go where the developers are and if telegram is popular then we should be on telegram to get them and I think that worked Just to corroborate this statement and we have for years the KDE Brazil channel is like average 20-25 persons last year we just bridged and made telegram we are over 300 in KDE Brazil channel more than 300 inside the KDE Brazil development and then Q2 Brazil is over there just because in one year so it's amazing there ok so as we lack in time so you can ask in person do I any time thank you