Stepping down as maintainer

[Stéphane Ancelot]

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