On Sat, Nov 9, 2013 at 4:11 AM, Dave Brondsema <d...@brondsema.net> wrote:
> On 11/09/2013 02:23 AM, Jake Farrell wrote:
>> If mentors are not performing their duties to vote on a given releases for
>> a podling, then it is up to the IPMC as a whole to help that podling by
>> doing the do diligence and casting a vote. We all asked to be apart of the
>> IPMC or where honored by a nomination and accepted the role. It is up to us
>> to show these podlings what the Apache was really means. These projects
>> have all come to the ASF and we (the IPMC) have openly voted them into
>> incubation, its up to us to help them succeed.
>
> While this is true in theory it's hard in practice to wrangle those
> votes together.
That's not the only problem. While IPMC volunteers who perform "freelance"
release reviews keep the Incubator from grinding to a halt, our reliance on
them undermines the Incubator's effectiveness as an IP clearinghouse. I wish
that we would redirect those volunteer energies elsewhere.
IPMC members who vote +1 on an initial incubating release are endorsing the
the code import and IP clearance process[1], as well as any work done in-house
since incubation started. Votes on subsequent incubating releases are less
weighty because they chiefly endorse work done in-house since the last
release.
Non-Mentors who swoop in at the last minute to vote +1 on a codebase they've
never looked at produced by a community they've never interacted with are not
in a position to make such endorsements, particularly for the first incubating
release.
They are like building inspectors who never go inside.
>> Merit stands above all else, and the contributors that you have pointed out
>> are all exceptional individuals that have advanced their projects and
>> continued to do so after graduation within the ASF. There are no short cuts
>> here, merit is earned. I am 100% behind helping individuals that show
>> exceptional merit within a podling and deserve to be apart of the IPMC and
>> have a binding vote.
>
> Yes, lets do this. No new structures, minimal risks.
True. It seems that a number of people find this approach attractive. Let's
focus on the challenges:
1. Candidates have to be nominated.
2. The votes have to pass. Not all of them, but most of them.
In order for the votes to pass, those IPMC members who have misgivings will
have to lay them aside. But maybe this isn't such a big problem, because my
sense is that there are a number of candidates out there that even the
skeptics would feel pretty comfortable with. I can't believe we let Marmotta
escape the Incubator without nominating any of its contributors!
So how do we solve the problem of nominating people? Ideally, Mentors would
proactively identify and propose candidates -- even when, as would have been
the case throughout Marmotta's incubation, the podling has no immediate need
for additional Mentors. And maybe that will happen more often if it's less
contentious.
Still, there will be podlings where the nominations won't happen -- and here,
maybe the IPMC at large can play a role.
* Diagnose Mentor attrition sooner, using report sign-off and shepherd
review. (Or even better, mailing list archive scans.)
* Ping podling Mentors on private@incubator asking why the release manager
who handled that last release so well hasn't been nominated.
* ...
> The IPMC can fulfill their duty (when appropriate) by identifying people
> that merit IPMC membership, so less people will have to invest the
> significant effort of assessing all the many many details for new releases.
Right now, when a release candidate shows up on general@incubator without
three +1 Mentor votes, here's what we do:
1. First, wait for an outsider to cast a "freelance" +1 IPMC vote.
2. Finally, explore the possibility of nominating a standout podling
contributor for the IPMC -- but only when all else fails.
How about we reverse that: look for a podling contributor whose vote deserves
to be binding *first*, and only consider bringing in an outsider as a last
resort?
Marvin Humphrey
[1] http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
