Yay progress! +1 Thanks Roman (and everyone else on the thread)
Sent from my Windows Phone ________________________________ From: Roman Shaposhnik<mailto:r...@apache.org> Sent: 12/22/2014 8:42 AM To: general@incubator.apache.org<mailto:general@incubator.apache.org> Subject: Re: Incubator report sign-off Hi! before answering Ross' proposal, I'd like to remark that I was holding off on replying to see whether viewpoints that we haven's seen before would emerge. It seems that they didn't. It seems that we're still limited by the following options wrt. resolving mentors AWOL issues: 1. get rid of IPMC altogether and move to the pTLP model 2. make this a poddling issue: if a poddling fails to hunt down ALL the mentors for a sign-off -- reject its report 3. patch the current process with starting to drop the mentors from the project who don't sign off. This will essentially serve as a heartbeat for mentors (now, in my opinion it'll quickly deteriorate into mindless tick-offs -- but at least it does not harm). FWIW, I personally think #2 is a useless middles ground and if we really feel like #2, we may as well man up and do #1. Frankly, I'd be appalled to remain part of IPMC that treats its podlings like #2 without providing even the slightest accountability for its own members. Thus, to me, the choice is really about #1 and #3. So perhaps, the path forward is to try #3 first and then, if things don't improve, go all the way to #1. Please let me know what do you think. And now to comment on Ross's proposal. The only one that addressed my original issue of lack of clear R&R understanding (which I think everybody else, with an exception of folks bringing up #1 is avoiding): On Fri, Dec 19, 2014 at 11:00 AM, Ross Gardler (MS OPEN TECH) <ross.gard...@microsoft.com> wrote: > Strawman: > > What if a mentor is *required* to be an active participant of the project. > That is contributing code, > voting on releases and generally engaging with the community, they would be a > better mentor > since they have a vested interest in the project itself. Well, than I suggest we solicit an opinion on this list of how many mentors will remain if the requirement is to be put in place. I can tell you this much: personally I will have to resign from every single poddling I am currently mentoring. There is absolutely no way I can promise the level of commitment that goes beyond helping them with 'the Apache Way' and releases. IOW, if I were to be required to understand their technology -- I don't think I can stay. > Sure, we might reduce the number of projects coming into the foundation > but (IMHO) that is not a problem. Our goal as a foundation is not to be > large, it is to be high quality. But it is to be high quality on the level of understanding of the 'Apache Way' which has very little to do with the quality of code, documentation or any other piece of technology. > We could scrap the role of shepherd and change the role of mentors. A team > of 9 mentors would meet monthly to review *all* podlings reports (as submitted > by the champion). Their responsibility is not to engage with the projects but > to > review the reports crafted by the champion. Any follow up actions would be > taken by a single mentor and podlings (especially the champion) are expected > to address the issues raised. I actually like this proposal, but only if we can cut out the middleman alltogether. What you're describing is essentially pTLPs. Which is a fine idea. > The champion is still answerable to the podling community. > Where conflict arises within the community they can call upon the IPMC > mentoring team to ask for independent guidance. Let me ask you this: do you think it would be worth our while to try this without any other changes? IOW, make #2 a champion's problem, instead of poddling's problem? No other changes needed. > I look forward to the PMC tearing this strawman proposal apart and (most > importantly) > suggesting alternatives That was my expectation as well. Sadly, I don't think we've got too many alternatives :-( Thanks, Roman. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
