Perhaps then, there's a recommendation that: - a member can be champion to only one pTLP at a time. - a member can be mentor to no more than two pTLP at a time.
This to me looks like a good way to make sure a mentor can always do their job - make sure they're not overloaded. BTW these #'s (1 & 2) should be subjective as I'm just making guesses for good #'s. John On Mon Jan 05 2015 at 7:38:24 PM Alan Cabrera <l...@toolazydogs.com> wrote: > A champion is merely a mentor who has publicly committed to being an > active mentor, in some significant capacity, of a podling. > > The creation of such a role is symptomatic of a dysfunctional organization > where responsibility and accountability has been diluted so much it's not > at all clear who will actually follow through with their responsibilities. > > IMO, all that's needed is two active mentors. To get that we need to hold > mentors accountable. If we do that then things become simpler and we can > get rid of champions and shepherds; two role that were created to fill the > gaps left by unaccountable mentors. > > > On Jan 5, 2015, at 3:41 PM, Benson Margulies <bimargul...@gmail.com> > wrote: > > > > Back in 2013, I suggested asking the Champion to accept a very clear > > level of reporting responsibility: to write a sentence or two _every > > month_ or find someone else to do it. That's one person whom I wanted > > to ask to sign up, for the duration of an incubation, to pay enough > > attention to be able to report a basic heartbeat. > > > > ? > > > > > >> On Mon, Jan 5, 2015 at 3:57 PM, Upayavira <u...@odoko.co.uk> wrote: > >> > >> > >>> On Mon, Jan 5, 2015, at 08:18 PM, jan i wrote: > >>>> On 5 January 2015 at 20:06, Alan D. Cabrera <l...@toolazydogs.com> > wrote: > >>>> > >>>> > >>>>> On Jan 5, 2015, at 10:26 AM, jan i <j...@apache.org> wrote: > >>>>> > >>>>> On Monday, January 5, 2015, Alan D. Cabrera <l...@toolazydogs.com > >>>>> <javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com');>> wrote: > >>>>> > >>>>>> > >>>>>> On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik <ro...@shaposhnik.org> > >>>> 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 > >>> problem. > >>> > >>> > >>> > >>>> > >>>>> 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, > >> > >> From an idealistic perspective, you are completely right. Apache should, > >> once a project has been accepted, provide the support needed. > >> > >> The reality is that, given the ASF's volunteer nature, that simply won't > >> always work. > >> > >> I'd much rather we be clear with projects right up front, saying > >> something like: > >> > >> "To join the Incubator, you need one or more mentors. To get to > >> graduation, you will need the support of those mentors. If mentors > >> become unavailable, you will need to seek replacements. Unless you have > >> already learned the ways of the ASF and are ready to graduate, you will > >> need to keep engaged with your mentors. If possible, engage in the wider > >> ASF, and develop connections with others who might be in a position to > >> assist with mentorship should one or all of your current mentors become > >> unable to fulfill the role. " > >> > >> This is, actually, what happens, and I'd much rather we just said it > >> like that :-) > >> > >> Upayavira > >> > >> --------------------------------------------------------------------- > >> 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 > >
