Stepping down as maintainer

[Martin Flöser]

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