My thoughts on this are two-fold: (a) Non-VDG devs generally shouldn't question VDG dev decisions in detail and avoid push-back on small issues. The VDG is still a relatively new institution and needs to be given the latitude to try things, build up institutional knowledge (and learn how to document it) and gain a bigger stake in the fate of the pro- duct.
For the non-VDG devs this may at times feel uncomfortable because it involves surrendering control to somewhere else, but this loss of control is the only way to grow a more capable VDG and bring about a new status quo where this division of labor is the true default. Non-VDG devs like me are generally given a lot of freedom to screw up and learn from our mistakes; the VDG needs that too. Some eyes will read the above and don't like it because it firmly demarcating two camps instead of treating all communica- tion as being between identical agents. The problem with the everybody-is-just-a-dev model KDE has historically used though is that it's never naturally lead to adopting processes that address some of our weaknesses, like doing design review passes. Setting up purpose-specific departments that within their man- date work on organizing these things is how we hope to fix that, and as long as joining those departments is simply a matter of merit there's no inherent problem of fragmantation. tl;dr If you're not part of the VDG, you should stay out of the VDG's way. If you don't want to, become part of the VDG. At the same time it's the VDG's responsibility to make sure they're succeding and the quality of their work is high. (b) For non-VDG developers, regressions from theme changes are just bugs like any other bug. Enumerating issues like that doesn't mean a new theme doesn't go in, it just means they're bugs to be fixed. Instead of feeling criticized, my recommendation to the VDG is that they see feedback from non-VDG developers as a resource: The coders on the theme know a lot about how the code works, which is the canvas you're trying to design to. The coders can help you succeed in your mission. Cheers, Eike _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel