incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Bowen <>
Subject Re: Incubator report sign-off
Date Mon, 29 Dec 2014 14:40:26 GMT

On 12/22/2014 11:42 AM, Roman Shaposhnik 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
>      2. make this a poddling issue: if a poddling fails to hunt down ALL
>          the mentors for a sign-off -- reject its report

-0.5 to punishing podlings for the failings of mentors. That would 
really suck.

>      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).

... who don't sign off N times, perhaps? Missing one should be a 
warning, two a scolding, three the boot, perhaps?

> 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.

Yes. Agreed.

> 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
>> 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.

I'm considering serving as a mentor, because I think that my experience 
at the ASF would benefit an incoming podling. If I was required to be a 
coder on that project, I would no longer be able to participate in that 
capacity, as my coding abilities have atrophied over the last few years.

I also object strongly to the use of the phrase "contributing code" 
becoming part of any written policy. (#INCLUDE standard conversation 
about documentors, marketers, event planners, community managers, etc, 
being every bit as meritorious as coders.)

>> 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.

I like the proposal a lot too, and almost proposed it myself. It's a 
mirror of what the board does, obviously, and raises the bar a little 
when it comes to podling reports. It also gives the podlings a little 
more idea of what to expect once they do graduate.

>>   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 :-(

Roman, please forgive me absence from this conversation. I started the 
thread, and then went on Christmas vacation. I am still on vacation for 
another week, but will attempt to keep up with the conversation here, 
and not abandon the thread I started. Please also forgive the dozen 
responses that I'm dropping all at once.

I care deeply about the outcome of this conversation, and it certainly 
sounds like several other people do, too, but the timing was unfortunate.

Rich Bowen - - @rbowen - @apachecon

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message