Common purpose for the Plasma team, and VDG

[Eike Hein]

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