incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)
Date Mon, 05 Jan 2015 20:18:45 GMT
On 5 January 2015 at 20:06, Alan D. Cabrera <> wrote:

> On Jan 5, 2015, at 10:26 AM, jan i <> wrote:
> > On Monday, January 5, 2015, Alan D. Cabrera <
> > <javascript:_e(%7B%7D,'cvml','');>> wrote:
> >
> >>
> >> On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik <>
> wrote:
> >>
> >>> The tracking part is easy, though. What's difficult is the part
> >>> that would require us to do something with poddlings put
> >>> on hold. Unless we come up with clear exit criteria for
> >>> this new state -- I don't think we're solving any real problems
> >>> here.
> >>
> >> There’s no silver bullet here, if a podling cannot whip up a mentor it’s
> >> because:
> >> the podling is not popular and should probably be retired anyway, being
> >> put on hold will provide impetus for the podling to seek out a new venue
> >> there are not enough mentors
> >> There is no way to magically solve the latter.
> >
> >
> > You mean popular within the pool of mentors (IPMC), the project can still
> > be popular on several other scales.
> I’m not speaking of popularity of mentors; I regret that choice of words.
> I am stating that active and healthy podlings seem to have no trouble
> attracting active mentors.
> The converse seems to be true.  Unhealthy podlings seem to attract mentors
> who have signed up out of pity and subsequently go MIA.
I agree with the last part, I still have to see mentors volunteer for small
active and healthy projects which might not be main road. Of course it
depends on how active and healthy is defined, but as an example my little
project Corinthia barely managed to get 2 mentors, while in the same time
span we got 3 committers.

> Before anyone replies, I understand this is not a hard and fast rule but
> an imperfect qualitative observation on my part.
> Anyway, active and responsible mentors will eventually get to all podlings.
> > I might lack experience, but why do more active mentors guarantee that
> the
> > podling will be a better TLP ?
> I’m not sure who’s making that assertion.
Well its because I cannot see why a podling need more than 1 active mentor
at all times....having multiple is fine, to cover each other, but it should
not take more than 1 mentor to learn a podling, what it needs to
understand. The suggestion implicit says 2 mentors is the minimum needed
for at podling to become a successful TLP.

> > We try to solve the problem of mentors not being active but adding more
> > volume. I don't believe that is the right cure.
> We’re not adding volume.  The volume is already there.  We’re just making
> the state of affairs more explicit and transparent and adding culpability
> for MIA mentors.
Do we have a rule today that a podling needs at least 2 active mentors (if
we have that, then we would not have a problem with sign offs, or a lot of
dead podlings), at least I have not seen it....that is what I mean by
adding volume.

If just 1 mentor is active and sign off the reports, then I do not see the

> > I do agree with bernard that it is the podling that should ask for
> > help....but the IPMC should solve it.,
> Yes, it should help solve problems but if there are no mentors available
> there are no mentors available.
Then the IPMC should not have accepted the podling in the first place!

It is simply not fair to make the life of a podling, depending on whether
or not we have mentors available (REMARK after accepting the proposal) ! If
the podling have a healthy community and are active, we cannot and should
not close it down, just because we have a mentor problem.

To me telling a podling it cannot grow its community nor make releases, is
the same as closing it down.

jan i.

> Regards,
> Alan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message