I like the idea, but isn't the initial list primarily a question for the
Secretary.
Is the Secretary ok with 1000 additional ICLAs arriving en masse from an
even larger project?

If so, then I think the solution is much simpler; *Let the podling decide*
if it is only Mentors, every user who has showed up at the project, or
anything in between. If the Secretary has workload issues with ICLAs, then
add a "max X" to the "let the podling decide". My guess is that the
Secretary would say Ok to up to 100, possibly much higher (it spreads out
over a few weeks). The less Incubator interferes the better, I think.

Niclas

On Wed, Sep 28, 2016 at 1:27 PM, Greg Stein <gst...@gmail.com> wrote:

> On Tue, Sep 27, 2016 at 4:39 PM, Bertrand Delacretaz <
> bdelacre...@apache.org
> > wrote:
>
> > On Tue, Sep 27, 2016 at 11:01 PM, Roman Shaposhnik <ro...@shaposhnik.org
> >
> > wrote:
> > >... Greg's proposal, as far as I can see, is predicated on mentors being
> > fully
> > > aware of an increased load...
> >
> > And as such might be an interesting filter to make sure mentors are
> > actually going to engage.
> >
>
> RIght. That was a bit of my thought: if the mentors aren't engaged enough
> to vote people in, then what are they doing there.(*)
>
> The basic concept can certainly be fiddled with. I see a couple ways:
> increased mentor count for the bootstrap work, and/or maybe set the initial
> list at (5) rather than (0).
>
> But back to (*), the mentors may only be there for *community*
> development/education. As stated elsethread, such mentors may not be
> properly equipped to evaluate merit for committership. That's a fair point
> which I had not considered. ... So you could maybe imagine (1) Champion,
> (3) Mentors, and (5) PPMC/committers to start any podling.
>
> Cheers,
> -g
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Reply via email to