Stepping down as maintainer

[Eike Hein]

On 06/03/2018 07:05 PM, Martin Flöser wrote:
> 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 think this is true, and I think it's helpful to talk about my
experiences a bit more to understand where it's coming from. What
follows is a lot of talk about KCM rewrites, which I know you haven't
been closely involved in, but I think it's worth a read for some of the
higher-level points.

Most of my recent experience working with the VDG has been in context of
the System Settings rewrite project. I've rewritten a bunch of KCMs now,
and for me the process has been like so:

1. The VDG did a large set of first wave mockups, one for each mockup.
Find the mockup.

2. Look at it, find the immediate "this is not going to work" gotchas
and have a brief chat about it with the VDG.

3. Implement a first rough version based on the mockup and the conversation.

4. Put up the rough first version on Phabricator for review. Invite the
VDG to comment. Iterate together both with the VDG, as well as with KF5
upstream on the technical side to get lib ducks in a row to support the
new UI.

So it's been an iterative ping-pong thing. Some notes on this:

* I find that having an initial mockup to implement improves my
productivity as a developer. Having a known target to implement is a
much more brisk process vs. inventing an UI from scratch myself during
coding.

* As we do more and more KCMs, it's increasingly become a bit
problematic that the first-wave KCM mockups are a bit outdated now, as
they no longer reflect the latest components and patterns we've
developed together through iteration. Since I am highly involved I can
adapt to this on the fly, but for someone coming at the mockups new it
can be a problem.

* The mockups can have obvious problems. Sometimes the designer doing
the mockup didn't quite understand what's going on in the KCM, or they
missed some important piece of the puzzle. So I can't just implement it
as-is, I need to provide feedback to the VDG and and explain and pose
them the challenge. They usually then produce new mockups that take this
feedback into account, and it's still a productivity win for my side of
things because I don't need to fiddle with mockups, and because more
people generate more ideas between them.

* In general I find that the VDG pulls me into directions I wouldn't
have gone in myself (e.g. due to "this would be annoying to code"
lazyness or having a biased tech perspective on the UI). I also find
that the VDG wouldn't be able to produce sensible UI without having
someone to explain the technology requirements. It's a mutual
push-and-pull and mutual course correction.

* The end result of this process is often better than what I would have
done all by myself, while requiring less of my own time and brainpower.
This means much higher utilization of myself and higher throughput. I
feel satified by the results in the end.

* I've realized that "making the VDG work well" is much less about
making the VDG "perfect" and producing exactly what you want at the push
of a button, but that "working well" is basically having a working
process like the one above.

* I've also realized that things are not easy from the VDG side of
things. For code contributors, there's a wealth of institutional
knowledge and experience to draw from. I can literally open up Hacker
News and peruse a dozen articles on how to engineer codebases and how to
work productively a day. Design teams in FOSS communities are a much
younger thing with much less in the way of provided ladders to climb.
They're also joining communities where code contributors have very low
levels of empathy for what it feels like when your opinion isn't law and
when it isn't taken for granted that you are gatekeeper to the
repository. There's a situation embarassingly close to the way that
white privilege works in the way code contributors are entrenched in
existing FOSS communities, and it's a barrier to true talent diversity.

Now from other developers I've gathered that their experience has been
different and much more frustrating. I believe it's due to several reasons:

* Not having been as lucky as me in having had the opportunity to work
with the VDG more regularly and experience a perspective change that
puts the process first. This manages my expectations for what I get out
of the VDG and what I need to on my end, and avoids frustration. It also
means I don't feel so bad when I say "no", because I get to have
confidence in what I bring to the table.

* It's very hard to have the experience I've had if you don't have the
time to engage with the VDG for sometimes several hours every day. It's
a very intensive, regular-work process. It requires keeping up with
things a lot. This is just not realistic and pretty overwhelming for
many others due to different circumstances. (This is also true for some
on the VDG side, btw., and then escalates frustation on both sides, when
two people chat who are equally out of the loop and confusion mounts and
no one sees the pattern.)

* As sort of an adjunct to the above, not doing maintenance/upkeep on
mockups (refreshing them to reflect new designs, etc.) is a big problem
with onboarding devs to existing work items. Pholio being very hard to
navigate currently also contributes to this. We may not be using it well
yet.


> 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.
I mostly agree with all of the move. I believe a bit more in erring on
the side of growing the contributor base than you do, because I have
vivid memories of how crappy and wrong my first patches to KDE where,
and how vital it was to deal with encouraging maintainers for KDE being
able to retain me as a long-term contributor. And now I don't make the
same silly mistakes anymore because I learned a lot.

Heck, when I started contributing to Konversation, I wasn't aware that
inheritance existed in C++, and merrily implemented code redundantly in
subclasses. Some of that code miraculously even made it into the repo,
even though it's obviosuly crap. You could call out the maintainers for
allowing the code quality to deteriorate in that way. On the other hand,
then I wound up *being* the next maintainer of the app, and I cleaned
its code up later. There's a lesson there about how allowing people to
make managable mistakes can be worth the gamble. Plus, thanks to code
review etiquette it wouldn't even happen like this anymore.

I'm a broken record on this, but I genuinely believe one of the most
remarkable properties of the KDE community is that it's
multi-generational, instead of petering out with its founder generation.
This must be retained.


> Cheers
> Martin

Cheers,
Eike