Stepping down as maintainer

Hi all, After long consideration I decided that I am no longer in a position to be a maintainer. I currently do not follow up on reviews and hardly contribute any code. Given that I think it's time to pass on the torch. KWin is currently in a good position we have new developers working on various areas of KWin and my suggestion would be to split the task of maintainership on many shoulders, specialized for various areas. My lack of work lately was not just the lack of time, but to a larger degree a lack of motivation. I searched a lot for the reasons for the lack of motivation and I think I identified two core areas where KDE is currently heading to and where I just disagree with these directions. Please don't take my explanation personal, you are doing awesome work, it's just that I don't approve these directions. Lately I had a feeling of doing fundamental opposition to changes the community wants to do. Granted I think these changes are wrong, but I don't want to stand in the way, if that's what the people doing the work want. What I identified as the core issues is the way the VDG currently acts and the usability project. With the VDG I currently see the following problems: * tendency to do changes and reverting them again * taking easy solutions like flipping defaults without looking at the big picture * tries to dictate much more than just visual or design * does not consult domain experts * presents final solution and disallows discussion as you were not part of the telegram discussion As examples I take the discussion around the change of lock screen wallpaper and the window decoration no border setting. In both cases the VDG identified a problem, which is great. But also presented the solution. In both cases the technical solution is bad and results in losing functionality. It takes a hard fight to convince the VDG that their solution is wrong and that something better is required. In the case of the lockscreen we succeeded. The new implementation is awesome, a clear improvement over the blue background and also over the one we had before. But if we would have taken the approach the VDG did without opposing and fighting we would have ended with a solution worse to the one we had before the blue background. To me this is a dangerous development. I don't want to have to fight for good solutions. That costs a lot of power and is not healthy for the community. My wish to the VDG would be to take a step back again and not trying to find the technical solution to the problems you identify. Please approach the developer community with "hey, we think this area is bad, we want to have these improvements, how can we achieve it?" What I also think is important is that you realize that changing a default is a technical solution. It's not just design. Ask the experts whether that is the right solution to your problem and don't dismiss their opinion based on "it's just design". Similar the no border discussion highlights some of these problems. While it sounds like a minor thing, it is not. We see the fundamental problems: domain experts are not consulted, if they chime in they are told that they have no saying in it as they were not part of the discussion. Changing the default has more consequences than just a visual one. I told that and nobody is listening. We are going the easy road of flipping defaults without thinking of the big picture or finding good solutions. This is not what we used to strive for in KDE. We used to operate on highest technical level trying to bring the best solutions. This is clearly not form follows function. We are removing function in the sake of form. A dangerous development. To get one thing clear: I don't care about whether no border or normal is the default, I'm not personal attached to this. What I care about is that we get the best solution for the users. And I am sure that changing this default will have negative impact. And that is sad. The second area where I really dislike the development KDE is taking is the usability project. I have a feeling currently everything is done in the sake of usability. We are losing the big picture, we are no longer doing product development. We don't try to improve the product and take it to the next level instead a thousand of minor things are added in the sake of usability. We ignore that every checkbox or option added decreases the usability for everybody else, we ignore the costs to maintain the code due to the changes. I remember that people like Björn, Kevin and Thomas told us that we should strive for satisfying 90 % of the userbase and not everyone. Currently we try to satisfy everyone. This is a road to failure in my opinion. We are on the road to KDE 3's configuration nightmare and creating an unmaintainable monster. We are working against plans we set for ourselves during the start of Plasma 5 development such as focus on the core features and only add what we can maintain. What I especially consider as dangerous to the community is that users get the feeling that if they scream load enough their wish will be fulfilled. That is something which makes bug management already now much harder. Bug or feature requests which had a final wontfix from me years ago are now brought up again in the sake of usability. It takes much more effort as I cannot say "meh, doesn't make sense", instead people (including KDE developers) are asking for explanation. Of course I have them, because I don't dismiss anything just like that, but it takes way more effort to manage and maintain the bugs. Also more feature requests are getting in as currently it's the time of wishing will be fulfilled. Also what I see as dangerous is the usage of "but usability" in review requests. Even security improvements are tried to be undone with the argument of usability. What I consider as dangerous here is that the usability project sees itself as standing above the security project (they should be on the same level) and that they harm the other project by proposing changes without understanding the implications. Similar to what I wrote about the VDG solutions are presented without asking the domain experts before. For the usability project my wish is to not take every user request as a mission. Instead evaluate whether it makes sense for the project. Perhaps also consult the domain experts prior to writing patches. It's way more difficult to say no to a change if the patch is already there. But maybe it's not where they want to take the product. So they accept the patch for usability although it doesn't follow what they aim for. Also please work against the user screaming. If users make noise about bugs or features they should not be rewarded with a fix about it. I fix bugs based on how much it affects the product and how many users are affected. A minor bug in an obscure setting - bad luck. Even if it's the pet bug of one user who really makes noise about it. Get to the level where you can evaluate what's really needed. Think as usability in the big picture and not in fulfilling every dream. -- I'll stay around and contribute changes and patches. But I probably will leave some mailing lists. Those lists where every phab mail gets send to are too difficult to follow. If you need my expertise in a review, please ping me. Thanks all Martin