On Mon, Aug 16, 2010 at 12:45, Justin Erenkrantz <jus...@erenkrantz.com> wrote: > On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman <n...@devtech.com> wrote: >> And if the Mentors aren't being active, voting, etc., then *that* is what >> needs to be addressed. > > As I've repeatedly stated before (here and elsewhere), in the podlings > I've been recently involved with, having three mentors isn't the > issue. It's the PMC members who aren't involved sticking their nose > in and trying to poison the community. > >> We have one of the largest PMCs in the ASF. If we > > I view this as potentially the crux of the problem - people who aren't > stakeholders in the community shouldn't have a say. Right now, they > feel they do. So, if we want to mandate at least 3 mentors - fine, > but that must come at the cost of telling the rest of the IPMC to go > away - unless they actively contribute to the community and earn > merit...of course. -- justin
I threw out a radical idea on IRC and a few of us walked through it. At its core, it solves the "peanut gallery" problem that you're talking about. Consider this: Make the podling a TLP comprised of *only* ASF Members, with at least *three* minimum (preferably more, to deal with idle times). The podling committers are invited onto the priv...@$podling.apache.org mailing list, but have non-binding votes. They are there for private discussion, to offer non-binding votes on committers, and to "see" how a private mailing is used and how it is NOT used. Since you have (at least) three people on the PMC, you can accomplish all necessary business: releases, adding accounts, and deciding to ask the Board for your "graduation". The mailing lists can be in the "right place", but can have footers attached noting the "incubation" status. The $podling.apache.org website "should" redirect to (say) incubator.apache.org/projects/$podling and have all the standard disclaimers. At graduation, they get the apache.org site and a few redirects are put in place. Releases should also have all the same caveats, warnings, and disclaimers. Graduation could simply be a TLP deciding to add the rest of the committers to its PMC and asking infrastructure to create the website, etc. Or it could require a Board resolution which also mass-adds PMC members. It's kind of unclear how much oversight the Board should have on the graduation (note that the (pseudo) TLP will be filing reports just like any other TLP, so the Board sees its progress). This pattern can be documented by the Incubator or the Community Development project. Doesn't matter, but it would certainly be standardized much like we're standardizing within the Incubator itself. Restrictions like those on websites or releases could be relaxed. It was a fair question to ask, "why keep those in place? what are we trying to protect?" Using this model decentralizes the process, removes vocal minorities, allows for better tuning of a PMC process to its community, and breaks down the Incubator umbrella project. Finding 3+ Members to be on these mini/pseudo TLPs would be quite difficult. I don't think this kind of process would be available or workable to *all* podlings. But for projects with active Member support, this could be a valid approach (tho what does it say about projects without this kind of active support?). Obviously, we'd also need Board buy-in for the construction of these TLPs (tho, it *is* only comprised of Members). Thoughts? Cheers, -g --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
