On 5 January 2015 at 21:57, 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 :-) >
I agree that the world is not perfect and I really like your wording.....mainly for 2 reasons: - its does not require 2 mentors, but "one or more". - its does not put fear in the podling that it might be prohibited from growing due to outside events (availability of mentors). As I see it, a Podling should always have at least 1 active mentor....should the worst happen, and the podling is without mentor, BUT does an active job of seeking a replacement and gets a new committer or has a release, then the IPMC must take action, so the podling does not suffer. This is I think a pragmatic solution...that allows the podling to work, provided it is active. I do not want us to make the ladder higher for entering ASF, it is already pretty high compared to e.g. github (I do know we provide more, but newcomers have to learn that first !!). rgds jan i. > > Upayavira > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
