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.el...@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_schae...@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 <a...@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" <u...@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-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
