Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
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
Re: Radical revamp (was: an experiment)
On 17 Aug 2010, at 03:31, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 10:00:40 PM Subject: RE: Radical revamp (was: an experiment) Greg Stein wrote: Using this model decentralizes the process So does having 3+ PMC Members today. To me this is a common flaw in both how the IPMC operates today and how Greg's proposal relies on 3 Members to get anything accomplished. If you've been paying attention to what actually happens in this PMC over time, you can't possibly have missed all the begging for votes that goes on. Reliance on 3 overworked people who are typically not podling committers to always be there when the project needs them is both unrealistic and doesn't scale. We've been doing it for years, inflicting massive pain on the podlings whenever they release or want new committers, and it sucks. That's what my experiment aims to fix. I believe that not having three mentors interested enough to provide oversight on key issues indicates the project is not as valid as we might think. There is a reverse side of the too much oversight coin. People sometimes vote +1 without providing the checks. That being said this solution is not one that s perfect. Ross - 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
Re: Radical revamp (was: an experiment)
On 17 Aug 2010, at 03:53, Joe Schaefer joe_schae...@yahoo.com wrote: It's optimized for success while making mentors potentially responsible for failure (iow a project with crappy mentors will fail no matter how much they grok apache). Still have doubts about escalating the graduation decision to the board. I don't see this proposal replacing the IPMC. The project can turn there for help if they choose (eg our mentors are absent). I see the IPMC role becoming more of a training ground for mentors than a police force. Sent from my iPhone On Aug 16, 2010, at 10:46 PM, Greg Stein gst...@gmail.com wrote: On Mon, Aug 16, 2010 at 22:31, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 10:00:40 PM Subject: RE: Radical revamp (was: an experiment) Greg Stein wrote: Using this model decentralizes the process So does having 3+ PMC Members today. To me this is a common flaw in both how the IPMC operates today and how Greg's proposal relies on 3 Members to get anything accomplished. If you've been paying attention to what actually happens in this PMC over time, you can't possibly have missed all the begging for votes that goes on. Reliance on 3 overworked people who are typically not podling committers to always be there when the project needs them is both unrealistic and doesn't scale. We've been doing it for years, inflicting massive pain on the podlings whenever they release or want new committers, and it sucks. That's what my experiment aims to fix. I hear you, and I think that *if* you have 3+ *active* ASF Members, then my approach will dramatically improve the process. Also, those Members in the hot seat are going to be more active because they *know* they're on the hook. There is nobody to pass the buck to. They are part of the reports to the Board (One of our PMC Members, John Doe, has been absent.). If a project has the support, then this gets the second-guessing of the IPMC and the second-level of unnecessary oversight out of the way. It directly introduces the project to its future place within the organization. Cheers, -g - 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
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
Unlike the observer role. It's very close to the current signing off of board reports by mentors but forces them to do a little more than put there name to a piece of electronic paper. Personally I imagined my binding vote, as a mentor, to indicate a) the project debs want this tongi ahead and b) in my opinion it is sat for the ASF and the project to proceed. I didn't imagine my vote having anything to do with the technical aspects of the project (unless also a committer of course) This is what the board do when approving project reports right? It's about social an community health not technical health, right? Sent from my mobile device. On 17 Aug 2010, at 05:56, Justin Erenkrantz jus...@erenkrantz.com wrote: [ CCing gene...@incubator as I think I can now place my finger a bit as to why I'm discomforted with Greg's proposal in the OODT context ; and more importantly, another potential experiment at the end; leaving context in for those on gene...@incubator ] On Mon, Aug 16, 2010 at 9:21 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: (moving to oodt-...@incubator.a.o, context coming in separate email FWD) Hey Justin, +1 from me with my OODT hat on. Also, I like Greg's proposal b/c it puts the onus on those (proposed) $podling.apache.org PMC members who are active, without external peanut gallery oversight. However, I think we should probably have a discussion on the OODT list as we should think through what this means and how it'd affect the nascent community. With Subversion, it already had a very vibrant, diverse, and self-governing community - OODT isn't quite there so there's a bit of a risk there. Perhaps this will act as a prod to promote the self-governance - which is ideally what we want anyway. +1 At the moment, I probably don't have the time necessary to sit down and lead the conversation within OODT. That alone does give me a bit of a reservation about what exactly we're signing up for. =) -- To me, all we are signing up for with Greg's proposal is basically to have something like: 1. oodt.apache.org exists today 2. Ian, Chris, Justin and Jean Frederic are OODT PMC members + committers 3. OODT committers continue as-is 5. There is no more IPMC oversight 5. VOTEs on releases are approved by 3 +1s of OODT PMC members - OODT committers weigh in on releases and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 6. VOTEs on new committers are approved by 3 +1s of OODT PMC members - OODT committers weigh in on new committers and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 7. When we're ready (we can even keep the same Incubator checklist), we put up a board resolution to graduate into *true* oodt.apache.org TLP. To me, ready = - we've made at least 1 release (we're close!) - we've VOTE'd in a couple new committers (keep those patches coming people!) hopefully with some diversity in mind, but if we don't get there, and the committers are still vibrant and healthy, then we move forward. OODT already has a pretty vast user community and healthy community that I'm slowing working to get signed up over here in the Incubator. We've had contributions from folks from Children's Hospital (thanks guys!), interest from other NASA centers (welcome Mark and others!), and some new folks from JPL stepping up and earning merit (welcome Cameron, and thanks for popping up Rishi!). Is that your take too? Yes, I think that roughly outlines what Greg proposed. See, here's where I get a bit discomforted by this entire process: I honestly don't feel that I deserve a vote on OODT releases. I've known you and Dave for long enough that I have no concerns advising the OODT community and trying to help out - but...giving me a binding vote? I want to encourage a process where the people doing the work get to have the power. At the core, that is what Apache is about - and having doofus's like me casting a vote for a release seems like straying from that. I'm *totally* fine turning on cranky mode and keeping the peanut gallery away so ya'll on oodt-dev@ get real work done. For Subversion, I was already a full committer and earned my merit. So, I had zero qualms about giving my $.02 there whether they wanted it or not. =) Given your (Chris) experience with other ASF projects (and, heck, being a PMC Chair), I can see exactly how the Subversion analogy (in my head) applies to you. You're a member, you know how things work, you have merit within OODT - so, yah, perfect sense. Smucks like me who get confuzzled reading Maven build scripts? Nah, not right that I should have a binding vote. Now, could we say that I would act as a certifier/observer that all of the major processes were followed? Heck yah. No qualms there. Here's an analogy I'm coming around to: in
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
Sorry damned iPhone autocorrect. First word should be I like Sent from my mobile device. On 17 Aug 2010, at 09:38, Ross Gardler rgard...@apache.org wrote: Unlike the observer role. It's very close to the current signing off of board reports by mentors but forces them to do a little more than put there name to a piece of electronic paper. Personally I imagined my binding vote, as a mentor, to indicate a) the project debs want this tongi ahead and b) in my opinion it is sat for the ASF and the project to proceed. I didn't imagine my vote having anything to do with the technical aspects of the project (unless also a committer of course) This is what the board do when approving project reports right? It's about social an community health not technical health, right? Sent from my mobile device. On 17 Aug 2010, at 05:56, Justin Erenkrantz jus...@erenkrantz.com wrote: [ CCing gene...@incubator as I think I can now place my finger a bit as to why I'm discomforted with Greg's proposal in the OODT context ; and more importantly, another potential experiment at the end; leaving context in for those on gene...@incubator ] On Mon, Aug 16, 2010 at 9:21 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: (moving to oodt-...@incubator.a.o, context coming in separate email FWD) Hey Justin, +1 from me with my OODT hat on. Also, I like Greg's proposal b/c it puts the onus on those (proposed) $podling.apache.org PMC members who are active, without external peanut gallery oversight. However, I think we should probably have a discussion on the OODT list as we should think through what this means and how it'd affect the nascent community. With Subversion, it already had a very vibrant, diverse, and self-governing community - OODT isn't quite there so there's a bit of a risk there. Perhaps this will act as a prod to promote the self-governance - which is ideally what we want anyway. +1 At the moment, I probably don't have the time necessary to sit down and lead the conversation within OODT. That alone does give me a bit of a reservation about what exactly we're signing up for. =) -- To me, all we are signing up for with Greg's proposal is basically to have something like: 1. oodt.apache.org exists today 2. Ian, Chris, Justin and Jean Frederic are OODT PMC members + committers 3. OODT committers continue as-is 5. There is no more IPMC oversight 5. VOTEs on releases are approved by 3 +1s of OODT PMC members - OODT committers weigh in on releases and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 6. VOTEs on new committers are approved by 3 +1s of OODT PMC members - OODT committers weigh in on new committers and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 7. When we're ready (we can even keep the same Incubator checklist), we put up a board resolution to graduate into *true* oodt.apache.org TLP. To me, ready = - we've made at least 1 release (we're close!) - we've VOTE'd in a couple new committers (keep those patches coming people!) hopefully with some diversity in mind, but if we don't get there, and the committers are still vibrant and healthy, then we move forward. OODT already has a pretty vast user community and healthy community that I'm slowing working to get signed up over here in the Incubator. We've had contributions from folks from Children's Hospital (thanks guys!), interest from other NASA centers (welcome Mark and others!), and some new folks from JPL stepping up and earning merit (welcome Cameron, and thanks for popping up Rishi!). Is that your take too? Yes, I think that roughly outlines what Greg proposed. See, here's where I get a bit discomforted by this entire process: I honestly don't feel that I deserve a vote on OODT releases. I've known you and Dave for long enough that I have no concerns advising the OODT community and trying to help out - but...giving me a binding vote? I want to encourage a process where the people doing the work get to have the power. At the core, that is what Apache is about - and having doofus's like me casting a vote for a release seems like straying from that. I'm *totally* fine turning on cranky mode and keeping the peanut gallery away so ya'll on oodt-dev@ get real work done. For Subversion, I was already a full committer and earned my merit. So, I had zero qualms about giving my $.02 there whether they wanted it or not. =) Given your (Chris) experience with other ASF projects (and, heck, being a PMC Chair), I can see exactly how the Subversion analogy (in my head) applies to you. You're a member, you know how things work, you have merit within OODT - so, yah, perfect sense. Smucks like me who get confuzzled reading Maven build scripts? Nah, not right that I should have a binding vote. Now,
Re: Radical revamp (was: an experiment)
- Original Message From: Ross Gardler rgard...@apache.org To: general@incubator.apache.org general@incubator.apache.org Cc: general@incubator.apache.org general@incubator.apache.org Sent: Tue, August 17, 2010 4:14:02 AM Subject: Re: Radical revamp (was: an experiment) On 17 Aug 2010, at 03:53, Joe Schaefer joe_schae...@yahoo.com wrote: It's optimized for success while making mentors potentially responsible for failure (iow a project with crappy mentors will fail no matter how much they grok apache). Still have doubts about escalating the graduation decision to the board. I don't see this proposal replacing the IPMC. The project can turn there for help if they choose (eg our mentors are absent). I see the IPMC role becoming more of a training ground for mentors than a police force. Well isn't that what the IPMC is supposed to be right now? Isn't that why we encourage IPMC members to participate in discussions about our podlings? How do we expect people to learn without dialog and discussion- by reading our constantly- in-need-of-attention docs? I have said this several times in the past, and I'll say it again: I'd bet over half of the Apache Membership could use a refresher course on Apache release policy. I've read enough mistaken remarks about it both here and across several other Apache lists, including from ex-board members, that I'm sure I'd win that bet were someone to take me up on it. That is why I went through the trouble of improving the release management docs here in the Incubator, but do those docs ever get read by mentors? Getting back to your point, we're not supposed to be a police force, and I can't help but think that some of the complaints about people's authority being questioned here is actually a useful exercise in Apache governance. It's only the tone of those remarks that is sometimes offputting IMO, not the content. As Greg likes to say: educate, don't bitch. And I see those moments as educational opportunities. OTOH there has always been a sense of the mentors playing the role of protecting their podlings from the wolves in the Incubator. (Perhaps that's what you're driving at with your police force remarks.) Hell at one point we even had documentation to that effect. The idea behind it being that the IPMC guards the org's interests where the mentors advocate for their projects, and in the balance podlings learn something about that style of governance. Unfortunately that model doesn't appear anywhere else in the org, so those lessons may not be particularly useful to them once they graduate. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
LOL know problem Ross ;) On 8/17/10 1:46 AM, Ross Gardler rgard...@apache.org wrote: Sorry damned iPhone autocorrect. First word should be I like Sent from my mobile device. On 17 Aug 2010, at 09:38, Ross Gardler rgard...@apache.org wrote: Unlike the observer role. It's very close to the current signing off of board reports by mentors but forces them to do a little more than put there name to a piece of electronic paper. Personally I imagined my binding vote, as a mentor, to indicate a) the project debs want this tongi ahead and b) in my opinion it is sat for the ASF and the project to proceed. I didn't imagine my vote having anything to do with the technical aspects of the project (unless also a committer of course) This is what the board do when approving project reports right? It's about social an community health not technical health, right? Sent from my mobile device. On 17 Aug 2010, at 05:56, Justin Erenkrantz jus...@erenkrantz.com wrote: [ CCing gene...@incubator as I think I can now place my finger a bit as to why I'm discomforted with Greg's proposal in the OODT context ; and more importantly, another potential experiment at the end; leaving context in for those on gene...@incubator ] On Mon, Aug 16, 2010 at 9:21 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: (moving to oodt-...@incubator.a.o, context coming in separate email FWD) Hey Justin, +1 from me with my OODT hat on. Also, I like Greg's proposal b/c it puts the onus on those (proposed) $podling.apache.org PMC members who are active, without external peanut gallery oversight. However, I think we should probably have a discussion on the OODT list as we should think through what this means and how it'd affect the nascent community. With Subversion, it already had a very vibrant, diverse, and self-governing community - OODT isn't quite there so there's a bit of a risk there. Perhaps this will act as a prod to promote the self-governance - which is ideally what we want anyway. +1 At the moment, I probably don't have the time necessary to sit down and lead the conversation within OODT. That alone does give me a bit of a reservation about what exactly we're signing up for. =) -- To me, all we are signing up for with Greg's proposal is basically to have something like: 1. oodt.apache.org exists today 2. Ian, Chris, Justin and Jean Frederic are OODT PMC members + committers 3. OODT committers continue as-is 5. There is no more IPMC oversight 5. VOTEs on releases are approved by 3 +1s of OODT PMC members - OODT committers weigh in on releases and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 6. VOTEs on new committers are approved by 3 +1s of OODT PMC members - OODT committers weigh in on new committers and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 7. When we're ready (we can even keep the same Incubator checklist), we put up a board resolution to graduate into *true* oodt.apache.org TLP. To me, ready = - we've made at least 1 release (we're close!) - we've VOTE'd in a couple new committers (keep those patches coming people!) hopefully with some diversity in mind, but if we don't get there, and the committers are still vibrant and healthy, then we move forward. OODT already has a pretty vast user community and healthy community that I'm slowing working to get signed up over here in the Incubator. We've had contributions from folks from Children's Hospital (thanks guys!), interest from other NASA centers (welcome Mark and others!), and some new folks from JPL stepping up and earning merit (welcome Cameron, and thanks for popping up Rishi!). Is that your take too? Yes, I think that roughly outlines what Greg proposed. See, here's where I get a bit discomforted by this entire process: I honestly don't feel that I deserve a vote on OODT releases. I've known you and Dave for long enough that I have no concerns advising the OODT community and trying to help out - but...giving me a binding vote? I want to encourage a process where the people doing the work get to have the power. At the core, that is what Apache is about - and having doofus's like me casting a vote for a release seems like straying from that. I'm *totally* fine turning on cranky mode and keeping the peanut gallery away so ya'll on oodt-dev@ get real work done. For Subversion, I was already a full committer and earned my merit. So, I had zero qualms about giving my $.02 there whether they wanted it or not. =) Given your (Chris) experience with other ASF projects (and, heck, being a PMC Chair), I can see exactly how the Subversion analogy (in my head) applies to you. You're a member, you know how things work, you have merit within OODT - so, yah, perfect sense. Smucks like me who get confuzzled reading Maven build scripts?
Radical revamp (was: an experiment)
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
RE: Radical revamp (was: an experiment)
Greg Stein wrote: Justin Erenkrantz wrote: 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. 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. 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? 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. 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. 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, what *are* the graduation metrics, and who votes on graduation? 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 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? Using this model decentralizes the process So does having 3+ PMC Members today. 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. 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. 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? --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
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,
Re: Radical revamp (was: an experiment)
- Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 10:00:40 PM Subject: RE: Radical revamp (was: an experiment) Greg Stein wrote: Using this model decentralizes the process So does having 3+ PMC Members today. To me this is a common flaw in both how the IPMC operates today and how Greg's proposal relies on 3 Members to get anything accomplished. If you've been paying attention to what actually happens in this PMC over time, you can't possibly have missed all the begging for votes that goes on. Reliance on 3 overworked people who are typically not podling committers to always be there when the project needs them is both unrealistic and doesn't scale. We've been doing it for years, inflicting massive pain on the podlings whenever they release or want new committers, and it sucks. That's what my experiment aims to fix. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
Hey Guys, 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. +1 from me with my OODT hat on. Also, I like Greg's proposal b/c it puts the onus on those (proposed) $podling.apache.org PMC members who are active, without external peanut gallery oversight. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
On Mon, Aug 16, 2010 at 22:31, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 10:00:40 PM Subject: RE: Radical revamp (was: an experiment) Greg Stein wrote: Using this model decentralizes the process So does having 3+ PMC Members today. To me this is a common flaw in both how the IPMC operates today and how Greg's proposal relies on 3 Members to get anything accomplished. If you've been paying attention to what actually happens in this PMC over time, you can't possibly have missed all the begging for votes that goes on. Reliance on 3 overworked people who are typically not podling committers to always be there when the project needs them is both unrealistic and doesn't scale. We've been doing it for years, inflicting massive pain on the podlings whenever they release or want new committers, and it sucks. That's what my experiment aims to fix. I hear you, and I think that *if* you have 3+ *active* ASF Members, then my approach will dramatically improve the process. Also, those Members in the hot seat are going to be more active because they *know* they're on the hook. There is nobody to pass the buck to. They are part of the reports to the Board (One of our PMC Members, John Doe, has been absent.). If a project has the support, then this gets the second-guessing of the IPMC and the second-level of unnecessary oversight out of the way. It directly introduces the project to its future place within the organization. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
It's optimized for success while making mentors potentially responsible for failure (iow a project with crappy mentors will fail no matter how much they grok apache). Still have doubts about escalating the graduation decision to the board. Sent from my iPhone On Aug 16, 2010, at 10:46 PM, Greg Stein gst...@gmail.com wrote: On Mon, Aug 16, 2010 at 22:31, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 10:00:40 PM Subject: RE: Radical revamp (was: an experiment) Greg Stein wrote: Using this model decentralizes the process So does having 3+ PMC Members today. To me this is a common flaw in both how the IPMC operates today and how Greg's proposal relies on 3 Members to get anything accomplished. If you've been paying attention to what actually happens in this PMC over time, you can't possibly have missed all the begging for votes that goes on. Reliance on 3 overworked people who are typically not podling committers to always be there when the project needs them is both unrealistic and doesn't scale. We've been doing it for years, inflicting massive pain on the podlings whenever they release or want new committers, and it sucks. That's what my experiment aims to fix. I hear you, and I think that *if* you have 3+ *active* ASF Members, then my approach will dramatically improve the process. Also, those Members in the hot seat are going to be more active because they *know* they're on the hook. There is nobody to pass the buck to. They are part of the reports to the Board (One of our PMC Members, John Doe, has been absent.). If a project has the support, then this gets the second-guessing of the IPMC and the second-level of unnecessary oversight out of the way. It directly introduces the project to its future place within the organization. Cheers, -g - 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
RE: Radical revamp (was: an experiment)
Greg Stein wrote: Noel J. Bergman 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). 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. Well, that has been an issue with many podlings so far. Subversion is an exception, not the rule, although I don't know that we've got a handle on the ratio of projects for which getting 3 binding votes isn't an issue. My proposal ups that from 3+ PMC members to 3+ ASF Members, which (IMO) is a stronger guarantee. Greg, *the* most common problem has been IP and release related. RAT has fixed a lot of it, but ASF Members were not even remotely immune to the problem. Without RAT, I suspect we'd still be mired in the muck, and needing as many eyes as we've had. And do not minimize the peanut gallery problem. That is a very real issue I'd really like to know how widespread it is, other than that it bit a burr under the saddle of some ASF Members on a few projects. And I'm still not minimizing its impact on even a single project, just wondering about prevalence. Empirically speaking... no, you cannot. The peanut gallery gets in the way. Let's agree to resolve the peanut gallery issue, and move on to see if there are any other issues. 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. Yes, but we still need to find out of the Board will agree to providing $X.apache.org resources, and branding, for provisional projects. 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. Well, if it isn't clear, I'm not trying to tear this down on you, and if OODT wants to give it a go, I'd support the experiment. But don't we first need to address ... what *are* the graduation metrics, and who votes on graduation? I suspect that the metrics would be defined by the Incubator: basically the checklist of considerations already present. 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. Is there any role for the Incubator, or is it strictly between the podling and the Board for this class of podling? 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 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. Fair enough. :-) 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. Empirical evidence also shows that we rarely hear from most projects except when they need binding votes or put in a report. Again, I agree with your idea of polling the community. 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). I may agree with you now, given RAT. As I've noted before, ASF Members have not been immune to release issues. And hopefully we won't come back to realize that not all ASF Members aren't good at project building. Not every ASF Member is you, Justin, Roy, Bertrand, Jukka, etc. I'm not even sure that most are. Reference Justin's point about the Subversion PMC not recognizing
Re: Radical revamp (was: an experiment)
On Mon, Aug 16, 2010 at 22:53, Joe Schaefer joe_schae...@yahoo.com wrote: It's optimized for success while making mentors potentially responsible for failure (iow a project with crappy mentors will fail no matter how much they grok apache). Fair assessment, but those *are* the projects that I'm looking at. Those which have large enough Member support, can be fully self-supported. But you raise a larger question: if a project has crappy mentors, then how do we solve *that* problem? (new thread, please!) Still have doubts about escalating the graduation decision to the board. Me too. I certainly believe that we can figure that out as we go. We don't have to hold up a new TLP-based podling based on solving the graduation answer today. Presumably, there would be a few months to explore. And certainly when the project *feels* it is ready, then the discussion will begin in earnest. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
On Mon, Aug 16, 2010 at 7:41 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Guys, 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. +1 from me with my OODT hat on. Also, I like Greg's proposal b/c it puts the onus on those (proposed) $podling.apache.org PMC members who are active, without external peanut gallery oversight. Generally speaking, I'm supportive of trying different things to break through the logjam that we currently have within the Incubator. However, I think we should probably have a discussion on the OODT list as we should think through what this means and how it'd affect the nascent community. With Subversion, it already had a very vibrant, diverse, and self-governing community - OODT isn't quite there so there's a bit of a risk there. Perhaps this will act as a prod to promote the self-governance - which is ideally what we want anyway. At the moment, I probably don't have the time necessary to sit down and lead the conversation within OODT. That alone does give me a bit of a reservation about what exactly we're signing up for. =) -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
[ CCing gene...@incubator as I think I can now place my finger a bit as to why I'm discomforted with Greg's proposal in the OODT context ; and more importantly, another potential experiment at the end; leaving context in for those on gene...@incubator ] On Mon, Aug 16, 2010 at 9:21 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: (moving to oodt-...@incubator.a.o, context coming in separate email FWD) Hey Justin, +1 from me with my OODT hat on. Also, I like Greg's proposal b/c it puts the onus on those (proposed) $podling.apache.org PMC members who are active, without external peanut gallery oversight. However, I think we should probably have a discussion on the OODT list as we should think through what this means and how it'd affect the nascent community. With Subversion, it already had a very vibrant, diverse, and self-governing community - OODT isn't quite there so there's a bit of a risk there. Perhaps this will act as a prod to promote the self-governance - which is ideally what we want anyway. +1 At the moment, I probably don't have the time necessary to sit down and lead the conversation within OODT. That alone does give me a bit of a reservation about what exactly we're signing up for. =) -- To me, all we are signing up for with Greg's proposal is basically to have something like: 1. oodt.apache.org exists today 2. Ian, Chris, Justin and Jean Frederic are OODT PMC members + committers 3. OODT committers continue as-is 5. There is no more IPMC oversight 5. VOTEs on releases are approved by 3 +1s of OODT PMC members - OODT committers weigh in on releases and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 6. VOTEs on new committers are approved by 3 +1s of OODT PMC members - OODT committers weigh in on new committers and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 7. When we're ready (we can even keep the same Incubator checklist), we put up a board resolution to graduate into *true* oodt.apache.org TLP. To me, ready = - we've made at least 1 release (we're close!) - we've VOTE'd in a couple new committers (keep those patches coming people!) hopefully with some diversity in mind, but if we don't get there, and the committers are still vibrant and healthy, then we move forward. OODT already has a pretty vast user community and healthy community that I'm slowing working to get signed up over here in the Incubator. We've had contributions from folks from Children's Hospital (thanks guys!), interest from other NASA centers (welcome Mark and others!), and some new folks from JPL stepping up and earning merit (welcome Cameron, and thanks for popping up Rishi!). Is that your take too? Yes, I think that roughly outlines what Greg proposed. See, here's where I get a bit discomforted by this entire process: I honestly don't feel that I deserve a vote on OODT releases. I've known you and Dave for long enough that I have no concerns advising the OODT community and trying to help out - but...giving me a binding vote? I want to encourage a process where the people doing the work get to have the power. At the core, that is what Apache is about - and having doofus's like me casting a vote for a release seems like straying from that. I'm *totally* fine turning on cranky mode and keeping the peanut gallery away so ya'll on oodt-dev@ get real work done. For Subversion, I was already a full committer and earned my merit. So, I had zero qualms about giving my $.02 there whether they wanted it or not. =) Given your (Chris) experience with other ASF projects (and, heck, being a PMC Chair), I can see exactly how the Subversion analogy (in my head) applies to you. You're a member, you know how things work, you have merit within OODT - so, yah, perfect sense. Smucks like me who get confuzzled reading Maven build scripts? Nah, not right that I should have a binding vote. Now, could we say that I would act as a certifier/observer that all of the major processes were followed? Heck yah. No qualms there. Here's an analogy I'm coming around to: in a lot of new democracies, there are observers who are sent in to monitor elections. They witness the elections, poke around, and make sure nothing unseemly is going on. They don't vote, but they do observe. They then issue a certification or report to be filed with the vote. (I'm catching up on my backlog of issues of The Economist; just read their article about nascent democracies in Africa on the plane...) Hmm, maybe there's something to this observer model as this reconciles my qualms and could provide the basis for an oversight model. Does this analogy move the needle for anyone else? Could a combination of mentor and observer be sufficient? I think so... -- justin - To unsubscribe, e-mail:
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
Hey Justin, Thanks so much for your thoughtful reply. My comments below: See, here's where I get a bit discomforted by this entire process: I honestly don't feel that I deserve a vote on OODT releases. I've known you and Dave for long enough that I have no concerns advising the OODT community and trying to help out - but...giving me a binding vote? I want to encourage a process where the people doing the work get to have the power. At the core, that is what Apache is about - and having doofus's like me casting a vote for a release seems like straying from that. I'm *totally* fine turning on cranky mode and keeping the peanut gallery away so ya'll on oodt-dev@ get real work done. So basically you are moving more towards Joe's proposal, that the PPMC would have the binding VOTEs in e.g., new committers/PMC members, and on releases? Of course, with the caveats below, as you mention, i.e., the observers can observe and step in where necessary, but ultimately, they're there to ensure things are going great, and not to get in the way, unless they aren't? +1 to that. Given your (Chris) experience with other ASF projects (and, heck, being a PMC Chair), I can see exactly how the Subversion analogy (in my head) applies to you. You're a member, you know how things work, you have merit within OODT - so, yah, perfect sense. Smucks like me who get confuzzled reading Maven build scripts? Nah, not right that I should have a binding vote. No way you'd ever be a smuck in my book. And don't worry I'll get you on the Maven bandwagon! ^_^ Now, could we say that I would act as a certifier/observer that all of the major processes were followed? Heck yah. No qualms there. Here's an analogy I'm coming around to: in a lot of new democracies, there are observers who are sent in to monitor elections. They witness the elections, poke around, and make sure nothing unseemly is going on. They don't vote, but they do observe. They then issue a certification or report to be filed with the vote. (I'm catching up on my backlog of issues of The Economist; just read their article about nascent democracies in Africa on the plane...) +1. So our OODT observers would be: You, Jean Frederic, Ross, Ian, and me? PPMC stays the same, but they are given: * binding release/committer VOTEs In this case, observers are just really the mentors, and we move towards the mentors ensuring all is going well (which they should do now anyways), but IPMC ratification isn't required, and PPMC gets to self-govern. +1 from me on that, I think that's the right thing to teach, and with mentors that pay attention, I think we'll be great. I've heard a lot of talk in not just this thread, but over the past day about podlings with mentors that aren't active. Well, if the mentors aren't active, then they shouldn't be a mentor and we should make room for those that have the cycles and that are ready to observe. Hmm, maybe there's something to this observer model as this reconciles my qualms and could provide the basis for an oversight model. Does this analogy move the needle for anyone else? Could a combination of mentor and observer be sufficient? I think so... If my interpretation above is correct, big +1 from me. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
On Tue, Aug 17, 2010 at 01:08, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Justin, Thanks so much for your thoughtful reply. My comments below: See, here's where I get a bit discomforted by this entire process: I honestly don't feel that I deserve a vote on OODT releases. I've known you and Dave for long enough that I have no concerns advising the OODT community and trying to help out - but...giving me a binding vote? You know when to vote and *how* to vote. I see no reason to deny your vote. 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) ... Now, could we say that I would act as a certifier/observer that all of the major processes were followed? Heck yah. No qualms there. Here's an analogy I'm coming around to: in a lot of new democracies, there are observers who are sent in to monitor elections. They witness the elections, poke around, and make sure nothing unseemly is going on. They don't vote, but they do observe. They then issue a certification or report to be filed with the vote. (I'm catching up on my backlog of issues of The Economist; just read their article about nascent democracies in Africa on the plane...) +1. So our OODT observers would be: You, Jean Frederic, Ross, Ian, and me? PPMC stays the same, but they are given: * binding release/committer VOTEs In this case, observers are just really the mentors, and we move towards the mentors ensuring all is going well (which they should do now anyways), but IPMC ratification isn't required, and PPMC gets to self-govern. +1 from me on that, I think that's the right thing to teach, and with mentors that pay attention, I think we'll be great. 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. The (podling) project/PMC would report directly to the Board. No more peanut gallery, or a second-guessing group. 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. ... Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
On Mon, Aug 16, 2010 at 10:08 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: So basically you are moving more towards Joe's proposal, that the PPMC would have the binding VOTEs in e.g., new committers/PMC members, and on releases? Of course, with the caveats below, as you mention, i.e., the observers can observe and step in where necessary, but ultimately, they're there to ensure things are going great, and not to get in the way, unless they aren't? +1 to that. Yes, I know Joe was looking to only try something small and incremental. Given its history, a small incremental change in process is probably right for Thrift, but perhaps we can use OODT as an experiment for something even more bonkers. I don't see how we have much to lose - we've already been taken out to the woodshed once by the Incubator PMC. =) +1. So our OODT observers would be: You, Jean Frederic, Ross, Ian, and me? PPMC stays the same, but they are given: * binding release/committer VOTEs Yes, I think so. Perhaps to satisfy the governance rules, the observers (in the eyes of the Board, the PMC for the TLP) certify the votes from the PPMC (in the eyes of the PMC, the real ones). So, maybe it's not directly a binding vote, but the expectation is that the observers are meant to only certify and *not* provide technical oversight - unless they are *also* part of that PPMC. In this case, observers are just really the mentors, and we move towards the mentors ensuring all is going well (which they should do now anyways), but IPMC ratification isn't required, and PPMC gets to self-govern. +1 from me on that, I think that's the right thing to teach, and with mentors that pay attention, I think we'll be great. Yes. Hmm, maybe there's something to this observer model as this reconciles my qualms and could provide the basis for an oversight model. Does this analogy move the needle for anyone else? Could a combination of mentor and observer be sufficient? I think so... If my interpretation above is correct, big +1 from me. I think we could perhaps make something workable from this. Dunno. Need to see who else chimes in...hey, a message from Greg. =) -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
