Then lets disambiguate by not referring to the
“IP Stewards” as being the PPMC. Seems simple
enough.
On Nov 19, 2013, at 4:34 AM, ant elder <ant.elder@gmail.com> wrote:
> The reason it might be dis-empowering is that currently one of the main
> roles of the PPMC is voting in new committers so if the PPMC is initially
> just the mentors then the other podling members wont be involved in that.
> It might still be worth trying the approach as an experiment if a willing
> podling can be found, but i doubt all new podlings would be very happy with
> the approach.
>
> ...ant
>
>
>
> On Mon, Nov 18, 2013 at 12:12 PM, Joseph Schaefer <joe_schaefer@yahoo.com>wrote:
>
>> I don’t see how the situation is any worse
>> than it is now, where no one on the project
>> currently has a binding vote on a release.
>> Going from that to “a few” may seem unfair,
>> but we have to start somewhere and we need
>> to keep in mind that this is partly a training
>> exercise, where we need to see people actually
>> demonstrate good judgement on policy matters.
>>
>> Unfortunately this doesn’t solve the bootstrapping
>> issue directly with the first release, unless we
>> use it as a remedy for letting release votes stall.
>>
>>
>> On Nov 18, 2013, at 6:41 AM, Andy Seaborne <andy@apache.org> wrote:
>>
>>> On 17/11/13 11:17, Upayavira wrote:
>>>>
>>>>
>>>> On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote:
>>>>>
>>>>>
>>>>> On 11/16/13 8:47 AM, "Upayavira" <uv@odoko.co.uk> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alex,
>>>>>>
>>>>>> I'm not sure I see the difference between a release auditor and an
>> IPMC
>>>>>> member. If someone is sufficiently clued up to audit a release, then
>>>>>> they're surely ready to join the Incubator PMC. Am I missing
>> something?
>>>>> To me, there is more responsibility in being on the IPMC, like
>> reviewing
>>>>> proposals for new podlings and voting on their graduation and becoming
>> a
>>>>> mentor. Personally, that's why I don't want to be on the IPMC, but I
>>>>> might be willing to help IP audit a podling's release. Just like some
>>>>> projects don't have all committers on the PMC, a Release Auditor is
>> just
>>>>> someone who can do that specific task, and there is no need to vote
>> them
>>>>> in if they are already on some other TLP PMC because any member of a
>> TLP
>>>>> PMC supposedly knows how to do release auditing.
>>>>>
>>>>>>
>>>>>> My interest is in a lesser level of involvement, where someone has
>> shown
>>>>>> merit within their own PPMC and can get a binding vote there, but
>>>>>> no-where else. That feels to me like a very useful intermediate step
>> to
>>>>>> have.
>>>>> I agree, except for the no-where else part. If you know how to check
a
>>>>> RAT report and have an idea of what should be in the NOTICE files, you
>>>>> should be able to help out any other podling by reviewing their release
>>>>> and casting a binding vote so they can learn how to do that. I'd say
>>>>> that
>>>>> 3 IPMC members must vote to give a person Release Auditor status if
>> they
>>>>> are not already on a TLP PMC. Consider this: I am an the Flex PMC but
>>>>> not the IPMC, but if I join the PPMC of some new podling, why
>> shouldn't I
>>>>> be able to cast a binding vote for that podling's releases?
>>>>
>>>> With a two tier model - with PPMC membership granting voting rights on
>>>> podling releases, then a podling would start with just mentors on its
>>>> PPMC. If you clearly knew what you were doing, you'd get voted onto the
>>>> PPMC pretty quickly, and thus you'd be able to vote on your releases.
>>>
>>> I am concerned that it would be dis-empowering to the incoming community
>> if at least the active and major developers of the podling were not on the
>> PPMC at the start.
>>>
>>> Andy
>>>
>>>>
>>>> Upayavira
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
|