On Mon, Aug 16, 2010 at 22:00, Noel J. Bergman <n...@devtech.com> wrote: > Greg Stein wrote: >... >> 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. > > How does that differ from the current system (given the assumption of 3+ PMC > Members), except that it precludes potential oversight from others -- the > flipside of "solves the peanut gallery problem" that apparently plagued > Subversion?
Presumably 3+ ASF Members is sufficient oversight. Given these Members are the ONLY PMC members, then they must also remain pretty active in their podling which implies oversight. "oversight from others" is NOT a goal, when you have 3+ PMC members already. My proposal ups that from "3+ PMC members" to "3+ ASF Members", which (IMO) is a stronger guarantee. (tho, for the most part, IPMC members *are* ASF Members, but Joe's recent suggestions (which are good!) would alter that balance) And do not minimize the peanut gallery problem. That is a very real issue, and the "flipside" as you suggest is not a necessary part of the process. >> 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". > > Yes. You can do that today, too, with 3+ PMC Members. Empirically speaking... no, you cannot. The peanut gallery gets in the way. >> 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. > > We could do that now, except that people have previously disliked the idea > of $podling.apache.org being provided prior to graduation, for either e-mail > or web site addresses. If the consensus is to change that, fine. I'm not asking for consensus. I'm proposing a whole new approach. And this particular approach minimizes the "external effects" of graduation: no mailing list renames, no subversion moves, no reporting moves, etc. >> 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). > > Please clarify. Wouldn't the Board have to establish this TLP > pre-Incubation, Yes. Thus, my point that the Board is going to have to weigh in on this topic at some point. But it needs some rounds of support and beat-downs here on general@ before it is in a reasonable proposal state for the Board. We also need some podlings who would like to volunteer for this new approach, for the Board to consider. > what *are* the graduation metrics, and who votes on > graduation? Dunno. I raised that in my original email. I suspect that the metrics would be defined by the Incubator: basically the checklist of considerations already present. Regarding the vote: as I mentioned: the PMC comprised of the ASF Members. It is possible that the PMC might add some non-Members over time (like a regular PMC can and does), but I'm not very supportive of this for projects in a *podling* state. I'd rather all those people are added to the PMC at graduation time. There could be two ways to graduate: 1) the PMC self-graduates 2) the PMC proposes graduation to the Board I prefer the latter, as a final checkup/signoff to the process. The PMC would need to arrive with $materials demonstrating satisfactory completion of all incubation requirements. Note: if *all* podlings move to this process, then the Incubator would reduce to docs rather than oversight; which could imply a merge into ComDev. But as I mentioned: I'm not sure the Members requirement is a bar that most podlings can reach, so the Incubator is not going anywhere, any time soon. >> 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?" > > Why relax them uniquely for such projects? And presumably we are protecting Dunno. The question was raised, and it is a good question for discussion. What *are* we attempting to protect by limiting releases from podlings? Does that hold in this scenario? Are there other modifications to the restrictions that can occur for these TLP-podlings? etc. A discussion points, nothing much more than that. > the ASF brand, as well as downstream consumers who rely on our output, > including clean licensing, etc. But getting back to the first point, is > there some rationale to relax them for these podlings and not for others? > If we can justify them for some, should we re-examine them in general? Yup, good questions all. It was a fair point raised on IRC that I'm bringing here. >> Using this model decentralizes the process > > So does having 3+ PMC Members today. The IPMC is anything but decentralized. And empirical evidence shows it to peanut-gallery-ism. >> removes vocal minorities > > True. The flipside is that it also removes additional oversight. Remember > that the Board created the Incubator because of problems with existing > projects trying incubation on their own. But we have learned a lot since > then. Yups. The Incubator has provided a lot of focus on what we need, what kinds of problems arise, and what we don't need. I maintain that "additional oversight" is not required given the composition of these TLPs membership (all ASF Members). So there is no real loss in this proposed construct. Just a high bar of involvement to *get* there. >> allows for better tuning of a PMC process to its community, and breaks >> down the Incubator umbrella project. > > Possibly so, which would be good things. Yup. Reference Justin's point about the Subversion PMC not recognizing their own self-governance. Their initial introduction to the ASF put them at the mercy of an invisible and nebulous group called "the Incubator Project Management Committee". If the initial intro was a self-governing PMC, then I think we wouldn't have the same kinds of (admittedly minor) problems with queries about how to get certain things done, or if they were allowed. >> 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 > >> Thoughts? > > I think that it is a very interesting proposal, that could work very well in > specific circumstances, and I'd be willing to see it tried as an experiment, > if the Board buys into it. Do we have any such projects pending or already > in the Incubator? I suspect the OODT guys might want to try this (it has four ASF Members as Mentors who could comprise the PMC). Subversion would have done this, based on my own thoughts/experiences and knowledge of what the ASF needs/wants. Cheers, -g --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
