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