Am 2018-06-02 13:43, schrieb Eike Hein:
To establish the full extent of the range opinions here: Personally I
think the VDG has been working very well lately, and I want to thank
its members for being some of the most hard-working and motivated
contributors to Plasma today. They've made my work better many times.
I also disagree that this has lead to sacrificing "product work at the
altar of usability".
our experiences seem to differ here.
I believe the solution to any remaining woes lies in engagement, not
in throwing hands up in the air and complaining. It's normal for
coding and design teams to have some push-and-pull between them,
that's how they complement and course-correct each other. It's also
worth keeping in mind how frustrating it must be for design
contributors if code contributors let them constantly feel that they
are the final arbiters and gate-keepers, and resort to arguments from
authority constantly. This is not what "common ownership" in the
Manifesto is about. I urge code contributors to be aware of this
harmful messaging, which sets us back on our quest to grow our talent
mix, which has been paying dividends. This goes doubly so for
maintainers, whose primary function is to enable the work of other -
any - contributors. Let's keep in mind onboarding is one of our chosen
community goals.
What I considered as my most important job as maintainer was saying
"no". If a change is wrong or against the product vision one needs to be
able to say no. And there is nothing bad about that. It's the job of the
maintainer to ensure the product is in good shape and goes into the
right direction. If I as maintainer see that there could be a better
solution or a proposed solution has side effects the author cannot know
about it's my duty to say no. No matter whether it's a new contributor,
the VDG or a dev having been around for 20 years.
What a maintainer should not say no to are ideas. In fact the maintainer
should help moving ideas into the right direction, so that they could be
added to the product. In that sense I think it is important to have the
maintainer a gate keeper for the code side, but not for the idea side.
If we work like that I think this would be satisfying for all sides. To
take the example of the no border change. I don't mind the VDG to want
to improve the area. If they present the idea on "we want Kirigami apps
look great", we can work on that. If instead a change is presented which
is flipping a default on the code side, which doesn't make sense from
the product perspective, my job as the gate keeper kicks in and I need
to say no. For the overall product KWin I think this change is wrong. I
think there are solutions which can result in satisfying both, Roman's
patch is a step into that direction for example.
So the problem I see here is not that design and code teams clash. The
problem is in my opinion that the design team presented technical
solutions without consulting the experts.
Personally my opinion is that the VDG does not even want to change the
borders. It's a hack around the problem. Kirigami apps seam not to be
designed with decorations around them. That's fine, but changing the
default as a hack is the wrong solution. Like what Hugo said we need to
fix Kirigami instead of changing the default. There are multiple ways to
do that. One option would certainly be client side decorations. And
that's also fine. If that's what the VDG wants it could be implemented
in a sane and working way. What I think is that they did not even
consider that option. But that's where the expertise of the maintainer
comes in. He is the one with the best technical understanding of the
problem and the solution.
Finally, I want to say that I think it's not in good form to have
started this discussion in this thread. Putting an entire set of
contributors on trial under the mantle of someone's disgruntled exit
announcement, biasing the burden of proof from the get-go? What are we
doing here?
Sorry about that. Maybe it's not the place to discuss that. I only
wanted to explain why I lost motivation.
Cheers
Martin
