From kde-panel-devel Sat Jun 02 09:58:17 2018 From: Marco Martin Date: Sat, 02 Jun 2018 09:58:17 +0000 To: kde-panel-devel Subject: Re: Stepping down as maintainer Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=152793353531637 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--000000000000265c5f056da5be4f" --000000000000265c5f056da5be4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=B6ser 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=C3= =B6rn, > 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=C3=B6ser" 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=C3=B6r= n, 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 --000000000000265c5f056da5be4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,
Sorry to he= ar that, and thanks for your continued amazing work on kwin, it's an am= azing piece of software and I really think is one of the best gems within K= DE, something that no other project can rival in any way.
I'm with Roman asking you to reconsider, as we do still need guid= ance before mastering enough, in the end of course it's your decision a= nd yours only.

Unfortuna= tely I have to agree to many points of your analysis about the VDG: it defi= nitely 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 happ= en.

--
Marco Martin

On Sat, Jun 2, 2018, 10:14 Martin Fl=C3=B6ser <mgraesslin@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 fee= ling
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 <= br> 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:
=C2=A0 * tendency to do changes and reverting them again
=C2=A0 * taking easy solutions like flipping defaults without looking at th= e
big picture
=C2=A0 * tries to dictate much more than just visual or design
=C2=A0 * does not consult domain experts
=C2=A0 * presents final solution and disallows discussion as you were not p= art
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 <= br> 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, <= br> 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=C3=B6r= n,
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", instea= d 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 r= eview
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. <= br> 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 th= e
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 wil= l
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=C3=B6ser" <mgraesslin@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 fee= ling
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 <= br> 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:
=C2=A0 * tendency to do changes and reverting them again
=C2=A0 * taking easy solutions like flipping defaults without looking at th= e
big picture
=C2=A0 * tries to dictate much more than just visual or design
=C2=A0 * does not consult domain experts
=C2=A0 * presents final solution and disallows discussion as you were not p= art
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 <= br> 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, <= br> 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=C3=B6r= n,
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", instea= d 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 r= eview
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. <= br> 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 th= e
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 wil= l
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

--000000000000265c5f056da5be4f--