Sorry if I'm late to the party, but my 2 cents... The more I read about this, the more I latch onto Justin's "Observers" notion. As a non-Apache Member, non-IPMC, PPMC member for OODT, I feel like I am qualified to vote on a release in the sense that I am closer to the code than Justin (sorry to pick on you, but I think I'm just parroting what you have been saying), but I also would love to have more experienced hands looking at other aspects (most notably in my mind are the various legal aspects).
In the end, I think that it takes both of these types of input to get what I'd call an "informed" vote. But all of this discussion in my mind hinges on the fundamental problems... good mentors and the notion of etiquette, both of which have previously been mentioned on all of these intwined threads. Realistically, as long as an individual podling is open to the entire incubation community, you will find some rules hawk that really believes by invoking article 237 of document XYZ they are helping to instruct in the Apache way. It's in cases where this happens that I would ask a mentor (someone I know who has even a slight investment in my podling's success), to sort the wheat from the chaff. Also MHO, but it strikes me that being part of the community, rather than in some sort of over-lord position, is more in line with the flat structure that is an important part of the Apache way. > If we ran it with the intention that the PMC is there to solely > provide non-technical oversight and that the PPMC does the actual > work, I think that's something I could live with and address my > concerns in the overall process. +1. Being the kind of person who likes to trust people, I'm fine with a informal agreement. If you feel like you can contribute technically, then I would love to hear what you had to say and if you just want to comment on process, I think that's A-OK too. IMO, as long as you have taken some step to be part of the specific podling, then you get to say anything you want (you are part of the community). Like Chris, I would be up for trying something with OODT. Any proposal that we can work, even if just by general agreement, where we can logically divide technical oversight from non-technical and also protect us from random drive-bys gets my vote. -Dave On Aug 16, 2010, at 10:37 PM, Justin Erenkrantz wrote: > On Mon, Aug 16, 2010 at 10:20 PM, Greg Stein <gst...@gmail.com> wrote: >> You know when to vote and *how* to vote. I see no reason to deny your vote. > > Of course. It's always seemed awkward if you can't contribute > technically to suddenly have a binding vote. I'm sure if I *wanted* > to learn how to build something with Maven, I could. But, why? =) > > So, it makes me leery on being forced to cast a vote on a release - on > par with those who have actually tested it and know something about > the codebase. The standard that I force myself to adhere to on > Subversion and httpd for example would be something that I'd fall > short with in OODT. > >> The (only) problem to arise would be if OODT was at the minimum of (3) >> ASF Members, and your vote was required. With Chris becoming a Member, >> OODT is at 5 Members that could comprise the mini/pseudo TLP that I >> propose. (maybe there are others interested, but I have zero insight >> into this community) > > Sure. It's just that Chris and I have discussed the pain points in > the Incubation process, so we're on the lookout for making it easier > on us. =) Plus, the experience with Subversion also showed me where > things break down too. > >> I'm not sure that I'm reading the above properly, but... whatevs. >> Under my proposed TLP-based approach, the PMC would be comprised of: >> justin, jean, ross, ian, chris. The current committers (who are also >> on the PPMC, presumably) would be invited to the private@ list, but >> would not be on the PMC. Thus, they would have non-binding votes >> across all project decisions. But that should not be a problem as >> those PMC members also understand how to build and listen to >> consensus. If there are issues in the community, then the difference >> between binding and non-binding votes makes *zero* difference. > > If we ran it with the intention that the PMC is there to solely > provide non-technical oversight and that the PPMC does the actual > work, I think that's something I could live with and address my > concerns in the overall process. > > I don't think this is at odds with what you are saying nor would it > run afoul of any corporate structures. It could just be the informal > agreement between the PMC members that the PPMC should be the ones > making the technical decisions. (If some other set of mentors wanted > to run it differently, they could. But, this separation is one I > could live with myself.) > >> The (podling) project/PMC would report directly to the Board. No more >> peanut gallery, or a second-guessing group. > > Right. The listed members of the PMC are on the line dealing with the > Board. (Hmm...would the PMC require a VP? I guess so.) If the Board > has an issue with how they are running things, the Board can chime in. > >> I do agree there is a lot of hand-waving around "how to graduate", but >> I presume that the community can figure that out and provide >> information for future projects and communities. > > I very much like the Incubator providing what the general checklist > form would look like. The Board could receive the checklist, review > it, and then vote on the Graduation resolution. > > It'd also raise the oversight of the podlings (in this structure) back > to the Board...which is likely a good thing so as things don't get > hidden. -- justin
