incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Incubator report sign-off
Date Mon, 22 Dec 2014 16:57:26 GMT
On Monday, December 22, 2014, 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

could you waste a couple of words on pTLP, to me at least its a new term, I
would like to understand.

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)
> < <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:
> <javascript:;>
> For additional commands, e-mail:
> <javascript:;>

Sent from My iPad, sorry for any misspellings.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message