+1, this makes sense to me, Roman. For #3, please feel free to use my apachestuff code: http://github.com/chrismattmann/apachestuff/ in particular, incubator_mentor_tally, the latest results of which are here:
https://github.com/chrismattmann/apachestuff/blob/master/incubator-mentors- tally.txt ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Roman Shaposhnik <r...@apache.org> Reply-To: "general@incubator.apache.org" <general@incubator.apache.org> Date: Monday, December 22, 2014 at 8:42 AM To: "general@incubator.apache.org" <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 >
