Team meeting today

Aaron J. Seigo aseigo at kde.org
Thu Jun 21 12:47:36 UTC 2012


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 ask because this seems to have come up after i had to leave..)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120621/713b8c50/attachment.sig>


More information about the Plasma-devel mailing list