From kde-panel-devel Mon Jun 04 06:29:33 2018 From: =?UTF-8?Q?St=c3=a9phane_Ancelot?= Date: Mon, 04 Jun 2018 06:29:33 +0000 To: kde-panel-devel Subject: Re: Stepping down as maintainer Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=152809379802024 Hi, What is vdg ? Regards Le 02/06/2018 =C3=A0 10:14, Martin Fl=C3=B6ser a =C3=A9crit=C2=A0: > Hi all, > > After long consideration I decided that I am no longer in a position=20 > to be a maintainer. I currently do not follow up on reviews and hardly=20 > contribute any code. Given that I think it's time to pass on the=20 > torch. KWin is currently in a good position we have new developers=20 > working on various areas of KWin and my suggestion would be to split=20 > the task of maintainership on many shoulders, specialized for various=20 > areas. > > My lack of work lately was not just the lack of time, but to a larger=20 > degree a lack of motivation. I searched a lot for the reasons for the=20 > lack of motivation and I think I identified two core areas where KDE=20 > is currently heading to and where I just disagree with these=20 > directions. Please don't take my explanation personal, you are doing=20 > awesome work, it's just that I don't approve these directions. Lately=20 > I had a feeling of doing fundamental opposition to changes the=20 > community wants to do. Granted I think these changes are wrong, but I=20 > don't want to stand in the way, if that's what the people doing the=20 > work want. > > What I identified as the core issues is the way the VDG currently acts=20 > 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= the=20 > 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 no= t=20 > part of the telegram discussion > > As examples I take the discussion around the change of lock screen=20 > wallpaper and the window decoration no border setting. In both cases=20 > the VDG identified a problem, which is great. But also presented the=20 > solution. In both cases the technical solution is bad and results in=20 > losing functionality. It takes a hard fight to convince the VDG that=20 > their solution is wrong and that something better is required. In the=20 > case of the lockscreen we succeeded. The new implementation is=20 > awesome, a clear improvement over the blue background and also over=20 > the one we had before. But if we would have taken the approach the VDG=20 > did without opposing and fighting we would have ended with a solution=20 > worse to the one we had before the blue background. To me this is a=20 > dangerous development. I don't want to have to fight for good=20 > solutions. That costs a lot of power and is not healthy for the=20 > community. My wish to the VDG would be to take a step back again and=20 > not trying to find the technical solution to the problems you=20 > identify. Please approach the developer community with "hey, we think=20 > this area is bad, we want to have these improvements, how can we=20 > achieve it?" What I also think is important is that you realize that=20 > changing a default is a technical solution. It's not just design. Ask=20 > the experts whether that is the right solution to your problem and=20 > don't dismiss their opinion based on "it's just design". > > Similar the no border discussion highlights some of these problems.=20 > While it sounds like a minor thing, it is not. We see the fundamental=20 > problems: domain experts are not consulted, if they chime in they are=20 > told that they have no saying in it as they were not part of the=20 > discussion. Changing the default has more consequences than just a=20 > visual one. I told that and nobody is listening. We are going the easy=20 > road of flipping defaults without thinking of the big picture or=20 > finding good solutions. This is not what we used to strive for in KDE.=20 > We used to operate on highest technical level trying to bring the best=20 > solutions. This is clearly not form follows function. We are removing=20 > function in the sake of form. A dangerous development. To get one=20 > thing clear: I don't care about whether no border or normal is the=20 > default, I'm not personal attached to this. What I care about is that=20 > we get the best solution for the users. And I am sure that changing=20 > this default will have negative impact. And that is sad. > > The second area where I really dislike the development KDE is taking=20 > is the usability project. I have a feeling currently everything is=20 > done in the sake of usability. We are losing the big picture, we are=20 > no longer doing product development. We don't try to improve the=20 > product and take it to the next level instead a thousand of minor=20 > things are added in the sake of usability. We ignore that every=20 > checkbox or option added decreases the usability for everybody else,=20 > we ignore the costs to maintain the code due to the changes. I=20 > remember that people like Bj=C3=B6rn, Kevin and Thomas told us that we=20 > should strive for satisfying 90 % of the userbase and not everyone.=20 > Currently we try to satisfy everyone. This is a road to failure in my=20 > opinion. We are on the road to KDE 3's configuration nightmare and=20 > creating an unmaintainable monster. We are working against plans we=20 > set for ourselves during the start of Plasma 5 development such as=20 > focus on the core features and only add what we can maintain. > > What I especially consider as dangerous to the community is that users=20 > get the feeling that if they scream load enough their wish will be=20 > fulfilled. That is something which makes bug management already now=20 > much harder. Bug or feature requests which had a final wontfix from me=20 > years ago are now brought up again in the sake of usability. It takes=20 > much more effort as I cannot say "meh, doesn't make sense", instead=20 > people (including KDE developers) are asking for explanation. Of=20 > course I have them, because I don't dismiss anything just like that,=20 > but it takes way more effort to manage and maintain the bugs. Also=20 > more feature requests are getting in as currently it's the time of=20 > wishing will be fulfilled. > > Also what I see as dangerous is the usage of "but usability" in review=20 > requests. Even security improvements are tried to be undone with the=20 > argument of usability. What I consider as dangerous here is that the=20 > usability project sees itself as standing above the security project=20 > (they should be on the same level) and that they harm the other=20 > project by proposing changes without understanding the implications.=20 > Similar to what I wrote about the VDG solutions are presented without=20 > asking the domain experts before. > > For the usability project my wish is to not take every user request as=20 > a mission. Instead evaluate whether it makes sense for the project.=20 > Perhaps also consult the domain experts prior to writing patches. It's=20 > way more difficult to say no to a change if the patch is already=20 > there. But maybe it's not where they want to take the product. So they=20 > accept the patch for usability although it doesn't follow what they=20 > aim for. Also please work against the user screaming. If users make=20 > noise about bugs or features they should not be rewarded with a fix=20 > about it. I fix bugs based on how much it affects the product and how=20 > many users are affected. A minor bug in an obscure setting - bad luck.=20 > Even if it's the pet bug of one user who really makes noise about it.=20 > Get to the level where you can evaluate what's really needed. Think as=20 > usability in the big picture and not in fulfilling every dream. > > --=20 > > I'll stay around and contribute changes and patches. But I probably=20 > will leave some mailing lists. Those lists where every phab mail gets=20 > send to are too difficult to follow. If you need my expertise in a=20 > review, please ping me. > > Thanks all > Martin