There is some obvious compromises opportunity here. On releases, the iPMC could decide, by internal convention, to let the involved three mentors (when there are three involved members) be the relevant voice. iPMC members could pledge to defer to the involved mentors unless they feel that there is some overwhelming reason to vote -1.
On committers there is a legal / procedural clarification called for. Perhaps I'm just dense, but I got the strong impression from the recent email at members@ that there was much more flexibility possible with committer status than with releases -- that the iPMC could indeed make a one-time, blanket, decision, that PPMC votes were sufficient for committer status. To cite an example to support my position, I'm pretty sure that GSOC students get commit privileges without formal PMC votes. However, if I am dense, and if the foundation requirements do require a real PMC vote for committer access, then the idea of my first paragraph would apply. On Mon, Aug 16, 2010 at 1:43 PM, Justin Erenkrantz <jus...@erenkrantz.com>wrote: > On Mon, Aug 16, 2010 at 10:37 AM, Noel J. Bergman <n...@devtech.com> > wrote: > > Where are you seeing this "over-reach" problem to which you refer? I > have > > heard of a few isolated incidents, and those can be addressed. But by > far > > and way, the biggest complaint is LACK of involvement, e.g., > ... > > And most cases of PMC members getting involved in projects of which they > > aren't a Mentor have been with respect to release packaging, where the > > involvement has generally been valid and valuable, even if bothersome to > > those whose packages weren't quite up to snuff. > > > > But, seriously, if there is systemic overreaching, lets address *that* > > issue. > > The cases of "overreaching" in Subversion and OODT related to adding > new committers - not releases. So, I'm definitely in favor of Joe's > proposal to let the PPMC have control over who gets to be in the > community. -- justin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
