Noel J. Bergman wrote:
We have the notion of a PPMC, but I don't believe that we are making as
effective use of them as we should. This is effecting our ability to scale,
and allowing things to fall into the cracks. In addition, people are not as
clear as they should be on how the Incubation Process works. So ...
-- We should require 3+ Mentors for each project
-1. +1 to encourage 3+ to mentor, but it's not worth having folks step up
to mentor a project simply because 'they need three' - quoting Justin's
thoughts - with which I wholeheartedly agree. We don't need body counts,
we need dedicated mentors.
-- Upon acceptance, we should establish the initial
PPMC as consisting of the Mentors.
--1 - worst idea of the thread. You can't teach new project members to
become project managers if you exclude them from the oversight and management
of their own project. You graduate them to TLP status and they look around
without a -clue- how to solve problems.
-- Upon project acceptance, we should immediately
create the [EMAIL PROTECTED]
mailing list. Or -private if there is a consensus
to switch to that nomenclature.
That's what we do today, AUIU. I'm leaning twords Roy's position on -private
and therefore requested the new lokahi-private@ list for managing this new
project. If there is any confusion about what's private/what's public, I'll
certainly share the experiences of this ppmc with the general incubator
community.
Except that my attempt to create tmcg2-ppmc (renamed later to lokahi-private)
in order to draft the /projects/project.xml document was rejected, and wouldn't
be considered until the /projects/project.xml document existed. Which is fine,
if we want the /projects/project.xml to be created, then the ppmc/private list,
and finally other resources.
-- Once established, the PPMC shall
-- work to make sure that the other resources
are put into place.
Uhm, ya.
-- vote on other PPMC members (only those on
the Incubator PMC have binding votes)
NO. The entire Incubator PMC have binding votes, and ratify the decisions
made by the podling ppmc. They vote, their choices aren't legitimate until
ratified. However, it doesn't make sense for every business decision of
the project to be ratified individually by the incubator pmc, we would be
flooded. So we've restricted that to votes on pre-graduation code releases,
and graduation itself (which ratifies the actions of the ppmc in whole in
their creation of the new project/subproject.)
-- vote on Committers (see above)
Well, we could add ratifing committers individually by the incubator pmc.
If you want the extra work.
-- ensure that the quarterly report is provided
to the Incubator PMC
Uhm, we do that now. In fact I *prefer* to delegate that to some admin
minded ppmc members so they learn to write these for themselves following
graduation.
Comments please. And, yes, I expect that some people will say "but isn't
this how things (should) work today?" Well, I would say yes. But the meme
doesn't seem to have entirely caught on.
If my 'duh - yea we do that today' comments don't jive with all of the currently
incubating projects, then yes I agree we should change those podlings. As for
the two new proposals, no.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
