> On Jan 7, 2015, at 12:13 PM, Marvin Humphrey <mar...@rectangular.com> wrote:
> 
> On Wed, Jan 7, 2015 at 9:42 AM, Alan D. Cabrera <l...@toolazydogs.com> wrote:
> 
>> https://wiki.apache.org/incubator/MentorRebootProposal
> 
> From that page:
> 
>    People who wish to become mentors that are not in the IPMC must be a
>    novice mentor, whose mentorship is not counted as an active mentor, for at
>    least one podling's incubation. ASF members can become IPMC members.
>    Non-ASF members must mentor a project before becoming an IPMC member.
> 
>> No more layers.
> 
> Looks to me like the proposal invents a new layer: the "novice mentor”.

It’s not a layer.  It’s a phase that mentors need to go through.  This is not 
new and it’s something we currently do.  I’ve just made it more explicit.

> I deeply dislike how this proposal erects barriers to keep us from electing
> people onto the IPMC.  One of reasons the Incubator is functioning well these
> days is because we've welcomed lots of new people who have brought lots of
> energy!

And if our process/roll churn died down, what use is the IPMC other than 
mentoring podlings through incubation?  IMO, you are either “here” to directly 
help podlings incubate or your here to contribute to process/roll churn.

I’m all for energy.  Great.  I want that energy directed toward facilitating 
successful incubations.  If you don’t want to be a mentor then why are you here?

Mentoring and vetting is what the incubator is all about.

> If anything, I'd rather go the opposite route: no more automatic joining for
> ASF members.  (I'm not proposing that, I just think it's less bad.)

I thought about that.  The thinking is that ASF members are already 
“trustworthy”.   Maybe we should remove it and see if the proposal still flies. 
 Anyone else have an opinion on that?

> Similarly, this proposal effectively prevents us from elevating outstanding
> podling contributors onto the IPMC, undoing the wildly successful reforms Joe
> Schaefer championed that have gotten podlings like Thrift, ManifoldCF and
> Allura unstuck.  Why discard that crucial tool from the toolbox?

Would not these outstanding podling contributors be considered podling novices 
who have been vetted by “one” podling incubation?

> The Incubator has made important progress.
> 
> *   We're not chronically losing track of podlings the way we once did.

I’m not so sure.  Isn’t the lack of reporting and the need for shepherds 
symptomatic of us chronically losing track of podlings?

> *   Our report is consistently on-time and well-put-together, and it's
>    become a team effort that starts great conversations and doesn't
>    burn out the Chair.

I’m confused.  Automated reporting does not mean we have a handle on things

While the Incubator report itself is consistently on time, mentors have 
consistently not signed off on podling reports, if the reports get filed at 
all.  The problem is so endemic that we “needed" to create the role of 
shepherds.  Now, we need people to review the shepherds to make sure they 
review the mentors who were supposed to review the podlings.

Some podlings are graduating w/ no clear understanding of the Apache Way.

This is all symptomatic of MIA mentors.

> *   Releases are getting approved faster, with fewer RC cycles and with
>    less arguing.

That’s a function of how much spare time people in the IPMC have…  I would not 
say the problem has been solved.

> I keep hearing how the IPMC is too large to achieve consensus so we have
> to keep people out.  But the people who have brought back these radical
> overhaul proposals and are inundating general@incubator with dozens of
> emails each day are the same discontented core who were doing it two
> years ago.

I do not claim that the IPMC is too large and those that do do not understand 
the fundamental problems we have, imo.

We do have problems; see above.  This is what precipitated the recent few 
proposals.

With that said, my proposal is not a radical overhaul.  The proposal is not 
rebooting the IPMC.  The proposal is making things more explicit and 
transparent while not changing the amount of expected responsibilities.


Regards,
Alan



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to