Team meeting today

[David Edmundson]

On Thu, Jun 21, 2012 at 1:47 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Thursday, June 21, 2012 13:23:02 David Edmundson wrote:
>> I made a similar form for Plasma is available here:
>> http://community.kde.org/Plasma/Maintainership please fill-in as
>> appropriate.
>
> there are 51 plasmoids in kdeplasma-addons alone.
>
> some plasmoids have clear owners (for various reasons: more complex, specific
> interest area, etc...) such as the comic plasmoid, remember the milk, kde
> observatory ...
>
> most are communally owned, however. this allows people to work on things
> rather more freely, but also reflects the reality that people come and go a
> lot.
>
> the bugzilla components also don't map cleanly to the code as they are often
> about functional distinctions as that is easier to help with categorizaton
> (multiscreen being perhaps the obvious example). again, some of these have
> people who care for them, and some are communally owned.
>
> so my main concerns for such a list are:
>
> * it will only cover certain elements but not others
>
> * that people who are no longer active will not remove their name and it will
> very quickly grow outdated (this has been my experience with all of the wiki
> pages we've used for such things ...)
>
> what i'm missing here is: why do we need this?
>
> is it that people do not know how to use git well enough to see who has been
> working on it?
>
> is the idea of community maintenance an alien idea so people want to see "the
> person who is in charge" or each item?
>
> i can see having a list of maintainers for components that are "strongly
> maintained" by an individual, such as the comics applet (to pick something
> completely at random). but then ... using git i'd be able to figure that out
> immediately as well.
>
> i can definitely understand wanting to have notation for who oversees which
> group of technologies: e.g. who is responsible for libplasma, for plasma in
> workspace and runtime (or which large parts of it...), for solid, for
> networking, for power management, for window management and composition ..
> etc. that would be useful for understanding how the overall product splits
> down into projects with team leadership.
>
> is that what we're looking for rather than a module-by-module break down of
> plasma?

I think you're probably right. I copied and pasted the list without
really thinking. What I think Alex Fiestas was leaning towards in the
meeting where we said we need this is what you described of covering
the entire Plasma Workspace, rather than the old term of  "plasma"
which was just the shell, lib and applets. The terminology still
confuses me.

Will have another try this evening which is more general.

Dave

>
> (i ask because this seems to have come up after i had to leave..)
>
> --
> Aaron J. Seigo
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>