On Monday, December 22, 2014, Roman Shaposhnik <r...@apache.org> wrote:
> 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 could you waste a couple of words on pTLP, to me at least its a new term, I would like to understand. rgds jan i > 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 <javascript:;>> 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 > <javascript:;> > For additional commands, e-mail: general-h...@incubator.apache.org > <javascript:;> > > -- Sent from My iPad, sorry for any misspellings.
