From kde-panel-devel Sun Jun 03 17:58:13 2018 From: Eike Hein Date: Sun, 03 Jun 2018 17:58:13 +0000 To: kde-panel-devel Subject: Re: Stepping down as maintainer Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=152804870915564 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