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