Stepping down as maintainer

[Alexander Potashev]

VDG = Visual Design Group. I guess that's how you generally refer to
all graphic designers who invest a substantial amount of their time on
KDE projects.
пн, 4 июн. 2018 г. в 9:29, Stéphane Ancelot <sancelot at numalliance.com>:
>
> Hi,
>
> What is vdg ?
>
> Regards
>
>
>
> Le 02/06/2018 à 10:14, Martin Flöser a écrit :
> > 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



-- 
Alexander Potashev