If this was a software project, and the appropriate answer was unknown,
they you might apply a "lean startup" approach, and figure out how to
run tests to see which way works best.
Given the number of incubating projects, should be easy to run some
experiments. Then you just need to build up some consensus on how to run
the experiments. And how to evaluate the results. Essential to establish
some metrics that will correlate with success. Then run the experiments
for a while (three months, six months?). At the end, you'll have actual
data that will inform a decision.
Eric.
On 5/10/13 9:25 AM, Benson Margulies wrote:
So, here we have:
Alan's idea of removing champions and shepherds and demanding mentor
recommitment, with the 'teeth' of putting podlings on ice if they
can't muster an adequate mentor squad.
My idea of asking champions to step up to some specific supervision
responsibility, thus allowing some flexibility for some mentors to be
more 'supervisory' than others.
Ross' ideas about shepherds,
Chris' proposal to push the self-destruct button.
Does anyone have a suggestion for a decision procedure? I don't see,
or foresee, a consensus for any of these.
My draft board report says that if we don't find a way forward in time
for the June board meeting, I propose to discuss the situation with
the board.
On Thu, May 9, 2013 at 3:34 AM, Ross Gardler <rgard...@opendirective.com> wrote:
Sent from a mobile device, please excuse mistakes and brevity
On 8 May 2013 02:20, "Bertrand Delacretaz" <bdelacre...@apache.org> wrote:
On Wed, May 8, 2013 at 10:47 AM, Ross Gardler
<rgard...@opendirective.com> wrote:
...I've made a proposal for giving the IPMC teeth but it hasn't gained
support..
URL?
Sorry, working from mobile device while travelling. I proposed creating a
board like structure and formalising shepherd role. Very similar to Chris'
proposal but leaving overhead with IPMC rather than moving to board.
...In the absence of something else with teeth then I'm +1 for
probationary TLPs as proposed by Chris as long as we stop accepting
projects that are likely to run into problems according to our
collective experience....
If you're able to find out that a podling will cause problems in the
future, or that its mentors will become inactive, maybe I should hire
you for this lottery betting club ;-)
Hehe - fair comment. I was thinking, for example, of BlueSky - the archives
show my concern that was ignored and ultimately shown to be right. A
counter example is OpenMeetings who addressed my concerns, came back and
graduated quickly and smoothly. I'm not suggesting its always possible to
get it right, but I do think we can be more rigorous in general.
Apart from that I agree that the board doesn't have cycles to handle
problematic podlings or missing mentors, and as a result whatever
actions it would take would be much harsher than what we do here.
That's the more important point.
Ross
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
