Stepping down as maintainer

[Marco Martin]

Hi Martin,
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.
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.

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.
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.

--
Marco Martin

On Sat, Jun 2, 2018, 10:14 Martin Flöser <mgraesslin at kde.org> wrote:

> 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
>

On Jun 2, 2018 10:14, "Martin Flöser" <mgraesslin at kde.org> wrote:

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20180602/9b413656/attachment-0001.html>