Stepping down as maintainer

[Martin Flöser]

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