incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liang Chen <>
Subject Re: A smaller IPMC
Date Fri, 08 Mar 2019 00:25:23 GMT

One more suggestion: How about maintaining one table, and ask IPMC to freely
provide info by them-self which part they are mentoring or will be going to
mentor as volunteer.
For example myself : Helping new project (DataSketches)  to prepare
incubator proposal. and participate in some vote for new releases and new


Ted Dunning wrote
> I don't think that the number of inactive IPMC members is a factor in
> anything. They are, by definition, inactive.
> So I would vote for the no-op action (#4, I think).
> On Thu, Mar 7, 2019 at 3:39 PM Roman Shaposhnik &lt;

> roman@

> &gt;
> wrote:
>> On Thu, Mar 7, 2019 at 3:33 PM Justin Mclean &lt;

> justin@

> &gt;
>> wrote:
>> >
>> > Hi,
>> >
>> > It’s been suggested that the IPMC is too large, what do other IPMC
>> members think might be a way to address this?
>> Personally, I believe that "IPMC is too large" argument is only
>> applicable
>> to
>> how quickly/easily consensus can be built. That's literally the only
>> situation
>> when the size of IPMC gets in the way (sometimes).
>> Is anyone aware of any other situations where "IPMC is too large"
>> argument
>> is actually legit?
>> At any rate, the rest of my feedback will be from that single
>> perspective:
>> > Please discuss and indicate +1 what you would think would help, you can
>> vote for more than one.
>> >
>> > Some suggestions:
>> > 1. Ask all inactive IPMC if they want to continue being on the IPMC and
>> see who steps down. Being inactive they are probably not following this
>> list so we need to identify and send each one email them personally.
>> > 2. There were some questions around merit raised, remove all IPMC
>> members who were not on the initial proposal and who were voted in. Those
>> left on the IPMC vote back in those who are currently active.
>> > 3. Get rid of all IPMC members, and vote (with ASF members vote being
>> binding - not sure how else it could be done?) currently active ones back
>> in.
>> > 4. Do nothing as this is not actually a problem but instead address
>> other underlying issues. e.g. lack of mentor engagement.
>> I would like to suggest a 5th alternative (again this is from the
>> above's perspective):
>>    * Don't change anything, but for any situation that requires
>> consensus building just be a tad more formal with how we close loops
>> and track if we really get as many obstructionists as we thing that
>> the size of the IPMC allows. If not -- we don't have a problem.
>> > Also re point 2 do you think we should drop that ASF members can
>> automatically get IPMC membership and change it to requiring a vote by
>> the
>> IPMC? It’s has always seem odd to me that this is the case. We’ve
>> recently
>> voted more people in that we’ve had requests from ASF members.
>> >
>> > Any other sugestions?
>> >
>> > Options 2 and 3 may cause some issues around mentors, but if they were
>> not active then I guess it’s no big loss.
>> >
>> > And any suggestions on level of activity? Such as:
>> > - Emailed the list in the last year.
>> > - Reviewed at least one release in that time.
>> >
>> > It’s already been determined that some (about 15%) of the less than
>> active PMC members (out of the 100 odd that are not signed up to the IPMC
>> private list) do help out infrequently but that help is very useful. That
>> may also apply to other inactive IPMC members, so I would suggest the bar
>> for what consider active be kept low.
>> I honestly don't see how all of these options of getting people in and
>> out of IPMC can actually help with this consensus building thing. So
>> yeah -- I'd say #5.
>> Thanks,
>> Roman.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 

> general-unsubscribe@.apache

>> For additional commands, e-mail: 

> general-help@.apache


Sent from:

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

View raw message