incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (3980)" <>
Subject Re: Incubator report sign-off
Date Mon, 22 Dec 2014 17:05:57 GMT
+1, this makes sense to me, Roman. For #3, please feel free to use
my apachestuff code:
in particular, incubator_mentor_tally, the latest results of which are

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
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

-----Original Message-----
From: Roman Shaposhnik <>
Reply-To: "" <>
Date: Monday, December 22, 2014 at 8:42 AM
To: "" <>
Subject: Re: Incubator report sign-off

>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
>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)
><> 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
>will remain if the requirement is to be put in place. I can tell you this
>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
>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
>> 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
>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
>> of 9 mentors would meet monthly to review *all* podlings reports (as
>> 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
>> taken by a single mentor and podlings (especially the champion) are
>> 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 :-(
>To unsubscribe, e-mail:
>For additional commands, e-mail:

View raw message